Hello,

Our goal was to make API as simple as possible. And we thought that enabling programmer to provide/changing existing WKWebViewConfiguration instance may make more harm than good. But if it will eventually turn out that it is really only way - we will do it.

May I ask you first to elaborate more on what you want to achieve? The WKWebView instances which are created inside PMSnapStartViewController already use shared WKProcessPool instance (it is available as a PMHybridWebView.sharedProcessPool instance). So cookies are shared between these WKWebView instances.

Why do you mean by saying "in order to keep existing cookies". You want to persist session cookies between application launches?
I don't know how to achieve it by using custom WKProcessPool instance. The WKProcessPool instance is just a token, so serializing and deserializing should not restore sessions.

I think you should go with 'HTTPCookieStorage.shared' instance to retrieve/restore your session cookies. I know that cookie synchronization is major problem with WKWebView (WKWebView works in its own process), but in Mashup library we made an effort to workaround these deficiencies to some degree:
- all cookies received via page navigation are immediately put to shared HTTPCookieStorage instance
- Unfortunately cookies obtained via XHR calls are not guaranteed to be put into shared HTTPCookieStorage instance immediately. 
- Mashup library is listening for 'NSHTTPCookieManagerCookiesChanged' notifications and tries to update cookie storage on the WKWebView side by invoking some 'document.cookie=..' JS calls. 

You can try also to retrieve cookies through 'fetchDataRecordsOfTypes:completionHandler:' method call on one of the WKWebsiteDataStore instances. But I didn't try this.

Hello mloct,

Thanks for your answer! It's great to be able to talk with someone who worked on the SDK first-hand.

Here is the context: Pega is not used directly for user login, another piece of software sits in front of it in order to handle authentication and account creation using the OpenID standard. This software is KeyCloak.

What I'm trying to achieve is this:

• open the KeyCloak URL in my own WKWebView in my app, and make the user log in with is username and password
• this will yield session cookies that are stored inside the WKWebView (more precisely inside the WKProcessPool which is part of the WKWebViewConfiguration)
• I intercept the redirect to the Pega page as I now want to use the Mashup SDK instead of handling the hybridation in the app myself
• I create a PMSnapStartViewController and show it. That's the step where I want to inject the WKWebViewConfiguration (containing the WKProcessPool) that was used by the previous WKWebView I managed myself, in the hope that the cookies used in my own WKWebView will be reused by the WKWebView instantiated within your Pega Mashup SDK
• I would also like to store the cookies between app launches, so that the end-user does not have to login in every time he launches the app

Does that clarify your understanding of the context? Do you now understand why I'd like to pass an existing  WKWebViewConfiguration instance to the WKWebViews instantiated by the Mashup SDK: it's to share cookies from some preliminary authentication process before calling the Mashup SDK.

As far as the various suggestions you made, here's what I've managed to check at the moment:

• WKWebsiteDataStore does not yield cookies, it's just a way to manage the data stored by navigation in a WKWebView. You can for example delete cookies associated with a domain, but you cannot peek inside and read cookie information. So fetchDataRecordsOfTypes:completionHandler is not a solution
• As I understand it, if I manage to insert cookies regarding KeyCloak auth inside the shared HTTPCookieStorage, they will be synchronized inside the WKWebView instantiated by the Mashup SDK. The problem here is that these cookies are obviously sensitive for security and are flagged HTTPOnly, so I don't think I'll be able to read them from native code. I will try to use the old UIWebView for my own webview to perform the user login, and see if the cookies generated by it can be inserted inside the share HTTPCookieStorage

Do you think you could send me a modified version of your Mashup SDK with the ability to provide an existing WKWebViewConfiguration to check if this solve this issue?

Thank you very much for you help.

Guillem

Hello Guillem,

Sorry for late reply. I didn't receive any notification for your response and I missed it.

I understand what you want to achieve and have some questions.

Regarding your first post:

- WKProcessPool. You may want to configure your 'log-in' WKWebView instance with our PMHybridWebView.sharedProcessPool instance? Or event better would be to use PMHybridWebView class for it (it is our wrapper around WKWebView, and it is configured with our WKProcessPool instance OOTB). This will ensure that cookies are synchronized among all WKWebView instances and webview embeded into PMSnapStartViewController will have an access to a session cookie.

- I asked our Product Manager to give me permission to create a custom build for you with configurable WKWebView inside SnapStartViewController. One important question - which version of Mashup SDK are you using? 7.22.5?

- You are right about WKWebsiteDataStore. This is not a way to get an access to WKWebView cookie store. The API for cookie management in WKWebView will be available only since iOS 11. So sorry, for wrong advice.

- Implementing single-sign-on functionality using WKWebView instances is troublesome - to say at least. This is because we don't have programmatical access to WKWebView cookie storage. If you are interested I may describe later how we have achieved SSO in our Hybrid Container application (iOS/Android app built on Mashup SDK which opens PRPC application).

- I don't understand your point regarding HttpOnly cookies. Such cookies are of course accessible from native code. The 'HttpOnly' flag means that these cookies are not accessible (you cannot read them or modify) from JS, for example from document.cookie API.

- Regarding old UIWebView. It runs in the same process as the rest of application and all cookies obtained by UIWebView are immediately put to shared NSHTTPCookieStorage and vice versa.