I have an App which is playing audio files stored on AWS.
The audio content is secured by AWS CloudFront signed cookies functionality. I had no problem in creating the signed cookies and set them in the original HTTP request using AVURLAsset, and everything works just fine for .mp3 content. Nevertheless, when accessing .m3u8 files, I get a 403 HTTP error. I noticed that the initial request is ok and the .m3u8 file is downloaded correctly, but the subsequent requests (for the audio fragments) do not work and receive a 403 as the cookie is not sent.
I already tried using the NSHTTPCookieStorage, but it did not work ;-(
NSURL *url = [NSURL URLWithString: #"http://..../stream.m3u8"]
// Get the Cookie Storage
NSHTTPCookieStorage *cookiesStorage = [NSHTTPCookieStorage sharedHTTPCookieStorage];
// Create the array to store the cookies
NSMutableArray *cookies = [NSMutableArray array];
// Create the Cloud-Front-Policy Cookie
NSHTTPCookie *cloudFrontPolicyCookie = ...
[cookies addObject:cloudFrontPolicyCookie];
// Create the Cloud-Front-Signature Cookie
NSHTTPCookie *cloudFrontSignatureCookie = ...
[cookies addObject:cloudFrontSignatureCookie];
// Create the Cloud-Front-Key-Paid-Id Cookie
NSHTTPCookie *cloudFrontKeyPairIdCookie = ...
[cookies addObject:cloudFrontKeyPairIdCookie];
// Create the HTTP Header Dictionary
NSMutableDictionary * headers = [NSMutableDictionary dictionary];
// I omitted the cookie creation, but it is ok! I tested using curl on the command line
NSString *cookieAsHeader = ...
// Set the header
[headers setObject:cookieAsHeader forKey:#"Cookie"];
// Create the AVURLAsset so that I can use the headers and the cookies
// Notice that I tried using only the headers (which works)!
AVURLAsset * asset = [AVURLAsset URLAssetWithURL:url options:#{#"AVURLAssetHTTPHeaderFieldsKey": headers, AVURLAssetHTTPCookiesKey : [cookiesStorage cookies] }];
// For secured .mp3 files, it works just fine
// but for .m3u8, the content does not play as the first file part receives 403. Notice that the first request (for the .m3u8) works just fine.
AVPlayerItem *playerItem = [AVPlayerItem playerItemWithAsset:asset];
You need to generate the cookies, unfortunately aws ios sdk doesn't have this function. My temporary solution for now is one the the following:
1) Ask web server to generate the cookies (using aws php sdk). In this way you can set timeout in a few minutes or anytime you desire, so you can keep the data safe.
2) Hardcoded the cookies inside the code. You can generate it locally using aws php sdk, and then set duration as long as possible. Maybe a year or more depend on your condition. However if someone can see it, your data will be exposed.
3) Create our own cookies generator function in swift/obj-c. We can use aws php sdk for reference.
It looks like would be a good way to handle it: https://github.com/ykying/Swift_Player_AWS_Cookie
You will likely need to generate the cookies on whatever server you have written for serving content and whenever the user opens the app or logs in, give them the cookies with a 24 hour expiration (or however long your current session TTL is).
I hope this helps someone else, we're going to try this out in our app as well.
Related
I understand that as of iOS9 you should be able to read cookies with SFSafariViewController.
If I set a cookie on my page in JS using the following:
var dd = new Date(Date.now() + 1000 * 60 * 60 * 24).toGMTString();
var expires = "expires="+ dd;
document.cookie = "mycookie=cookievalue; " + expires + " domain=.mydomain.co.uk ; path=/ ";
If I do :
- (void)safariViewController:(SFSafariViewController *)controller didCompleteInitialLoad:(BOOL)didLoadSuccessfully
{
NSHTTPCookieStorage *storage = [NSHTTPCookieStorage sharedHTTPCookieStorage];
NSArray *cookiesArray = [storage cookies];
}
cookiesArray is always empty.
If I use a traditional UIWebView
-(void)webViewDidFinishLoad:(UIWebView *)webView
{
NSHTTPCookieStorage *storage = [NSHTTPCookieStorage sharedHTTPCookieStorage];
NSArray *cookiesArray = [storage cookies];
}
I get the cookie I was expecting.
Any ideas what I might be doing wrong?
SFSafariViewController is basically a Safari process, running outside of your app. Your app will not have any access to the cookies used by the SFSafariViewController, just as your app has no access to the cookies in the Safari app itself.
If you need this functionality, you'll need to stuck with UIWebView or WKWebView.
SFSafariViewController runs in a separate process, so reading cookies is NOT possible.
However, in case SFSafariViewController is the only option available due to some limitations with the existing available options like WKWebView, and UIWebView.Then the custom URL scheme approach will be helpful in sending the data from SFSafariViewController to the parent App which initiates the SFSafariViewController.
In the above case, a possible URL will be as follows, where "myapp" is the custom URL scheme
"myapp://SendData?mycookie=cookievalue&domain=.mydomain.co.uk&path=/"
So, the custom URL scheme will be registered against the parent app to launch it and custom URL scheme parameters will have the intended data to be received by the parent app. If the data is sensitive then it can be encrypted by javascript prior to sending and can be decrypted by the parent app after receiving it.
Hope this would help :)
For more details on the custom URL scheme, please visit
https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app
Our customer requested us to do a switch from WebView to WKWebView recently. Their app uses native login, which is done by a 2 POST calls to their backend, returning various authorization cookies that were later on used in every single HTTP/AJAX call throughout the whole app.
With the WebView, it all worked like a charm without a need to implement a single line of custom code. User logged in, cookies were stored to cookie storage by default, and WebView always took them from there and used them, since the HTTPCookieStorage was shared between NSURLSession and WebView.
It it a whole new story with WKWebView. Once we switched WebView to WKWebView, we saw that the authorization was not working. It was due to losing some cookies in the WKWebView. We store the cookies from the NSURLSession response now and append them to the WKWebView manually, by adding "Cookie" header to the HTTP requests.
We were able to get the authorization for HTTP calls work this way, but now we are seeing a new problem. Somehow, all the AJAX calls done in the WKWebView lose the authorization cookies.
Do you please know if there is any way to somehow have the authorization cookies appear in the AJAX calls too? Injecting javascript with
javascriptCookieString = #"document.cookie = 'testCookie=testValue';";
[self.webView evaluateJavaScript:javascriptCookieString completionHandler:nil];
did not work and it seems like there is no control whatsoever over Javascript calls, so I cannot alter the requests before they are being executed. Thank you.
I found that the following snippet did the trick for us. We had the same problem.
// add session cookie to ajax calls
WKUserContentController* userContentController =
WKUserContentController.new;
WKUserScript * cookieScript =
[[WKUserScript alloc]
initWithSource: [[User sharedInstance] getJavscriptCookieString]
injectionTime:WKUserScriptInjectionTimeAtDocumentStart forMainFrameOnly:NO];
[userContentController addUserScript:cookieScript];
WKWebViewConfiguration *webViewConfiguration = [[WKWebViewConfiguration alloc] init];
webViewConfiguration.userContentController = userContentController;
webViewConfiguration.preferences.javaScriptCanOpenWindowsAutomatically = true;
_wk = [[WKWebView alloc] initWithFrame:self.view.frame configuration:webViewConfiguration];
The cookie string needs to be formated correct in order to be accepted.
-(NSString*) getJavscriptCookieString {
return [NSString stringWithFormat: #"document.cookie = '%#=%#'", [self getSessionName], [self getSessionValue]];
}
Hope this can be of some help.
See also:
Can I set the cookies to be used by a WKWebView?
How does -[NSURLCache cachedResponseForRequest:] works? Is it works like key-value pair where the key is the content of the NSURLRequest object (which includes the NSURL object, cache policy, time out interval, HTTPBody, HTTPHeaders)? If so then if any of the above field is different then we could not retrieve the cache.
For example, assuming the NSURLRequest has everything staying the same except the HTTPBody, which one request has the body of:
{
a = 1;
}
while another request has the body of:
{
a = 2;
}
Am I be able to get the cache of former request using the latter request?
IIRC, only the URL is taken into account. If header or body data dfferences matter to you, you'll need to implement a custom cache. The URL Loading System Programming guide should be of some help, should you decide to go down that path.
Our service is using Google App Engine as our backend, and we're now implementing an upload-function for images etc.
Using the answers from several different questions here on stack, I have made it working, but not completely as I want. We are not using the built-in OAuth etc, and for now we want the storage to be public, but not entirely public. We would like to limit it to users of our own app (I.E no authentication). In the Cloud-console we can create an API-key for iOS. When doing this, we copy the API-key to the app, and pass it along with every upload-request. This is currently working, when the bucket-permission is set to allUsers - WRITE
However, inside the API-key, we can supply our app's own Bundle Identifier, so that, supposedly, only requests from our app is allowed. (App Store ID/URL is also permitted, apparently).
Adding this bundle-id does nothing as long as the bucket has the permission allUsers - WRITE. If I change the bundle-id to not match the actual bundle-id, it still works. So which permission should it use for the bucket to make the bundle-id in the API-key apply? And what should be sent along in the upload-code on iOS (acl?)?.
If I remove the allUsers-permission, and use something else, I get this error when trying to upload:
{message:"There is a per-IP or per-Referer restriction configured
on your API key and the request does not match these
restrictions. Please use the Google Developers Console
to update your API key configuration if request from this
IP or referer should be allowed." data:[1] code:403}}
This is how I'm using it right now (though I have tried several different things, all picked up from different questions/answers):
GTLServiceStorage *serv = [[GTLServiceStorage alloc] init];
serv.additionalHTTPHeaders = [NSDictionary dictionaryWithObjectsAndKeys:
#"[my project id]", #"x-goog-project-id",
#"application/json-rpc", #"Content-Type",
#"application/json-rpc", #"Accept", nil];
serv.APIKey = #"[my iOS API key, gotten from console, (linked to bundle-id?)]";
serv.retryEnabled = YES;
GTLStorageBucket *bucket = [[GTLStorageBucket alloc] init];
bucket.name = #"[my bucket]";
GTLUploadParameters *params = [GTLUploadParameters uploadParametersWithFileHandle:fileHandle MIMEType:#"image/jpeg"];
GTLStorageObject *storageObject = [[GTLStorageObject alloc] init];
storageObject.name = #"testFile.jpg";
//I have no idea what I'm doing with the following stuff, but I've tried several things:
GTLStorageObjectAccessControl *objAccessControl
= [GTLStorageObjectAccessControl new];
//This is working
objAccessControl.entity = #"allUsers";
objAccessControl.email = #"[my app-id]#project.gserviceaccount.com";
objAccessControl.role = #"OWNER";
//If I try this instead, it is not working.
//objAccessControl.domain = #"[my app-id].apps.googleusercontent.com";
//objAccessControl.role = #"WRITER";
//Probably because it's bullshit, I have no idea what I'm doing.
storageObject.acl = #[objAccessControl];
[...] //Bucket and upload and stuff. It seems like it's the ACL-thing above that's not working..
It seems like I have to connect the permissions on the bucket to the iOS API Key somehow, but I don't know if it's even possible.
What I want: All users to be able to use the cloud, given that they are requesting it from my iOS app.
As this question never got an answer I'll add one here, based on the information currently in the post.
The reason you got the error 'There is a per-IP or per-Referer restriction..' when calling the GCS API with the iOS API Key is simply because the GCS API doesn't work with API Keys for private data, only Bearer Tokens (ie. using OAuth). There isn't anything you could have done to make the API Key work with the GCS API directly with private data. The reason it worked when you had 'allUsers - WRITE' set as the ACL is simply because that ACL allows public access.
To access the private data without user intervention requires a Service Account, however the Google APIs Objective-C Client only supports OAuth2 Client IDs. The rationale being that Service Accounts are intended for server-side authentication only. Using a Service Account in a client would involve distributing the private key along with the app, which could easily be compromised. For reference, here's a sample of how you might authorize the GCS service using OAuth:
NSString *keychainItemName = #"My App";
NSString *clientID = <your-client-id>;
NSString *clientSecret = <your-client-secret>;
// How to check for existing credentials in the keychain
GTMOAuth2Authentication *auth;
auth = [GTMOAuth2WindowController authForGoogleFromKeychainForName:kKeychainItemName
clientID:clientID
clientSecret:clientSecret];
...
// How to set up a window controller for sign-in
NSBundle *frameworkBundle = [NSBundle bundleForClass:[GTMOAuth2WindowController class]];
GTMOAuth2WindowController *windowController;
windowController = [GTMOAuth2WindowController controllerWithScope:kGTLAuthScopeStorageDevstorageFullControl
clientID:clientID
clientSecret:clientSecret
keychainItemName:kKeychainItemName
resourceBundle:frameworkBundle];
[windowController signInSheetModalForWindow:[self window]
completionHandler:^(GTMOAuth2Authentication *auth,
NSError *error) {
if (error == nil) {
self.storageService.authorizer = auth;
}
}];
...
// Initialize service with auth
GTLServiceStorage *serv = [[GTLServiceStorage alloc] init];
serv.authorizer = auth;
All of this was taken from the storage sample on the google-api-objectivec-client GitHub page, so you can refer to it for a complete example with context.
This still leaves the question of how to implement access to GCS from iOS without user authorization. The short answer to this is that the iOS Key can be used to restrict access to your own backend API hosted on Google Cloud Endpoints, and that backend application can authorize against GCS using a Service Account (usually the Application Default Service Account). The Cloud Storage Client Library Examples page has samples using the default credentials for different languages.
Further details on how to implement an Endpoints API for this purpose are probably getting outside of the scope of this question, but this should serve as a good starting point.
This question perhaps can be trivial, be as I am starting with IOS I'm not sure on what to search for.
I have a backend which handles processing of images, and with browser-based uploads, the images get upload directly to a temp folder in the app's bucket in S3, once done, I send the url to the backend for processing of the image in a background worker.
On IOS, I don't understand how and who is responsible for getting the url of the just-uploaded file to the server or to the app along with some meta data (which user uploaded the file, etc)
Looking at an S3 SDK for mobile example https://aws.amazon.com/articles/3002109349624271 I don't see that this is included.
Is that possible? Is that a common practice to do (get the url back from S3 and send it to the server along with meta data)?
The sample code from link in question.
S3PutObjectRequest *putObjectRequest = [[[S3PutObjectRequest alloc] initWithKey:MY_PICTURE_NAME inBucket:MY_PICTURE_BUCKET] autorelease];
putObjectRequest.contentType = #"image/jpeg";
putObjectRequest.data = imageData;
// Now we need to get the response and check the error which was not in the sample code given in the link
S3PutObjectResponse *putObjectResponse = [s3 putObject:putObjectRequest];
if (!putObjectResponse.error)
{
// Send the KEY to server.
}
Let me know if you have any questions.