I do SSR auth. What's the best way to set up an authenticated client-side Realtime connection?

I am currently handling authentication entirely server-side via an /api/auth endpoint, so I don't have any Appwrite client instances running client-side.

However, Realtime requires being authenticated on the client side to stream events the user has access to.

My challenge is how to leverage the SSR auth I already have in place to securely authenticate a client-side Appwrite instance to subscribe to Realtime events. So far, I see two possible approaches:

1. Return the session cookie in my server's /api/auth endpoint response and use it to authenticate the client-side Appwrite instance.
2. Reimplement client-side authentication, separate from my current SSR setup, to authenticate the Appwrite client directly.

For the first approach, I'm concerned that exposing the session cookie to JavaScript (even if it was originally set as httpOnly) opens up security vulnerabilities to XSS attacks or malicious browser extensions. For the second approach, it feels like a step backward in terms of developer experience. Additionally, maintaining both SSR and client-side authentication seems to violate DRY principles.

What’s the best approach to securely set up an authenticated client-side Appwrite Realtime connection without giving up on SSR auth?

i would suggest creating a cookie that will be sent to both your backend and Cloud. So in order to do that, assuming your have:

• appwrite endpoint: appwrite.myapp.com
• app: myapp.com

you'll need to create a cookie with

• name: a_session_<project id>
• domain: .myapp.com

I'm pretty sure the cookie will be sent to both your myapp.com and appwrite.myapp.com

Hi Steven, thank you for your response and suggestion.

I do currently have an implementation that gives me access to the session cookie on my backend and on the client. I am just concerned about the potential security risks of returning the session cookie to the client as part of my endpoint response (which theoretically makes it JavaScript-accessible, unlike returning it as a secure set-cookie header configured to be httpOnly).

Another concern I have is that having an authenticated client-side Appwrite client instance (necessary to subscribe to Realtime events) eliminates the control I have over filtering and transforming the data I return to users through my Nuxt server functions. If clients can communicate directly with my Appwrite database without a server endpoint as an intermediary, the only control I have over what they get are explicit Appwrite resource permissions, which are a great baseline, but not as flexible as custom functions. But, I guess that's a different topic altogether. The only issue I currently have with the sharing of the session cookie approach is the risks it opens up.

you can make it so it's not accessible by javascript client-side