SFSafariViewController cookies
Asked Answered
F

2

14

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?

Forzando answered 19/12, 2016 at 15:30 Comment(0)
P
21

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.

Postliminy answered 19/12, 2016 at 15:53 Comment(7)
Thanks for getting back to me but according to : developer.apple.com/reference/safariservices/… The view controller includes Safari features such as Reader, AutoFill, Fraudulent Website Detection, and content blocking. It shares cookies and other website data with Safari. The user's activity and interaction with SFSafariViewController are not visible to your app, which cannot access AutoFill data, browsing history, or website data. You do not need to secure data between your app and Safari.Forzando
You are misunderstanding what it means to say SFSafariViewController "shares cookies and other website data with Safari". SFSafariViewController is an instance of Safari. It is not part of your app. It is accessing the Safari sandbox of data (cookies, autofill, etc), it is not your app sharing that data with Safari. Your app doesn't have access to any of the secure data in Safari, including cookies. If you need to have access to web site cookies in your app, SFSafariViewController isn't the right choice.Postliminy
You proved out my answer in your code. NSHTTPCookieStorage will be empty if you access the website in an SFSafariViewController. SFSafariViewController has it's uses, but not for what you are trying to do.Postliminy
OK, thanks for the clarification. Just to give some context, I was advised that I could use the SFSafariViewController for deferred deep linking. i.e. 1. Clicking a universal link on a webpage (containing cookie data) 2. Because the app isn't installed the appstore opens and my app is downloaded 3. When my app opens and runs, it then reads the 'shared cookie' and actions.Forzando
I don't believe that advice was correct. Take a look at this: blog.branch.io/install-attribution-ios-9-safari-view-controller - note the quote "Practically speaking, you can’t just open up SFSafariViewController and read the cookies from any website (that would be terrifying)."Postliminy
Yes. I see what you mean. Thanks for all the help.Forzando
@JaiByron so were you able to implement deferred deep linking using UIWebView? I have the same requirement to implement deferred deep link for iOS app.Harbin
P
2

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

Peaceful answered 16/8, 2022 at 18:47 Comment(1)
ERRORS In Safari: 1) Cross origin requests are only supported for HTTP. 2) XMLHttpRequest cannot load deeplink://path due to access control checks.Spelling

© 2022 - 2024 — McMap. All rights reserved.