questions about models, read-only, and security/validation

[abovemike]

a few quick questions about how to use swarm for a typical webapp. thanks in advance!

is it possible for client replicas to be read only? for example, is there a flag in the host setup to set this.

for the available models, which would work best for an append only data type? should i use vector and only the .append function?

if i use a crdt, what is the recommended way to implement server side validation on a user's changes to the models? or should they just not be trusted and model changes be filtered through server side validation before being saved.

[sebakerckhof]

I'm also highly interested in these questions. Because most real world applications will need this data validation, authorization etc. Swarm looks great, but for now it's still too much a POC instead of something usable in the real world.

[gritzko]

1. Read-only will likely appear in 0.4; that is protocol-level (talk, not listen)
2. An append-only collection may be implemented with Vector. Although, that is not very efficient. CRDT literature has plenty of collection datatypes with various tradeoffs. Eventually, we'll have more of that implemented.
3. Server-side validation can be done by means of RPC. That part is in progress.
4. Regarding authorization, Swarm only needs to know a user login for each connection. That is more like "jQuery and auth" issue. They are orthogonal.

[dubrowgn]

I have also been looking for a way to do these things.

I found I can override Syncable.acl() to deny access. This might be useful in the context of validation, but seems mostly useless for authentication, since this function only has access to what the client sends to the server. Obviously, the client can't be trusted.

I've been looking at intercepting the messages as they came into the server, either at the websocket level or the Swarm stream level. It could be workable to inject a filter layer at this point to do things like check authentication and validation before propogating the messages to the other peers. For example, you could throw an 'access denied' error for 'init' opperations when a peer requests an object, or you could throw a validation error for 'set' opperations, etc. However, at that point in the stack the messages are still serialized, and need to be unpacked before they can be routed to the correct filter logics for validation/authentication/etc.

[gritzko]

My plan for 0.4 was to separate authorization and authentication. Authorization is mostly based on (a) reasonable defaults and (b) stored ACLs. Meanwhile, authentication is very much dependent on the underlying transport/application stack. I mean, if we integrate OAuth then it needs access to HTTP, not an abstract Pipe. So, it has to be implemented in the server that either opens a Pipe or not.
Another interesting aspect is that operations may propagate by shortcut links, directly client to client. That means, that every replica must do auth checks, not only the server.
Specifically at the Swarm protocol level, "read allowed" is manifested by an .init message and "write allowed" by a .reon (reverse subscription).
What are your thoughts?

[dubrowgn]

Thanks for the response! I guess I'm not entirely clear on the interplay between authorization and authentication.

An ACL can tell me Bob has read permissions to object A, but authentication tells me if a given user is in fact Bob. Bob has to present something to me to prove he is Bob before I'll take his word for it. Traditionally we do this with a shared secret, like a password hash or an OAuth token. In order for Bob to prove his identity to a given peer, they must also know this secret or be able to validate it.

It makes sense to me that an authoritative server could do these things by either opening a pipe or not. I had a short discussion on IRC a few days ago about using the Pipe connecting Stream and Host instances to implement this logic. It would be easy enough to make stages of this Pipe pluggable, so Swarm users can inject their own custom application logic. As an operation moves through the pipeline, it can be rejected and/or transformed at each stage, making it somewhat like Ruby On Rail's middleware concept.

However, I'm not sure how you would do authentication between arbitrary peers. Theoretically, a peer could just ask an authoritative server if the user is authenticated (like OAuth), but at that point you have defeated the latency benefits of communicating peer-to-peer. Depending on the implementation, this could also allow a peer to masquerade as any other peer they have ever connected to.

Is there already some way to do what I'm talking about on the server, and what are your thoughts on overcoming the peer-to-peer authentication problem?