PWA support on iOS 11.3

[nolanlawson]

Reported here:

PWA functionality does not play nicely yet on iOS11.3 because when adding an instance, Safari opens & gets the login cookie instead of the sandboxed PWA webview, so it cannot login.

[nolanlawson]

BTW my hunch is that this breaks for more than just Pinafore: any site that does an OAuth login should be hit by this. So I kind of suspect the WebKit team may move fast to fix this.

FWIW, PWAs on Edge on Windows 10 do not have this issue, nor do Firefox/Chrome PWAs on Android AFAICT.

[SpankyWorks]

I read a little bit about PWAs on iOS today and remembered seeing this issue. iOS apparently clears its data when the PWA goes into the background. Could be complicating the default OAuth process in the masto API?

For reference, here’s one of the articles I read: https://www.netguru.co/codestories/few-tips-that-will-make-your-pwa-on-ios-feel-like-native

[technopagan]

I'm quoting Maximiliano Firtman (@firtman) when asking him how to address the current limitations of PWAs on iOS 11.3 (see https://medium.com/@firt/progressive-web-apps-on-ios-are-here-d00430dee3a7):

I think storing the data in Cache Storage is the best solution to share between sessions and safari/webapp. Just save a JSON as a Response and get it back from cache

This might be a viable workaround to keep users logged in, but it does not address the issue of not even being able to complete the OAuth session.

[nolanlawson]

Sharing data between the main Safari app and the PWA is not a big concern to me as long as users can log back in. Edge on Windows has the same limitations for its PWAs, but at least the OAuth flow works.

If the OAuth flow doesn't work and data isn't shared between the main browser and the PWA app, though, then I'm not sure I see any workaround for this. 😕

[firtman]

To be honest, I didn't get exactly what was the issue. If it was a) passing data from Safari to the installed PWA (Web.app process), b) keeping data between PWA sessions or c) get back again from Safari after an OAuth login and keep the session details somehow in the PWA.

Right now, the only storage shared properly between Safari and installed PWA is "Cache Storage" (from the Service Worker spec). Therefore, as a hack, the OAuth final endpoint (rendered in Safari) can put in the cache a "fake" resource, such as in "./_private/data/session.json" creating a Response object with data. You then read that object from the same cache within the installed PWA; if the URL is in the cache you have the data and you can "import it" into the PWA context.

[nolanlawson]

OK thanks, that actually does sound like it might work.

BTW does anyone know if there is a WebKit bug or Radar for this issue? I can't seem to find it.

[firtman]

I'm not sure if this is a bug or a feature. Web.Apps and Safari had different storage contexts for years. Some bugs: https://bugs.webkit.org/show_bug.cgi?id=181849 https://bugs.webkit.org/show_bug.cgi?id=181850 Bugs links shared on Twitter https://twitter.com/tomayac/status/984290732499447808

[tomayac]

FYI, the login flow for Pinafore seems broken in general on iOS 11.4 Beta 1, not just limited to added to home screen. It shows the authorize/deny buttons, then stays there if I try to press either. Seems like the redirect flow isn’t working.

[nolanlawson]

I just tested in iOS 11.2.6 both in Safari and as a homescreen app, and the OAuth flow works. So this seems to be a new issue in 11.3. 😕

[tomayac]

I'm on 11.4 Beta 1 actually.

[MarcoZehe]

I’m on 11.4b1 as well, and the OOAuth flow is definitely broken for me.

[technopagan]

I can confirm the OAuth workflow working correctly on iOS11.3, stock Safari browser, as long as I don’t use a Webview as is used when coming from Add-To-Homescreen.

I’ll try another Webview mode (called “Sidefari”) next to see if this breaks the OAuth flow, too.

A comment from one of trivago’s PWA developers: the PWA OAuth login issue is probably unfixable on iOS11.3 and it needs fixing by the Safari devs. His suggestion is to provide an alternative login mechanism if possible.

[technopagan]

Just tested OAuth inside a normal Webview and can confirm the OAuth workflow working correctly for it on iOS11.3. So I think we are looking at two different issues:

1. OAuth workflow being broken on iOS11.3 when using the PWA after doing Add-To-Homescreen

2. OAuth workflow broken on iOS11.4 Beta 1 Safari as reported by @tomayac & @MarcoZehe

[MarcoZehe]

Oops, correction: In Safari, the ooauth workflow works in 11.4pb1 for me. It is really only the PWA added to the home screen and trying to add an instance that still does not work for me in 11.4pb1.

[technopagan]

Thanks @MarcoZehe!

So we’re only looking at one specific issue: you currently cannot use Pinafore as a PWA (via Add-To-Homescreen) on iOS 11.3 or above due to the current limitations of Apple’s PWA implementation. What breaks is the OAuth flow due to the sandboxing of the PWA.

[technopagan]

Maybe @addyosmani, @tomdwyer or @firtman or another person with in-depth PWA knowledge has an idea if there’s anything that can be done inside Pinafore to make this work.

Otherwise, all that remains might be to +1 this issue in the Safari issue tracker.

[ram1225]

We are also facing the same issue. i.e. OAuth flow breaks in iOS 11.3 in PWA.
Should we have to wait for Apple developers to fix this?

We have reported the issue at https://discussions.apple.com/message/33306161#33306161 .

[nolanlawson]

Thanks @technopagan for the details. I looked a bit into window.open() or an embedded iframe as an alternative to document.location.href = ..., but this has security implications (window.opener, iframe CSP), it might trigger popup blockers, and I also have no evidence that it would even fix iOS or work with Mastodon's existing OAuth implementation. So it seems to me there is indeed no workaround.

To clarify: the data issue is not a problem for me. Edge has exactly the same data model (installed PWAs are sandboxed with their own storage), but it's fine because users can just log in again when they install a PWA. On iOS 11.3+ they can't, because when you do document.location.href = <other origin>, it opens in Safari instead of in the PWA.

I'm inclined to just wait for the WebKit team to fix this, unless there is some simple workaround that doesn't affect security / popup blockers / UX / etc.

[MaksymKarpenko]

How can I pass data from Safari to the installed PWA ( Process Web.app)? Is it possible?

[tomayac]

I've just filed https://bugs.webkit.org/show_bug.cgi?id=185400 that tracks this.

[socceroos]

@tomayac I don't think the unload issue has anything to do with the OAuth workflow issue. When going through OAuth workflow, it redirects to Safari and never redirects back to the PWA - unloaded or not.

[nikolaydyankov]

I found this discussion from google and I'm not part of this project, but I managed to fix this by removing the manifest meta tag:

<link rel="manifest" href="/tracker/site.webmanifest">

Hope it works for you too, wasted 2 days trying to find a solution.

[nolanlawson]

Unfortunately that would disable PWA support for non-iOS platforms. Wish there was a way to just disable it for iOS. 😕

[tomayac]

One super ugly idea might be to (temporarily until this gets fixed) do something along the lines of the loadCSS folks. Their approach is:

<link rel="preload" href="path/to/mystylesheet.css" as="style" onload="this.rel='stylesheet'">

You could try the following instead:

<link rel="preload" as="fetch" href="manifest.json" onload="if !(/^((?!chrome|android).)*safari/i.test(navigator.userAgent)) this.rel='manifest'">

Not tested, just an idea. In theory this should only make this to link[rel="manifest"] on non-Safari browsers. The regular expression is from StackOverflow. Did I say this is ugly?

[firtman]

With JS (ES5 just in case) you can remove the manifest on iOS with

var manifest = document.querySelector('link[rel=manifest]');
if ('standalone' in navigator) manifest.parentNode.removeChild(manifest);

Also, you can change it to a different one, with display: browser

if ('standalone' in navigator)  document.querySelector('link[rel=manifest]').href='manifest_ios_url';

[gitsupersmecher]

Did anyone find an workaround for this? I read the above "workaround" about saving the data in the "Cache Storage", but it cannot work, it seems to me a security issue and I don't see Google Auth taking this path.
If anyone has found a solution then it would be great to share it.

[socceroos]

@gitsupersmecher I implemented a workaround based on generating a UUID on the client, and redirecting to an external login page hosted elsewhere. The external login page logs the user in and temporarily (5 minute window) saves the auth result in the DB under the UUID. The client then accesses this UUID in the DB when it is re-loaded and uses the result to log the client in.

[gitsupersmecher]

@socceroos - thank you for providing this solution and for the quick reply! It looks good, I will try it.

[firtman]

It's not Google Auth who needs to do the trick but your app after it recieved the login Auth token. Storing in Cache Storage or IndexedDB seem to have the same security risks withou a deeper analysis. It's the only storage shared between Safari and the standalone app unfortunately. These issues are forcing some PWAs such as Starbucks to use a server side user agent sniffing technique to provide display: browser to iOS users.

…

On Mon, Jul 30, 2018 at 14:14 SupSm ***@***.***> wrote: Did anyone find an workaround for this? I read the above "workaround" about saving the data in the "Cache Storage", but it cannot work, it seems to me a security issue and I don't see Google Auth taking this path. If anyone has found a solution then it would be great to share it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#45 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABQ_WRlfkWFDquS9eyxeSMThNikBO6GSks5uLog-gaJpZM4TNBmo> .

[davegariepy]

I have just run into the OAuth redirect problem for my web app. I'm using create-react-app with AWS Cognito Hosted UI for social sign on for Facebook.

1. user adds the app to homescreen on iOS
2. clicks sign in which sends them to AWS hosted URL
3. sign in with facebook
4. redirect does not send back to web app

opening the web app restarts that process.

The only way I have gone around it now is to disable PWA as @nikolaydyankov mentioned. Bummer!

[charlesvestal]

In the interim, some mastodon apps (like whalebird on macOS) request a token to be pasted, rather than the redirect. Could the iOS pwa app request that pathway?

[firtman]

Instead of pasting manually you can always save it as a Response object within the Cache Storage API and then retrieved it in the standalone app through a fetch. That storage is shared between Safari and the standalone app

…

On Sat, Aug 11, 2018 at 13:03 Charles Vestal ***@***.***> wrote: In the interim, some mastodon apps (like whalebird on macOS) request a token to be pasted, rather than the redirect. Could the iOS pwa app request that pathway? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#45 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABQ_WWy_WtOPVzcWHOyyJPe3w0LIGoHXks5uPwA9gaJpZM4TNBmo> .

[socceroos]

Just to add to @firtman's comment, obviously check your security requirements closely before putting a possibly long-running token in the cache. This goes for any work-around solution to the auth problem. 👍

[jvitor83]

Same as firebase/firebase-js-sdk#77 (comment)