Yes, but when the server does not send the token as cookie the only option is to store it with JavaScript. And yes, that also means (any) JavaScript can access the token.
Thanks for the insight! If anyone cares to provide any clue about best practices and how to handle token storage, you are more than welcomed to provide any insight.
I've been looking at this for months without getting a clear, noncontroversial answer.
Even with this documentation, it is still unclear what to do if you have a SPA on another host than your backend (so you can't use cookies), and you do not want to use server sessions.
Using `oidc-client` from the frontend could work, but that bundle size[0] is absolutely insane.
In short, being able to scale to as many requests as your CDN can handle, with none of the operational overhead of a traditional web server, is really really nice.
Thanks for that post. That is impressive that you went with the best/fastest tech available today rather than just leverage what was done with Harrys. I am interested with what you actually used for the e-commerce part of it. Are you interacting with your systems that you made for Harrys with GraphQL or did you use a JAM stack orientated solution like gocommerce?
Thank you! We have plans to build many more frontends in the coming years, so it felt like an appropriate time to step back and see what other solutions were out there.
For the e-commerce part of it, it's a custom API written in Scala that handles our inventory, warehouse, and fulfillment needs. As well as interfacing with Stripe for actual order processing. Want to get that team to write their own blog post as several people have asked about it!
You could probably proxy a file through your own server and add any headers you like. But in that case browser cannot use a version of a script cached at other sites.
