Define Auth Methods

[stresslimit]

Need to decide what we move from the auth module into this library.

Definitely API calls & URIs, but also JWT storage?

Q: should auth methods return JWT, or also deal with storing and retrieving jwt from local storage? I'm tempted to say it basically returns true/false and does all localStorage work for you.

If we do want to make it super easy to use library, we should probably at least provide the option to have the library magically take care of this for the developer. That means actually calling .then() on the fetch response. Is this cool? Possible? Do we need top-level methods for login vs simpleLogin so that developers can implement their own auth UX?

[anru]

Now localStorage is not used at all actually. Auth methods save all data (jwt and user info) in redux state. So, where our auth methods will be ? In terms of layers.

I want just show workflow with JWT, how it used now:

1. At server side JWT retrived from cookies and being writed to redux state.
2. Later redux state at server hydrated into client side.
3. At client side we can use existing JWT from redux state or get new via authentication methods.

So if we want handle passing jwt in methods which requires authorization in foxcomm api internals, we need some unique context for this, for example via instantiating instance with JWT token:

const fcapi = new FxC(jwt)

Without that we forced to pass jwt explicitly:

FxC.checkout(jwt, ....);

Thouths, comments ?

[stresslimit]

where our auth methods will be ? In terms of layers.

This is exactly the question!!

First, I saw this https://github.com/FoxComm/firebird/blob/master/src/node_modules/modules/auth.js#L45 and just assumed we were using the value.

My thinking was, one model could be that if api-js handles auth from end to end, including saving to localStorage, and then either getting from localStorage or keeping local state...

The other model is to keep jwt in global app state, which would mean keeping auth at the higher layers... There are trade-offs here, the top-level app would re-implement a bunch of auth boilerplate that I'd love to abstract. What do you think are the options here?

[stresslimit]

The other thing we could do process-wise is continue to be incremental: move just simple API calls down here for now, then as we explore the more complex separation of Storefront & Client we may find ourselves re-using patterns that will make this clear.

[anru]

I like that idea. In general we should figure out how solve passing jwt in "multiple requests/jwt" environment (at server side) problem. Obvious and most simple is just pass jwt everywhere where it needed.