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.
Related
We are building an app that allows users to connect their cloud storage (in this case gDrive) and upload files from our app, however they also have the ability to disconnect from it and perhaps connect to another.
A use-case might be:
A User connects to gDrive(App creates folder and uploads files) >
Later user disconnects from drive in-app >
Later user reconnects
Problem being we then want to grab this previously created folder and make changes and the issue is, in order for the user to reconnect they have to reauthorize, setting a new token and we therefore no longer have access to that folder and instead our app auto-creates a new folder with the same name - obviously this is not what we want.
The only solutions we can think of is not re-authorizing on disconnect/connect or increasing the scope of oauth and searching for the folder.
We will be using something like rClone in the future, but for now we are focusing on a couple of the main cloud services.
Are there any other solutions to this?
Your app is using drive.file scope, which allows it to access files created or opened by the app.
Users commonly disconnect from the app, effectively deauthorizing it. Because of this, the app does not have access to folders that were created last time user connected to the app.
The description of drive.file scope is quite clear:
Per-file access to files created or opened by the app. File authorization is granted on a per-user basis and is revoked when the user deauthorizes the app.
Because of this, unfortunately, the only two ways to allow the app to access previously created folders are the ones you already sketched:
Use a scope that provides a wider access: the scope in this case should probably be https://www.googleapis.com/auth/drive, since the app, from what I understand, needs write access.
Change the workflow of your app so that users don't deauthorize the app.
Regarding the use of a wider scope, the following feature request, which apparently was internalized recently, could provide an acceptable workaround in case it got implemented:
FR: Drive Restrict access to folder when authorizing applications
I'd suggest you to star the referenced issue, to keep track of its development and to help prioritizing it.
I'm having trouble working out why some uploads to our server from iOS result in empty files. The upload page is a simple form using POST and enctype as multipart/form-data.
The problem only seems to arise when the user:
Is using iOS
Attempts to upload a file from a cloud service (currently iCloud or Dropbox) even if the file is the version on their local system
Leaves a period of time between selecting the file (via a <input type=file> button) and initiating the upload, roughly about 30sec to 1min.
I'm not sure if there is a timeout issue with the connection to the file, and if so, whether this is a bug or a security feature. If the user selects their file and initiates the upload within this time, the file uploads successfully.
Uploads from the 'true' local system (eg. outside any cloud folders) upload fine, even after any delay. The file size and file type seem to be irrelevant.
I'm aware Dropbox have a 'Chooser' system, which forwards a link instead of the file, however in testing, a Dropbox file will still upload successfully provided the user does so within a short time.
The form that handles the upload is rather large with many options, so typically a user will spend some time between selecting the file and initiating the upload.
The problem does not occur on Android or OSX desktop platforms.
I have also tested using an independent online uploader, namely http://checkfiletype.com/ and performed the same test, and the same thing happens:
result after pressing 'upload' straight away,
and
result after short a delay and then pressing 'upload'.
I'm not sure where to go from here, most Googling only turns up results about uploading TO cloud platforms, instead of from them. Am I missing something?
Update: This appears to be no longer be the case with the release of iOS 15.4. The updates page contains under 'bug fixes':
Photos and videos may not sync to iCloud Photo Library
Whilst it doesn't describe the bug directly, it appears the dev teams have actually made adjustments to the chooser/file system. What a shame it took several years.
I am trying to display the www.usta.com website in my application.
I added the following keys to my .plist and the site loads some of the data. However, it will not load any of the images.
Does anyone know why the images won't load?
I am testing on an iPhone 6 device that has iOS 9.3 installed.
The website you're asking about uses Amazon S3 to serve images. This screenshot shows where the images are loading from:
Since App Transport Security checks for a matching domain name, you need to add the s3 domain (amazonaws.com) to your plist.
My first try would be to simply allow arbitrary loads, unless you are wanting ONLY usta.com to be able to load. This should be the most simple way of doing it unless you are wanting to restrict which kinds of websites (http vs https) will load other than usta.
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.
I have been serving some mp3s to a small community for years just by linking straight to the MP3 and letting the device's browser handle the playback. All worked fine until users updated their iPhones to iOS 8. Now playing MP3's natively doesn't work. After lots of testing I seem to have narrowed it down to the use of .htaccess.
Here are two identical directories with the same mp3 and directory listing software in them. But one is password protected (U:music P:access).
Normal: http://danielmee.com/dl/
Secured: http://danielmee.com/dl-secure/
I've also tried using a JS player which also broke once behind the secure directory.
What changed in iOS 8 to disable MP3 playback and is there a way to fix it?
The hoops that iOS goes through to play a music file are interesting, to say the least. Looking at a packet trace, the credentials are sent properly for the initial request of the file, but the subsequent partial requests do not have credentials. This is likely a bug in Safari; if you get a free developer account with Apple, you can report the problem to them.
HTTP authentication works this way: the browser makes a request for a resource; the server responds with "401 Authorization Needed" and includes a WWW-Authenticate header indicating the type of authentication — in your case, basic — and the "realm" which is just a way of grouping protected resources. The client re-requests the same resource, adding an Authorization header that contains the username and password — in the case of basic auth, it's just base 64 user:pass. Typically, the browser will cache these credentials and send them without being asked, for every subsequent request within the same realm.