3 ms·
Cool. I implemented a similar toy project once, to directly expose a database on the server to the client via web socket. I say “toy” because that’s obviously i
by chatmasta 9y ago
Cool. I implemented a similar toy project once, to directly expose a database on the server to the client via web socket. I say “toy” because that’s obviously incredibly insecure.
What are the security considerations here? If you have multiple clients, should their topics be isolated? Presumably Alice should not be able to run a DEL command on a topic owned by Bob. Where would you put code for authentication / ACL?
- marianoguerra 9y agothe idea is to expose the websocket api to the public (for now only subscribe) and the redis api only to internal servers so they can publish/subscribe.
- goliatone 9y agoThere are a couple projects that solve this by adding a rules engine that manages ACL. https://deepstreamhub.com https://deepstreamhub.com https://crossbar.io https://crossbar.io
- marknadal 9y agoWe solved this by actually enabling P2P user accounts that secure the data and permissions through cryptographic signatures! https://hackernoon.com/so-you-want-to-build-a-p2p-twitter-with-e2e-encryption-f90505b2ff8 https://hackernoon.com/so-you-want-to-build-a-p2p-twitter-wi... This means the servers themselves can't even middleman the data.
- e12e 9y ago> I say “toy” because that’s obviously incredibly insecure. I trust postgres row-level access control a lot more than a php script with dbowner access to the db - so I think this depends a lot on which db, and what "direct access" means...
- chatmasta 9y agoTrue. This was a college project years ago but recently I’ve been thinking about revisiting it. With properly provisioned DB users, ACLs, and stored procedures, it could actually end up being more secure than it would be with an intermediary application server.