Avoid public notifications about private resources #6
Conversation
|
@kjetilk bump |
| @@ -1,4 +1,4 @@ | |||
| sudo: false | |||
| language: node_js | |||
| node_js: | |||
| - "0.12" | |||
| - "10" | |||
There was a problem hiding this comment.
This should be done as a specific PR IMO, but apart from that this PR looks good ^_^
There was a problem hiding this comment.
OK, I did it as three commits in one PR, but I can split it out as one PR per commit, no problem!
|
Sorry that I hadn't followed up on this. I have tried to read up on WebSockets but not grasped the security model. It seems like it supplies a token that could mitigate some attacks, and since I was unsure about what things this might break, I left it for now. It seems very valid though. Since there are many things that needs to be tested on NSS, I'm also a bit hesitant to release it right now, as we might not easily what breaks. OTOH, we shouldn't leave security problems open. So, what should we do? Merge and release a beta? |
|
I'm also unsure what this might break, so we should try to find that out. Solid-chat, for instance? |
|
Just confirmed that the data browser's chat pane relies on the current behaviour to display new chat messages |
This is a first step of two for fixing #1. First, since currently WebSocket client connections are all unauthenticated, none of them should receive notifications about non-public resources.
In a follow-up PR, we should add code to check and store credentials of WebSocket clients, and then allow them to receive updates about non-public resources too, based on those credentials.