Server-Side Sessions

[queen mantle]

Hey,
We're doing some verification through creating sessions on the server-side, data is returned fine but I noticed the created sessions on the server-side can't be deleted with the #deleteSession method.

I did some reading into it and from what I understood AppWrite doesn't like handling sessions through SSR and all that is returned from the session creation promise is the data, just to double-check those sessions aren't persistent in ram, cache, etc., right?

And if it is persistent, then I have some worries about potential memory leaks, and I'd like to ask if there's any solution to deleting sessions created in SSR in the backend.

Thank you!

[lean wave]

Hey I am using Appwrite with many SSR apps and I am able to delete the sessions with account.deleteSession('current') or the session id. Where did you read that Appwrite doesn't like handling session thru ssr?

Dennis has a great video showing full SSR with Nextjs https://youtu.be/ENnG7GusuO4?si=ovwrJwRF7OCtljqi

https://github.com/divanov11/Nextjs-Appwrite-Auth-SSR/blob/main/src/auth.js

[queen mantle]

From what I read here, a member of the AppWrite team replied to this thread saying that creating sessions server-side don't persist https://appwrite.io/threads/1089618351527043223 and they recommended against SSR when possible

The error I get when using #deleteSession is "Error Logging in AppwriteException: [e-mail] (role: applications) missing scope (account)" which leads me to believe that it's consistent with what was being said in that thread.

[coarse marsh]

It could be, but that thread is over a year old, and before SSR was officially supported.

[lean wave]

as Kenny mentioned that was in the past, and things has changed since Appwrite 1.5.0 besides Dennis videos here's from the docs:
https://appwrite.io/docs/products/auth/server-side-rendering
https://appwrite.io/docs/products/auth/server-side-rendering#tutorials

here's all available official server sdk's
https://appwrite.io/docs/sdks#server

[queen mantle]

@coarse marsh @lean wave Hey guys, I understand and appreciate that things have changed since that thread, but like I've mentioned I've looked through the documentation and can't really find a clear answer to this:

Is the server-created authentication cached anywhere, or is it stored in ram, memory, etc. or anywhere where multiple users may be logged in from the backend cause a memory issue or does the function return the object and not store it anywhere?

Thank you!

[lean wave]

When you create a session from a server let's say nodejs, Appwrite returns a session token that you should handle/store however you want (the recommended approach is to store it in a secure cookie) and attach it to subsequent requests. the session returned from Appwrite respects the user/account roles and session settings you on your Appwrite instance (selfhosted or cloud) like the expiry etc...

is this what are refering to? or if you could explain your use case would be happy to help 🙂

[queen mantle]

In order to verify login through our security method we have to make an API request, and to verify the email and password (which we encrypt) on the server-side we use the #createEmailPasswordSession method using the node SDK.

This however, raised a red-flag that might be the fact that since on the client-side this is stored (through cookies/memory). I am scared that this may cause a memory heap pileup on the server-side which may have several performance issues on our servers.

Hence, I'm asking if I have to use the #deleteSession method to remove it from memory, or if AppWrite already handles this and not actually stores it in memory, as mentioned in the thread I referenced.

[lean wave]

To keep track of the sessions created I believe Appwrite stores that information in Appwrite db, each account can create a limited sessions before creating new one (which you can control from Appwrite console -> Auth -> Security) as shown in the first screenshot as you can see you can set the session length and limit which has no memory issues or at least I haven't experienced such thing in my ssr apps. If you don't use deleteSession Appwrite will automatically delete the session when it expires and return 401 exception. Also if your use case is to use short-time access for the user take a look a jwt that you can create on behalf of the user and ther're automatically destroyed I believe after 10 -15 minuts not sure exactly.

[queen mantle]

Thanks for the reply, however, the session limit of the user isn't what I'm trying to understand. I'm trying to understand if the session handled by the node SDK is stored in memory.

[lean wave]

the node sdk doesn't store the session anywhere. it just returns it from the Appwrite server it's our job to store it either on the server or somewhere else. sorry if i didn't not understand you correctly 🙂