Collection where Users have 'Read' Permission Won't stream Realtime Events to Authenticated Users.

[rich burrow]

I set up a Realtime subscription to an Appwrite collection with the following permissions:

any:  [create: F][read: T][update: F][delete: F]
user: [create: T][read: F][update: F][delete: F]

The subscription worked as expected, and the Realtime connection got a response whenever a document was created, updated, or deleted in the collection.

However, then I updated the permissions, so only users could read documents in the collection:

user: [create: T][read: T][update: F][delete: F]

After that, no CRUD change in the collection triggers a Realtime event, despite being authenticated as a user.

I confirmed that my client is properly authenticated when setting up the Realtime subscription by testing the ability to fetch documents using databases.listDocuments() with databases instantiated by the same client that subscribes to my collection's channel with Realtime, successfully.

Document-level security is enabled in both scenarios (with the same settings). My client and server code is also exactly the same in both cases (and it's designed to unsubscribe from Realtime and subscribe with a new client instance whenever there is a change in authentication state). The only thing that changed was the collection’s read permission from any to user.

I also tried subscribing to more generic Realtime channels such as documents to receive any changes across the board. Even then, I didn’t receive any events when the permission was set to user.

Expected Behavior:
When the read permission for the collection is set to user and I am logged in as an authenticated user, I should still receive Realtime events for create, update, and delete actions (just as I do when the read permission is set to any).

Request for Support:
Is there something I'm missing, or is this a potential bug in Appwrite's Realtime handling when user permissions are involved?

Any insights or suggestions would be appreciated.

Thank you for reading!

[flint gate]

Can you check the network logs from the browser dev tools? Switch to the web socket tab and look for the connection when you call subscribe. The web socket should start and there should be a few messages. One of the messages should be an auth one and then after that, the user. Do you see that?

[rich burrow]

Yes, I see a message from the Realtime websocket connection, but not an auth one. Also, user is null.

[flint gate]

This means the connection is unauthenticated. How are you authenticating? What's your tech stack?

[rich burrow]

Tech stack is just Nuxt and Appwrite:

"nuxt": "^3.13.2", "node-appwrite": "^14.1.0", "appwrite": "^16.0.2"

I'm doing SSR auth and then returning the session cookie from my API endpoint to the client when authenticated. I then use that cookie to authenticate the client-side Appwrite instance that goes on to establish the Realtime connection.

// /app/utils/appwrite.ts

import { Account, Client, Databases } from 'appwrite'

export function createClientSideSessionClient(sessionCookie: string | null) {
  const runtimeConfig = useRuntimeConfig()

  const client = new Client()
    .setEndpoint(runtimeConfig.public.appwriteEndpoint)
    .setProject(runtimeConfig.public.appwriteProject)

  if (sessionCookie)
    client.setSession(sessionCookie)

  const account = new Account(client)
  const databases = new Databases(client)

  return { client, account, databases }
}

I'm not really using this client-side client for anything other than Realtime (all requests to data in my Appwrite collections are handled by server-side Appwrite client instances). But, I modified my client-side Appwrite util to return account and databases to test the auth status of my client-side instance.

Both account.getSession('current') and accessing a collection where only users have read permission with databases.listDocuments() return the current session and the list of documents, respectively, suggesting the client-side instance was successfully authenticated.

Only Realtime doesn't seem to recognize the authed status of the instance.

I am currently developing in localhost only and my Appwrite endpoint is https://cloud.appwrite.io/v1, so I couldn't configure the session cookie to be automatically sent to Appwrite in addition to localhost.

[flint gate]

SSR that's probably the problem then. The cookie isn't set up client side to send to Appwrite. And neither is the fallback cookie

[rich burrow]

I see. But then why am I able to execute all other operations that require an authenticated user with that same client-side Appwrite client instance? Only Realtime isn't recognizing the instance's authed state.

[flint gate]

I don't think realtime supports that set session approach. Feel free to create a GitHub issue requesting that

[rich burrow]

Thank you. I've created an issue:
https://github.com/appwrite/appwrite/issues/8925

Until that is fixed, the only solution for people doing SSR auth who can't yet configure their Appwrite endpoint to a custom domain is to reimplement auth client-side to make an authenticated connection to Realtime, right?

[little summit]

For anyone that come across this issue, I have created a work around here: https://github.com/appwrite/appwrite/issues/8925#issuecomment-2747349916

[wide nova]

THANK YOU @little summit .. i adapted this to sveltekit and its working a treat..