[
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-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
