Persistence on the browser....

[royletron]

Hey guys,

So I have had a little play around with Dashport and I feel like I am missing something fundamental, which is how do we persist logins between requests? I see that my Google auth strategy works, I come back to the redirect and the the serialisation/deserialisation has done it's thing but I don't seem to have anything on the browser side - that means the next request appear unauthorised... Am I missing something here? Do I have to implement cookies/headers whatever myself?

Cheers team!

[sportelance]

Hey Royle!

Our session manager uses the browser's http object (by way of oak's ctx) to store your user's serialized id. It also stores that id locally. Authenticate, which should be getting called when trying to access a protected page, then checks that context object against the local id and bypasses the login process if there's a match.

Everything is functioning fine on my end so I'm drawing a blank on why it might be giving you issues. I'll do some more playing around, but if you could provide me with any more info about your setup that'd be greatly appreciated!

Since a couple people seem to be having issues, I'd be happy to hop on a zoom for 30 mins to troubleshoot to make sure we can resolve this issue and so I can better answer problems like yours in the future. Lmk your availability if interested.

[royletron]

Hi @sportelance I would be more than happy to have a chat. I will get back to you on times. I have done a little snooping and it seems that you are using the context.state from oak to add the session property which has the serialised ID - what I am not finding is anywhere that says that this is the right way to do it in oak - their documentation is a little poor. I set up a simple test - I added a simple middleware that logs the context.state calls next and then logs the context.state again. The theory being that the first call shows the state on the way in and then the second one shows the state on the way back to the browser. I then created a single GET route that will will attempt to set some dummy state context.state['hello'] = 'world' and then responds with a body that is just the stringified context.state.

// Logger
app.use(async (context, next) => {
  console.log("STATE IN", context.state);
  await next();
  console.log("STATE OUT", context.state);
});

const router = new Router();
router.get("/test", async (context: any) => {
  context.state["hello"] = "world";
  context.response.body = JSON.stringify(context.state);
});

My expectation is that if I hit this route twice I would first see an empty state on the way in, and a populated {hello: 'world'} on the way out, the second time I would see the previous {hello: 'world'} state on the way in, and the same on the way back, but I don't!

STATE IN {}
GET http://localhost:8000/test - 1ms
STATE OUT { hello: "world" }
STATE IN {}
GET http://localhost:8000/test - 1ms
STATE OUT { hello: "world" }

I actually just see the state coming in is always empty.

So then I started trying to work out what Oak is actually doing, I looked everywhere in the returned response from the first request, and I can't find a single thing that acts as storage on the browser - I would've expected a cookie because that's what most libraries do, but nothing:

HTTP/1.1 200 OK
content-length: 39
x-response-time: 1ms
content-type: text/plain; charset=utf-8

It's not much! So I guess I wonder how this works at all... it just looks like context.state is an ephemeral store for the lifetime of the request.... but not subsequent requests. I see this: https://deno.land/x/[email protected] which might be the answer - Redis backed session stores are pretty norm so I wouldn't worry about adding dependencies - although it would be good if you could choose your own data-storage.

[royletron]

PS I am new to Deno, but have a lot of JS experience and run a lot of HTTP services with a lot of Auth! I used to use Passport a lot, but we mostly roll NextJS these days and absolutely love https://next-auth.js.org - I'd love to assist if you wanted to go somewhere like that with Dashport

[sportelance]

That's really interesting! We store your serialized id at "ctx.state._dashport.session" and during testing I remember that trying to log ctx.state wouldn't show anything -- we needed to log ctx.state._dashport.