WKWebView, Form POST and Session Cookies

I am having an issue with forms, server connect and API when using POST on mobile when using WKWebView. Posting via a form works fine when using UIWebView however as this is now depreciated for iOS I am looking for a solution for WKWebView as currently form submissions simply will not work for me when using it.

Does anybody have any ideas on this?


WKWebView enforces CORS so you have to enable it on your remote server, see:

You do that usually into your .htaccess file

Hi George,

Thanks for your reply!

I tried implementing this and even allowing all in .htaccess but I still get the same issue of it not being able to complete the POST action:

Header add Access-Control-Allow-Origin "*"
Header add Access-Control-Allow-Headers "*"
Header add Access-Control-Allow-Methods "*"

If this helps, it is for a login form. I can’t seem to get it to login and verify user details at all. It works locally and without WKWebView.

Aha maybe it is the cookie then.

Is the login form made server connect and security provider?

Security provider uses per default secure cookies (httpOnly) that can’t be read from JavaScript ( so also not Cordova)

So you might want to switch that off.

Thanks for suggesting this and yes it is using Server Connect and Security provider. It does sound like what you are suggesting makes sense but please can you tell me how to turn this off?

Hi George,

Please could you explain how to turn this off as I can’t see any option in there that is obvious.

Many thanks!

Do you get any errors? I don’t think it is the cookie, the cookie is only set after a successful login and it uses the session cookie by default, only when the session is expired it uses the cookie from the remember me option.

It looks like a CORS problem to me, but it is difficult to tell without any information. Would at least want to know what the server responded (maybe check the server logs) and if there where some javascript errors in the WKWebView.

Hi Patrick,

When looking at Console/Debug through Adobe Phone Gap, the script simply shows as pending and will not complete processing.

It works with normal forms with POST and Server Connect but not with Security provider and Login - it will just not complete almost like there is a rule blocking it but I have everything open on the server so it could be something that is being blocked locally on the app but I am stuck on this.


What are the steps in the Server Connect action? Does the form submit work if you disable the login step in the action?

Server connect settings (works with UIWebView but not WKWebView):


Then when running in WKWebView looking at the console when submitting we get the following

On the second line I have disabled the Security provider and the form processes OK. Does this help?

Which steps did you disable, was it only the login step or did you also disable the steps above it.

  1. I deleted Security Provider (as it will not allow me to disable it)

  2. I disabled Security Login

I left the DB connection in place

I also tried leaving Security Provider in there and disabling the Security Login step and the form processes OK (but obviously doesn’t log you in)

Thanks, so the Database Connection and Security Provider steps are not causing the pending state. Then we know that it is the login step. Does it keep pending also on invalid login credentials or only with a valid login?

It stays pending if the details are or are not correct.

Hi Patrick,

Did you have any thoughts on this one at all?

I don’t know exactly where to look, do sessions work? Try using a setSession action step.

You could also test to create a Security Provider of type Single with just a single username/password, no database. Do not allow Basic Authentication and set the Remember of the login step to {{false}}.

Single did work when putting the credentials in the Server Connect action. In fact it worked on the database one too when hard coding the credentials. it only seems to be when you pass a POST value to either the username or password field. Confusing.

Could there be some firewall blocking the request? It is possible that it is being blocked because it sends plain-text password, do you use https on your server?