Open semaja2 opened 7 months ago
You can easily do this and we do it internally at Cloudflare. Rooms follow the URL pattern example.com/
Orange Meets can also pick up the name of the user from Access and display that also.
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
@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?
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.