Refresh JWT via REST

Hello. Should it be possible to create new JWT via REST, using current valid JWT?

I'm trying to execute POST http://localhost/v1/account/jwt with X-Appwrite-JWT containing the latest JWT, but I'm getting this error:

{message: 'The current user session could not be found.', code: 404, type: 'user_session_not_found', version: '1.2.0'}

Hmmmm, afaik, it has to be attached to a session. You won't be able to create new JWTs with existing JWTs. These are really meant to pass to Server SDKs to perform actions on your behalf.

I see. Well, the argument can be made that creating new JWT is the action on my behalf, so the server should be able to do it. 🙂 But I see how that migth be a bad idea from the security standpoint.

Can you advise how to maintain the valid JWT inside service worker, since the client SDK doesn't work there?

Service worker?

Hmmmmm

Like this isn't somehting client facing

right?

Use an API key

https://appwrite.io/docs/keys

If it is client facing, you should have an active session 😉 If it's like a background tasks that persists, API keys are your friend.

Bottom of your overview page

Yeah, I understand both workflows. The service worker I'm talking about is a browser extension background process, so it's technically a client facing code. I believe api key cannot be used in this scenario. I wonder if there are any recommendations on how to use appwrite from a browser extension. 🤔

@VincentGe Thank you for help. I will keep poking around. 🙂

What you're facing would be the same as frameworks using SSR like sveltekit, NextJS, nuxt, etc.

This might be helpful: https://discord.com/channels/564160730845151244/564160731327758347/1075481441791639683

In short, you need the service worker to use the session cookie

👀 is this actually advisable?

Ideally we wrap it with something that would make it easier but I don't think we've had the time to build that

👀 I guess we can propose it as a temporary work around

Thanks. Actually I have a nextJS app too, where I do something like this. I went through @Meldiron very helpful examples, and I was able to make it work for NextJS. It's just my current use-case is different due to the browser extension service worker constrains. There is no, traditional request/response cycle like in SSR. In this case it's an isolated long-living process, which I want maintain user session in. Both appwrite and node-appwrite failed to run there, but that's for another time. Anyways, I'm gonna look into this later and update you on my findings 🙂

You could manually log in using fetch, grab the cookie, and store it

I ended up doing it somewhat similar to NextJS SSR flow. Sent credentials to the background SW via runtime messaging, created session, captured x-fallback-cookies header and stored in the chrome storage. After that set up timer to refresh JWT periodically using chrome alarms.