Auto log-in user on PWA app

It is possible to check standalone via JS (at least for Chrome and Safari, doesn't work in Firefox) - but unfortunately not from a service worker :(

So this info somehow needs to be passed from the controlled page to the SW, but postMessage is async so might not have happened when the manifest is requested.

One option could be to vary the SW URL (with a query param) depending depending if it is PWA or Non-PWA; the PWA SW could then intercept the manifest request and add a query param (or custom header) to indicate PWA context.
 
So I have this working, but it's not particularly as clean as I would have liked...

When the manifest file is created it puts a single-use token in the start_url. That token can be used once (it also expires if it's not used within 5 minutes). Visiting the start_url address (normally that would just be when the PWA app loads), it checks the token (if it hasn't already been used and hasn't expired), it will automagically log the user in (the user that retrieved the manifest file that the token was embedded into).

Here's what I don't like about it... since there isn't a way to tell the difference between a browser and PWA on the server-side, we end up generating a new single-use login token every time a logged in user requests the webmanifest file. It's probably okay (can't think of a realistic scenario where the start_url would be leaked to an unintended party), however I don't love the fact that the token exists when it's not needed (even if it's short-lived). I was able to mitigate this being needed most of the time because when the manifest file is requested, it does at least pass the referrer (so if the referrer has a single-use token, even if it's expired, we don't generate a new token because we are already in the PWA app presumably).

Additionally, I worked out all the other things I wish the PWA app did:
  • Use Sec-Fetch-Site header as replacement for CSRF (fallback to CSRF if browser doesn't support Sec-Fetch-Site) - prevent stale sessions causing security error (for example when you open the PWA app that has been idle for awhile). An "up to date" CSRF token is no longer needed.
  • Automatic refresh of badge counters when app is loaded/brought to front (I ended up applying this to the site as a whole, not just the PWA app). Like if your browser was minimized for hours or overnight and you bring that page to the front, it will update the counter badges (see above... we don't need an up to date CSRF anymore to do this in a secure way).
  • Give more prominent push notification permission message when initially loading app (put it up top and a little bigger rather than pinned to bottom... only applies to app, and even then only on the initial loading of it... if you ignore it and navigate to a different page, it goes back to being pinned to the bottom).
 
So I have this working, but it's not particularly as clean as I would have liked...

When the manifest file is created it puts a single-use token in the start_url. That token can be used once (it also expires if it's not used within 5 minutes). Visiting the start_url address (normally that would just be when the PWA app loads), it checks the token (if it hasn't already been used and hasn't expired), it will automagically log the user in (the user that retrieved the manifest file that the token was embedded into).

Here's what I don't like about it... since there isn't a way to tell the difference between a browser and PWA on the server-side, we end up generating a new single-use login token every time a logged in user requests the webmanifest file. It's probably okay (can't think of a realistic scenario where the start_url would be leaked to an unintended party), however I don't love the fact that the token exists when it's not needed (even if it's short-lived). I was able to mitigate this being needed most of the time because when the manifest file is requested, it does at least pass the referrer (so if the referrer has a single-use token, even if it's expired, we don't generate a new token because we are already in the PWA app presumably).

Additionally, I worked out all the other things I wish the PWA app did:
  • Use Sec-Fetch-Site header as replacement for CSRF (fallback to CSRF if browser doesn't support Sec-Fetch-Site) - prevent stale sessions causing security error (for example when you open the PWA app that has been idle for awhile). An "up to date" CSRF token is no longer needed.
  • Automatic refresh of badge counters when app is loaded/brought to front (I ended up applying this to the site as a whole, not just the PWA app). Like if your browser was minimized for hours or overnight and you bring that page to the front, it will update the counter badges (see above... we don't need an up to date CSRF anymore to do this in a secure way).
  • Give more prominent push notification permission message when initially loading app (put it up top and a little bigger rather than pinned to bottom... only applies to app, and even then only on the initial loading of it... if you ignore it and navigate to a different page, it goes back to being pinned to the bottom).
Slightly off-topic - How long until you get hired by XF or contracted? You're a missing asset to their puzzle and always contribute.
 
Slightly off-topic - How long until you get hired by XF or contracted? You're a missing asset to their puzzle and always contribute.
They don’t need me… And my currency is time, not money these days (so they would need to somehow pay me with more time in my life to work on my own projects). Also, they are some of the best devs I’ve seen, so I couldn’t contribute much from an engineering standpoint. 🤷🏻‍♂️
 
They don’t need me… And my currency is time, not money these days (so they would need to somehow pay me with more time in my life to work on my own projects). Also, they are some of the best devs I’ve seen, so I couldn’t contribute much from an engineering standpoint. 🤷🏻‍♂️
Time. I wish I could gain time too 😂 let me know if you find how.

You're being modest I think. Honestly. I don't doubt what you're saying but you do a tonne of good for this community with your knowledge and contribution, I could honestly see being an asset to them.

Anyways. Regarding this thread. Good suggestion. Will be installing your new addon later in the week.
 
Slightly off-topic - How long until you get hired by XF or contracted? You're a missing asset to their puzzle and always contribute.
There are some loyal XenForo users here who contribute quietly (meaning, without seeking praise) both by submitting bug reports (which, to me, are sometimes incomprehensible due to the presence of unfamiliar code :sneaky: ) and by supporting the forum. I would like to express my immense gratitude to them for their time and efforts. 👊
 
You're being modest I think. Honestly. I don't doubt what you're saying but you do a tonne of good for this community with your knowledge and contribution, I could honestly see being an asset to them.
Well… nothing I do is because I’m just super kind. I use XenForo for my own projects and the stuff I let others use is only a very small subset of the stuff I build on top of XenForo for myself. I just don’t have the time (there’s that thing again… hah) to support more of it.
 
There are some loyal XenForo users here who contribute quietly (meaning, without seeking praise) both by submitting bug reports (which, to me, are sometimes incomprehensible due to the presence of unfamiliar code :sneaky: ) and by supporting the forum. I would like to express my immense gratitude to them for their time and efforts. 👊
I wholeheartedly agree.
 
Well… nothing I do is because I’m just super kind. I use XenForo for my own projects and the stuff I let others use is only a very small subset of the stuff I build on top of XenForo for myself. I just don’t have the time (there’s that thing again… hah) to support more of it.
Its very much appreciated still and I'd say it's still very kind. Anyways. :)
 
Top Bottom