Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HocuspocusProvider parameters are ignored when websocketProvider is set #659

Closed
martindzejky opened this issue Jul 25, 2023 · 4 comments
Closed
Assignees
Labels
bug Something isn't working

Comments

@martindzejky
Copy link

Description

When creating a new HocuspocusProvider, if a websocketProvider is set, the parameters are completely ignored:

const provider = new HocuspocusProvider({
    websocketProvider: collaborationProvider,
    name: resourceId,
    token: collaborationToken,
    parameters: {
        readOnly: readonly || false, // <-- ignored
        templateId: collaborationTemplateId, // <-- ignored
    },
});

I'm not 100% sure whether this is a bug or it is intentional, given the implementation (config parameters are only used when creating a new provider):

parameters: websocketProviderConfig.parameters,

Steps to reproduce the bug
Steps to reproduce the behavior:

  1. Create a new HocuspocusProviderWebsocket
  2. Create a new HocuspocusProvider and pass the websocketProvider
  3. Set parameters on the provider
  4. Observe that on the server, requestParameters are empty {}

Expected behavior
I would expect that I can pass request parameters separately for each document connection. The documentation is not fully clear how to use the providers in multiplexing so perhaps I'm not doing this correctly?

What I want to do is to pass extra data for a document connection, such as whether it should be in readonly mode or what template ID (a separate string) to use for the document. If parameters are not supposed to be used for this, then first - please update the docs to make this more clear - and second, how should I implement this? Should I just add this info into the name? I.e. name: "${resourceId}?readOnly=${readOnly || false}&templateId=${collaborationTemplateId}"

Screenshot, video, or GIF
N/A

Environment?

  • operating system: N/A
  • browser: Chrome
  • mobile/desktop: desktop
  • Hocuspocus version: v2.2.3

Additional context
N/A

@martindzejky martindzejky added the bug Something isn't working label Jul 25, 2023
@martindzejky
Copy link
Author

Actually, now I realized that putting additional data into the name is not a good idea because then 2 editors won't be connecting to the same document 🤔 . So, I have no idea how to pass additional data for a document.

@martindzejky
Copy link
Author

I made an experiment today - I'm passing the additional data through the token. I don't really see any other option since HocuspocusProvider really gives me 2 strings to use when connecting -> the name and the token. As far as I understand, name needs to match for 2 editors to connect to the same document, so there's no way I'm passing additional state data through that. So I only have the token, which I've implemented today. It seems to work fine but I'm hitting one problem:

When I connect to a document using a token that has readonly=true in it, a readonly connection is created. But then I click edit in my app which creates a new editor in write mode. That creates a new connection where the token does not contain readonly=true, which I would expect would trigger the onAuthenticate hook again, but it does not. Instead the server prints Unable to handle message of type 2: no handler defined! and keeps the same connection to the document (which is readonly so my edits are thrown away...).

I have removed the logic of passing the readonly param through the token and I'm only passing the templateId which seems to work just fine. Is this the way to go? 🤯

@janthurau
Copy link
Collaborator

hey @martindzejky, the parameters are passed as HTTP parameters, so it indeed doesn't work with multiplexing (as we share the connection, it would be using the same HTTP parameters for all documents).

If you want to pass additional data, the recommendation would be to use a jwt token for authentication and pass the parameters in that. Using HTTP parameters for something like readonly is not recommended at all, as it can easily be modified. If that's ok for you, I'd recommend just using read-only mode on editor level (i.e. Tiptap.setEditable).

If you want to do this using server side auth with JWT, you'll need to destroy the old provider first, and then open a new provider. This will close the server connection and then allow the auth hook to run again.

@martindzejky
Copy link
Author

Thanks for the info 👍 . Regarding the provider, are you sure that is the way to go when I'm using multiplexing? When I need to close connection to a document and then reopen it using different data (which means different authentication token), I can't just destroy the provider because other documents and editors might still be using it. 🤔

@martindzejky martindzejky closed this as not planned Won't fix, can't repro, duplicate, stale Oct 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants