_pwa=1, have it be _pwa={some sort of token unique to the user that can log them in automagically} (if it's a logged in user) and then use that token.
Because on iOS when you install the PWA, you end up with an app that you aren't logged into. Probably something to do with iOS keeping "apps" isolated from each other (a PWA app isn't going to be sharing cookies with a browser app for example). Just a guess on the "why", but that makes sense to me knowing how iOS sandboxes apps and their data from each other (a PWA isn't going to inherit any cookies from a browser [and vice versa] because an app can't read another app's data).
Ya would definitely need to be single use and expiring as well. Basically just a mechanism to do the initial login is all. After that, the PWA has its own user/session cookies.Thanks for the explanation
In this case a one-time token would indeed make sense, though I wouldn't feel comfortable if the token could be used more than once.
jakub-kozak.medium.com
firt.dev
Not sure if relevant but the manifest now
If memory serves (and it very well may not), the issue was Google distributing a single WebAPK for all users (and any manifest changes are detected as updates that should be pushed to all users). And this "implementation detail" was buried in some issue tracker somewhere rather than being properly documented, so I'm not sure if that still is (or ever was) entirely accurate.
Did a basic test and it doesn't look like localStorage is shared between Safari and PWA app in 16.4.
developer.mozilla.org
Sorry, I meant CacheStorage. But also my test was thrown together in about 30 seconds, so I may have missed something.
Was reading more documentation on the id property (which Safari supports), and it does seem to me that using id as the unique identifier and back to my original idea for a single-use/expiring token in the start_url might be the best route.
firt.dev
developer.chrome.com
I believe older versions of Chrome used the
start_url to uniquely identify a PWA, and newer versions use the id and fall back to the start_url. I still don't think you can have multiple instances with the same identifier, but I imagine you could work around this by varying the identifier if you really wanted to (probably a niche use case).As far as I know Android doesn't have this problem to begin with because it shares cookies/caches between Chrome and the PWA, so you maintain the session when you install it already. So we'd only really need to vary the manifest for Safari, which I suppose is technically feasible if there's no solid alternative.
Ya, that was my understanding too.
Ya, although I'm not sure you'd want to to put an onboarding token all the time for Safari... Just initially when the user is logged in but not already in PWA mode. Seems like generating new/spewing out unnecessary tokens whenever the manifest is requested from the PWA (like to check for an update) could be a potential security risk/attack vector. At that point maybe it's better to just do the same handoff mechanism (if token exists, ignore cookies and use single-use token), and then the manifest falls back to not having a token when requested by an existing PWA instance. The bonus of that would be that it would still work on Android or other platforms if they ever take a more sandboxed approach to PWA (I could see that happening someday with all the privacy changes happening in the world).
Hmm ... how would you distinguish a "PWA Manifest Request" from a "Non-PWA Manifest Request" (which should contain the token)?
Not sure, I doubt it's as easy as a different user agent, but I haven't looked into it. I know you can detect standalone mode via JavaScript, so it could probably be done with some creativity within the service_worker.js where you intercept the request, check if it's PWA and add something to the request.
