Read-Only Tokens

By default, Y-Sweet’s client tokens authorize a client to read and write to a document. For use cases where a client should only have read access to a document, Y-Sweet supports generating read-only client tokens.

When creating a client token using the @y-sweet/sdk package, pass an options object with an authorization field set to either 'full' or 'read-only'. E.g.:

import { DocumentManager } from '@y-sweet/sdk'
 
const manager = new DocumentManager(process.env.CONNECTION_STRING)
const clientToken = await manager.getOrCreateDocAndToken(docId, {
  authorization: 'read-only' // is 'full' by default
})

The resulting clientToken will have an authorization field that the client can use to decide how the UI should look or to enable/disable client-side functionality as necessary. Note that mutating the client token’s authorization field won’t affect the token’s level of authorization. Any document mutations attempted with a read-only token will be ignored on the server and will not be synced with other clients or persisted to storage.

Gotchas

There are a few gotchas to be aware of when using read-only client tokens:

1. Read-only tokens cannot prevent local mutations to a YDoc.

Read-only tokens can only prevent local changes from being synced to other clients or persisted to storage. A client with a read-only token may still make changes locally, so applications will likely want to disable local edits when the clientToken’s authorization field is 'read-only'.

2. Read-only tokens only prevent syncing changes via the Y-Sweet server.

If you are using other Yjs Providers or other sync channels, a read-only client may be able to have their changes synced to a read-write client’s document which in turn may sync the unauthorized changes with the Y-Sweet server. If you have offlineSupport set to true in the YSweetProvider, read-only tabs may be able to sync their changes to a read-write tab. You don’t need to worry about this if you expect all a client’s tabs to use the same authorization level.