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

Feature request: More permissive authentication configuration #2

Closed
nighoggDatatype opened this issue Oct 26, 2022 · 2 comments
Closed

Comments

@nighoggDatatype
Copy link

A feature request I have would be for the configuration for authenticate to pass in more than the token. I would like to restrict who can access a particular document, but as it is, I am unable to access the URL from the socket.io handshake. Preferably, the entire handshake would be passed instead of just the auth.

I can see a workaround by manually registering with the dynamic namespace after initialization, but that's inelegant.

@ivan-topp
Copy link
Owner

ivan-topp commented Oct 26, 2022

Hi, I think it's a good idea, currently you can already pass more than just the token. For example, to check a user ID to see if they have permissions to access the document or to deny their access, you can do the following:

Client side

// ...
const socketIOProvider = new SocketIOProvider(
  'ws://localhost:1234',
   'admin-doc',
  doc,
  {
    auto connect: true,
    authentication: {
      token: 'valid-token',
      userId: 'my-user-ID',
      role: 'not-admin',
    },
  }
);
// ...

Server side

// ...
const authenticate = (authorization) => {
  if (!auth.token || auth.token !== 'valid-token') return false;
  else if (auth.userId ! == 'my-user-id') return false;
  // Here you can validate and manipulate to your liking all the information of the auth object...
}

const ysocketio = new YSocketIO(io, {
  authenticate: authenticate,
})
// ...

However, doing these little code snippets, I realize that:

1.- The server-side authentication function should be able to accept promises in case the permissions are stored elsewhere (eg in mongodb or MySQL)

2.- The server-side authentication function could provide the yjs document itself as a parameter of the authentication function in case the access data is in the document

In the next version post I'm going to include these two points I just mentioned in addition to the handshake forwarding as well.

@ivan-topp
Copy link
Owner

I just published the new version with this implementation, so I'll close this issue.

However, in the end I only added the allow full handshake access and promise acceptance in the "authenticate" function.

Thank you very much for your idea

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants