cordova-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Trainor (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CB-11045) Use the custom CDVWebViewEngine and add automatic cookies sharing
Date Tue, 20 Mar 2018 17:01:00 GMT

    [ https://issues.apache.org/jira/browse/CB-11045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16406532#comment-16406532
] 

Jim Trainor edited comment on CB-11045 at 3/20/18 5:00 PM:
-----------------------------------------------------------

Here is what I do, and it is working well, and is what I believe is a fairly standard approach:
 # Pop out to Safari, or  an SFSafariViewController for your login. The latter is preferred
(and required by Apple, they'll reject if you are needlessly opening the Safari app).
 # Complete your login in Safari and then make an http call to generate a Json Web Token on
your server. The call to create the JWT originates from the login web page and carries the
login authentication cookie. The server uses the cookie to authenticate the user and generate
the JWT. After this you don't need the cookie.
 # Implement a url open handler for your iOS app.
 # Pass the JWT token to your app via the open handler url (as a query parameter). (e.g. open
a link such as myapp://?token=xyz123abc456.
 # Save the JWT and pass it back to your server in the Authorization header.

If you don't like the idea of using a JWT token and the Authorization header then it is possible
to move a cookie through a server connection, i.e. capture the cookie on the server, and then
the app connects later and the cookie is returned on the new domain. I experimented with a
solution like that and it worked, but it's untidy and not as secure as simply generating
a JWT and handling it to the application via a local application url open. Also, the cookie
approach has problems, potentially, with XHR requests. The JWT and Authorization header approach
has no XHR problems because you are in complete control of the Authorization header.

Good luck.


was (Author: jptrainor):
Here is what I do, and it is working well, and is what I believe a fairly standard approach:


 # Pop out to Safari, or  an SFSafariViewController for your login. The latter is preferred
(and required by Apple, they'll reject if you are needlessly opening the Safari app).
 # Complete your login in Safari and then make an http call to generate a Json Web Token on
your server. The call to create the JWT originates from the login web page and carries the
login authentication cookie. The server uses the cookie to authenticate the user and generate
the JWT. After this you don't need the cookie.
 # Implement a url open handler for your iOS app.
 # Pass the JWT token to your app via the open handler url (as a query parameter). (e.g. open
a link such as myapp://?token=xyz123abc456.
 # Save the JWT and pass it back to your server in the Authorization header.

If you don't like the idea of using a JWT token and the Authorization header then it is possible
to move a cookie through a server connection, i.e. capture the cookie on the server, and then
the app connects later and the cookie is returned on the new domain. I experimented with a
solution like that and it worked, but it's untidy and not as secure as simply generating
a JWT and handling it to the application via a local appllication url open. Also, the cookie
approach has problems, potentially, with XHR requests. The JWT and Authorization header approach
has no XHR problems because you are in complete control of the Authorization header.



Good luck.

> Use the custom CDVWebViewEngine and add automatic cookies sharing
> -----------------------------------------------------------------
>
>                 Key: CB-11045
>                 URL: https://issues.apache.org/jira/browse/CB-11045
>             Project: Apache Cordova
>          Issue Type: Wish
>          Components: cordova-plugin-inappbrowser
>         Environment: iOS, Android
>            Reporter: Masmejean Jonathan
>            Priority: Critical
>              Labels: CDVWebViewEngine, android, cookies, inappbrowser, ios
>
> Hello,
> With the new version of cordova-lib (>=5.4.x), cordova-ios (>=4.x) and cordova-android
(>=5.2.x) you have the ability to choose a WebView engine for your app. 
> On iOS, you have the ability to use the new WKWebView engine and for Android you can
use for example the CrossWalk WebView which use the latest chromium WebView for android.
> At the moment, with InAppBrowser plugin you are using the default/old/basic WebView system
(UIWebView or Chromium 4.4 WebView). So, for every users that need/want to use the new WebView
system for their app encounters a lot of issues, especially with cookies sharing functionality...
Which is really sad when you are using an external Authentication system (like Keycloack)
to log you users in or out, and when you are using secured iFrames that need cookies to bet
set on your app.
> It could be great to make the InAppBrowser plugin use the CDVWebViewEngine everywhere
and had automatic cookies sharing between the app and the popup (and vice versa). 
> That should avoid the merge and fix the https://github.com/apache/cordova-plugin-inappbrowser/pull/122
issue.
> Have you planned to use this new engine already ? If it is the case, when do you think
it will be released ?
> Thank you for you time.
> Regards.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@cordova.apache.org
For additional commands, e-mail: issues-help@cordova.apache.org


Mime
View raw message