feat(oauth): support Sign in with Apple by default + support postMessage API in InAppBrowser as available #374
Conversation
| @@ -347,7 +348,7 @@ angular.module('ng-token-auth', ['ipCookie']) | |||
| buildAuthUrl: (omniauthWindowType, provider, opts={}) -> | |||
| authUrl = @getConfig(opts.config).apiUrl | |||
| authUrl += @getConfig(opts.config).authProviderPaths[provider] | |||
| authUrl += '?auth_origin_url=' + encodeURIComponent($window.location.href) | |||
| authUrl += '?auth_origin_url=' + encodeURIComponent(opts.auth_origin_url || $window.location.href) | |||
There was a problem hiding this comment.
Apple does not support localhost domains for redirect as part of their OAuth implementation. This has practical implications when doing things in WKWebView proxied environments, where internal URLs are all localhost-based. This opts flag provides an escape hatch for a scenario such as this.
| # favor InAppBrowser postMessage API if available, otherwise revert to returning directly via | ||
| # the executeScript API, which is known to have limitations on payload size | ||
| remoteCode = " | ||
| function performBestTransit() { |
There was a problem hiding this comment.
Backwards-compatible change with DTA InAppBrowser handling. Check to see if the new authWindow implementation supports the cordova-in-app-browser's postMessage implementation, and if so, prefer that. executeScript has some limitations in payload size that may otherwise cause silent failures.
If the postMessage API is available, we will utilize our existing callback handler to retrieve the data.
If the postMessage API implementation is not available, default to returning the data directly through executeScript, as it did previously.
booleanbetrayal
changed the title
|
Changeset looks good to me. |
See related: lynndylanhurley/devise_token_auth#1347
See related: apache/cordova-plugin-inappbrowser#362