3

My application has two views :

  • a login view awaiting user credentials

  • the main view containing the webview

When the user inputs his credentials, a native asynchronous POST method is sent to the server. If the credentials are valid, the user will be redirected to the webview view and load it using the load(request) method.

note : request is also a POST method using the said credentials.

The reason behind this two-step authentication is to avoid opening the webview with a 403 error login/password couple ; if authentication fails in the first step the users stays on the login view.

Here is a flow chart explaining how the authentication works

Versions of iOS between 10.0 and 11.2 run the application without any issue. Devices and emulators using iOS 11.3 open the webview with a 403 error.

So far I can assert two things (and has been tested by our backend) :

  • the authentication succeeds using the asynchronous POST method, meaning the credentials are correct and communication between the app and the server is working as intended

  • when the webview is loaded, the server does not recieve any parameters for authentication which explains the 403 login/password error.

Currently this issue is rendering my app unsable so a quick fix is greatly needed. GET requests have been tested and their parameters are sent without any issue.

Any suggestions would be most welcome.

TL;DR - since iOS11.3 POST requests do not work properly in WKWebViews, how can I make a more or less secured authentication using a GET request ?

PS : couldn't add the iOS 11.3 Tag to it, would greatly appreciate if someone could add it.

sancho
  • 443
  • 4
  • 14
RandomFly
  • 55
  • 1
  • 7

4 Answers4

2

I've tested against iOS 12.1.4 using WKWebView and works as expected. Only thing you need to make sure that the request has the proper header. In my case the issue was given by the missing Content Type, which has to be "application/x-www-form-urlencoded". Because of that, then you need to make sure that the body part is compliant with the rfc-1738 and the spaces chars are represented as '+' as described here.

Regarding the WKWebView mentioned delegate webView:decidePolicyFor: the body part there is not shown, but it is actually sent. I may assume is shown as empty for memory/security reason, or maybe is just a bug, not much concerned about that by far

Hope it helps

Luca Iaco
  • 3,387
  • 1
  • 19
  • 20
  • I can confirm this works for a WKWebView in iPadOS 13.5.1. The Content-Type header can be sent as described here: https://stackoverflow.com/a/1323844/872051 – Jan Ehrhardt Jun 02 '20 at 10:50
1

I used UIWebView instead the WKWebView and it worked!

Danielle Cohen
  • 629
  • 8
  • 5
0

I had a same problem herehere :(, don't know why POST parameter not sending when load URL Request by WKWebview. You can loaded site content (html resources) with URL session and fill it to WKWebview. But it will not maintain history, or navigationRequest if your page using cookie.

Hong Son
  • 1
0

sadly you cannot do this with WKWebView.

It most certainly does not work in webView:decidePolicyForNavigationAction:decisionHandler: because the navigationAction.request is read-only and a non-mutable NSURLRequest instance that you cannot change.

If I understand correctly, WKWebView runs sandboxed in a separate content and network process and, at least on iOS, there is no way to intercept or change it's network requests.

You can do this if you step back to UIWebView.

Sebastian Paduano
  • 301
  • 1
  • 5
  • 17