if i set say 1 min expiration but due to large file if it can not be downloaded within expiry time, will download will break/cancelled as time expired.
i need to keep the mim expiration time due to some reason.
Thanks for reply.
The expiration time is only tested when S3 initially receives the request.
The amount of time the download requires is not important, because the "expiration" time refers to how long the signed url can be used to begin downloading.
The exception to this is not really an exception, though it might appear to be if you didn't understanf what was happening. HTTP and S3 allow a client to specify a range of bytes to download. It is probably not common, but it is possible, for a download to be done in discrete chunks. If the client is attempting this, then all of the pieces have to be requested before the signed url expires, since the time each request is made is validated against the expiration time of the signed url.
Related
I use S3 for media file storage on my Django project.
DEFAULT_FILE_STORAGE = 'storages.backends.s3boto3.S3Boto3Storage'
From my iOS project I receive image URLs from Django like
https://my-bucket.s3.amazonaws.com/image-name.jpg?AWSAccessKeyId=<AccesKey>&Signature=<Signiture>
It seems the image URLs are expired after a while(and they probably should). However this causes a problem. When iOS app user left the app and came back after a while and the app memory was alive, the app tries to load images from expired urls(ex. cell reuse) resulting request error.
I wonder what is a right solution for this.
Your link is so-called S3 presigned URL and their expiration can't be disabled. But you can make it longer. The maximum expiration time is 7 days provided the URL is created using IAM user. If you use IAM role or instance role to make the URLs the max times are 36 and 6 hours respectively.
If these times are not satisfactory, you have three general options:
modify your app so that it auto-refreshes expired links.
don't use pre-sgined URLs. Instead make the s3 object public which never expire.
again don't use pre-sgined URL, but instead of making your objects public, create CloudFront distribution to server your objects from the CF. This way your bucket and objects are private (not accessible directly), but through CF which can also improve load times of the files.
i'm developing application with in app subscriptions (monthly, yearly). When i'm getting the receipt from apple with response (i'm validating receipt with apple server, i know this is not a good idea, but still), i want to check the expiration date of the subscription. Here's the checking part.
NSDate *currentDate = [NSDate date];
NSDate *expireDate = receipt[#"expires_date"];
NSComparisonResult result = [currentDate compare:expireDate];
BOOL subscribed = (result != NSOrderedDescending);
But if the device time is wrong(the user changed the time of the device) how can i be sure that subscription is still active ? Maybe i should request the current time from the server ?
I suggest reading up a little more about Apple's receipt verification and how most effectively validate In-App Purchases.
To your question: In short, yes. Requesting the current time from a server will give you the current time independent from the users device. This will always be the most reliable way to retrieve the current time.
A little more detail...
What you need to do is read the receipt url as data then base 64 encode it from the data. There is a similar post to this question which will be helpful in understanding this process.
Ultimately you need to handle this sensitive data as securely as you can - this process will allow you to retrieve the best kept "safe" expiration date (receipt) for your IAP.
Read this post to help point you in the right direction.
In regard to checking the "correct time" there are a few approaches you can take here.
Approach 1
Get the correct time from an API. Here is an API you could use to get the world time. You could also use AWS to get the current time.
Approach 2
This response goes into a simple way to monitor device clock changes to make sure / listen for the user changing the time. By monitoring for any large time changes you can decide whether the user has changed the clock maliciously or not.
Approach 1 will deliver (of course) an independent time for you to compare that should always be the true current time, where as 2 is a way that you can monitor the device's clock.
I noticed that OAuth 2 in its spec recommends the use of a property expires_in that defines how long the access code is valid.
This seems backwards to me, as the API still needs to calculate the time at which this expires to save it in the database, and the receiver needs to do the same. It seems much more sane to pass the expiry time as a standardised UNIX timestamp, which both the API and the application can save in their db to check for expiry times.
Since nobody seems to have an answer to this I'll add my assumption as an answer:
Server and device times will not always match. Which is why a duration is the more logical way to go.
Consider a user disabling time-syncing with servers and manually setting his/her time 1 week in the past. The tokens received from oAuth servers don't take this into account, they just set an expiry date and send a timestamp to the device assuming the device's clock is in sync AND it will convert the timestamp to the correct device timezone.
By sending a duration these "misunderstandings" can be bypassed.
We have an IOS app which connects to API/server through SSL connection. The SSL keys have been hard coded in the APP, the SSL certificate has expired and now the app is not functioning.
Q1. We want to avoid submitting the APP to the store as it takes upto 2 weeks to update the app.
Q2. We also want to get the SSL keys from CDN/store so that we dont hard-code it. But when we make the call to the store how do we ensure that its a secured connection?
What is the best way to get out of this situation?
I am sorry to say, but there is probably no way to do it except to upload new app. Here you can see how long it takes on average for users to get App approved - it is not as bad as 2 weeks, it can be much shorter (especially if it is update, those usually take less time from my experience)
So for the second question, I would advice you not to do it. Those keys should be present on the device, and you would have to update the App with new codebase anyway.
You can as well update the key and then, later, update the key in advance if you need to (it does not expire every month, and if you have production application, you will probably update it from time to time).
If you really need to download the key, then probably most secure way how to do it would be to encrypt the key on server side, send it to device and decrypt on device (possibly using AES128, 256 or something similar). You can also use signed download links with expiration time to add extra layer of security (fe. amazon S3 buckets provide that functionality).
Hope it helps!
I think you can use Google Tag Manager. You can publish new certificate through GTM instead of resubmit new ipa.
Apple has supported disk caching as of iOS 5.0. I was using a home-rolled solution before, but I'm testing NSURLCache in hopes of finally using it since I've seen strange behavior in the past.
One of the more perplexing issues I'm having is that cachedResponseForRequest: returns expired requests. I've been testing by setting forward the clock on the iPhone I'm using. Parsing the headers clearly shows that the device time is ahead of the expiration date.
I'm willing to accept that there may be a background task that prunes expired requests on a regular interval. I have done tests where I actually wait to see if the request expires "naturally", and it doesn't.
Did Apple just fail to implement cache invalidation correctly?
I'm testing using a Charles proxy. It's a tough problem and I don't envy anyone who has to implement cache invalidation, but iOS is supposed to be a mature SDK by now.
There are two http caching mechanisms: expiration and validation.
If a response has not expired, the client can serve it from the cache without making a request to the server.
If it has expired the client can make conditional requests using the If-Match or If-Modified-Since header entries.
If the server responds with 304 Not Modified, the client can use the data from the cache even if it has expired.
For more details have a look at http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html.