|
|
|
|
|
by paradite
969 days ago
|
|
I know this is a replacement for cookie, but some web apps use JS and sessionStorage on browser to store session token instead of using cookie. This protocol seems to also depend on JS to do client side cryto logic and adding HTTP headers. Unless by browser/client it means the actual browser, which would take ages to get implemented across all user agents. In which case, it would likely be polyfilled by JS first as the de facto standard of doing things. I wonder how this compares to using sessionStorage. |
|
It doesn't mention any dependency on JS, there's pseudocode in Python to demonstrate generating/using the token.
> but some web apps use JS and sessionStorage on browser to store session token instead of using cookie
This is particularly strange, I've seen that frontend apps do this but I can't understand why because it's error prone and excellent attack vector. It boils down to emulating cookies, having to have some sort of request interceptor that includes the token on every XHR/fetch to serverside and another interceptor that saves updated token on every valid response from serverside. It seems like a misguided attempt to rectify problems that stem from CORS handling or shortsighted design where auth was bolted on as an afterthought.