Managing separate cookies and session under WKWebView and Alamofire API calls in iOS app

3
votes

What we want to achieve

In our iOS app, we have two different functionalities which deals with a website call:

  1. In WKWebView, we are loading particular website in which users can login to their account and then we parse the page to process data.
  2. We are calling another webpage of same website from Alamofire to perform some actions (as anonymous user) and parsing the data.

The Problem

Everything works fine in second functionality until user logs in to website in first functionality. The problem is somehow sessions are commonly managed and second functionality performs action on user's account instead of performing it as anonymous user!

After some research, we came to know that in iOS, cookies are managed under HTTPCookieStorage. Thus, when user logs in under WKWebView, it creates a session in HTTPCookieStorage and those cookies are being used (internally) in Alamofire call (which converts expected anonymous website call into user identifiable call). According to this, it seems that Alamofire is also managing cookies under same HTTPCookieStorage.

What we have tried

Before API call through Alamofire, we backup all the cookies in some variable and delete all the cookies from HTTPCookieStorage. Then, we initiate API call and do the job (hoping it will manage new cookies which will perform actions as anonymous user). At last, we restore backed up cookies back to HTTPCookieStorage. So that, when the user visits same site on WKWebView, session remains as it is and they don't have to login again (which is working fine)! But even after clearing up cookie storage, new auto-generated cookies (during the API call) somehow identifies the user on that website and action is performed in that user's account instead of anonymous call!

So, how we can manage two different sessions under Alamofire and WKWebView to avoid this issue? Can we do something using WKHTTPCookieStorage?

1
ioscookiesalamofirewkwebviewhttpcookiestorage

1 Answers

1
votes

We found the issue!

In WebView, there was a Timer which was evaluating JavaScript every 0.5 seconds (infinitely) and that timer was not invalidated when screen was finished. Because of that session of user was kept maintaining in the background and thus it was affecting APIs even if we were clearing the cookies.

We invalidated that timer when screen is finished and it solved the issue.