Email or username:

Password:

Forgot your password?
Top-level
Darius Kazemi

@sean if I'm understanding you right, yes, the localstorage method is how I handle it

7 comments | Expand all CWs
charlag

@darius @sean in any case I would say store locally

Sean Tilley
@darius got it. So, it sounds like I should maybe update my API calls so that there are public and private versions. Public uses no bearer token, and is the default unless somebody is authenticated, at which point their localstorage token is used in the authenticated version of the call.

Thinking on it, maybe the calls can have some if-else logic to detect whether a user is logged in, so that I don't have to double-code everything. 😛
@darius got it. So, it sounds like I should maybe update my API calls so that there are public and private versions. Public uses no bearer token, and is the default unless somebody is authenticated, at which point their localstorage token is used in the authenticated version of the call.
Darius Kazemi

@sean exactly the first thing you said. The if/else thing could work but it's unusual for an endpoint to give two different results (other than say 200 vs 401) when authenticated or not. Typically you would render a different view template if logged in that accesses a different set of endpoints.

Darius Kazemi

@sean so you would have some api calls requiring a bearer token from localstorage, and some that work unauthenticated

Sean Tilley
@darius cool, in a nutshell that's what I'm thinking of doing.

There seems to be some warning against storing tokens in the browser, so I'm exploring what other way this might be done securely. 😅
Darius Kazemi

@sean what sort of warning? It's standard practice for OAuth

Darius Kazemi

@sean some tokens should not be stored, but others are designed to be

Go Up