2

I am working on implementing a service worker which caches and serves an app shell to certain routes on my site.

I am running into a problem in that the route can sometimes (based on a query parameter, say) cause a redirect on the server side. However, once the user is being served an app shell, they never actually hit the server again, and the redirects aren't happening.

This seems like a problem inherent to app shells. Looking for thoughts and guidance on handling cases like these.

Additional details for clarity:

  1. User hits https://www.example.com
  2. Service worker is installed, subsequently serving an app shell for the / route
  3. Some time later, the user hits the site again, but their account has been flagged for a security review. Normally, the server would handle this redirection, redirecting the user to, for example, https://www.example.com/account/security
  4. However, due to the presence of the app shell, the server has no opportunity to perform such a redirect.
Mike
  • 3,331
  • 2
  • 18
  • 22
  • Does getting https://github.com/GoogleChrome/workbox/issues/631 deployed into a production version of Workbox address your use case? We've been planning on cutting a new minor release soon. Or if the problem that you're not sure how to start including the query parameter in your navigation URLs once the App Shell takes over? – Jeff Posnick Jun 30 '17 at 18:21
  • @JeffPosnick right now we're manually doing in sw-precache what the above change will allow us to do in Workbox. But there's still an open question in my mind about how you handle purely server-side redirects, like reading from the server's session storage and redirecting based on something there. – Mike Jun 30 '17 at 18:41
  • The answer can't be as cut and dry as "implement the same routing logic on the frontend", can it? If so, it seems like a non-starter for teams like ours that have massive amounts of redirect logic built into their server-side routing. – Mike Jun 30 '17 at 18:43
  • In that scenario, it sounds like you'd need to have the client ask the server periodically (perhaps every time there's a History API navigation), via a lightweight `fetch()`, whether there's a reason to go to a special page. And then if the server responds yes, we need to redirect, you can explicitly set `location` to the security checkup URL, which is blacklisted from App Shell navigation. – Jeff Posnick Jun 30 '17 at 23:15

1 Answers1

0

(Promoting this from the comment section. It's not the only possible approach, but depending on how comfortable you are with running the redirect logic via client-side JavaScript, it should accomplish what you describe.)

In that scenario, it sounds like you'd need to have the client ask the server periodically (perhaps every time there's a History API navigation), via a lightweight fetch(), whether there's a reason to go to a special page. And then if the server responds yes, and you need to redirect, you can explicitly set location to the security checkup URL, which should be blacklisted from App Shell navigation.

Jeff Posnick
  • 53,580
  • 14
  • 141
  • 167