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

Suggestion: Cloudflare Access controls for creating rooms #21

Open
semaja2 opened this issue Apr 4, 2024 · 3 comments
Open

Suggestion: Cloudflare Access controls for creating rooms #21

semaja2 opened this issue Apr 4, 2024 · 3 comments

Comments

@semaja2
Copy link

semaja2 commented Apr 4, 2024

Would be fantastic to integrate Cloudflare Access controls to permit only CF Access users from creating a room, but allowing general public to join existing rooms if given the code

I am attempting to sort through the code to see if this is possible, but I am unable to find the file/line responsible for the creation of a room to put a basic header check in.

@renandincer
Copy link
Member

You can easily do this and we do it internally at Cloudflare. Rooms follow the URL pattern example.com/, so you can restrict access using Access on a particular URL.

Orange Meets can also pick up the name of the user from Access and display that also.

@semaja2
Copy link
Author

semaja2 commented Apr 5, 2024

I did spot the checks for the Cf-Access-Authenticated-User-Email which was nice to see, however as the room is dynamically generated the first time someone visits I am unsure how your securing room creation based on URLs?

The concern is a threat actor could make a URL (https://orange-meets.acme.workers.dev/supportcall/room) and send to a target, potentially impersonating someone at ACME Inc.

I did eventually find I could place a header check in the ChatRoom.server.ts code which will return a 404 if the target room has no existing sessions and the user does not have the authentication header, this is not ideal but atleast ensures an Access authenticated user is in the room before establishing

Fantastic project by the way, only real issue I had was the cookie expiry check caused a loop as we only issue 24 hour tokens so they were invalidated instantly

@BenjaminEHowe
Copy link
Contributor

@semaja2 that sounds like a nifty patch for a semi-public instance (I'm thinking where guests can join but only after a "host" has started the room). Perhaps it's worth filing a PR with a feature toggle defaulted to disabled?

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

3 participants