update: headers for CORS #133
Conversation
| @@ -79,7 +79,7 @@ trait ReadWriteWebControllerGeneric extends ReadWriteWebControllerTrait { | |||
| private def allowHeaders(authResult: AuthResult[NamedResource[Rdf]]): List[(String, String)] = { | |||
| val modesAllowed = authResult.authInfo.modesAllowed | |||
| val isLDPC = authResult.result.isInstanceOf[LocalLDPC[_]] | |||
| val allow = "Allow" -> { | |||
| val allow = "Access-Control-Allow-Methods" -> { | |||
There was a problem hiding this comment.
The LDP spec requires the Allow. See ¶ 4.2.8.2 of the LDP spec. So it can't be replaced the way it is done here.
The Access-Control-Allow-Methods is part of the CORS standard and has a different meaning. The reason for its existence has to be looked at in a lot greater detail to understand what the dangers associated with it are.
There was a problem hiding this comment.
Alright, I hadn't found that. I'm wondering why they didn't use the same header. Can there be cases where the two headers have different values?
Otherwise I'm just going to duplicate it.
There was a problem hiding this comment.
The difference is that the Allow header is saying: you can use these methods as you are authenticated now. The Access-Control-Allow-Methods field is saying what you can do if a JS script is holding a gun to your head and telling you exactly what to do. There are certain JS scripts that are allowed to take over your brain perhaps with the Origin header, but not all.
So in the case that the RDF is completely public then the two should be the same. What is really needed is in the WebID profile of the user who is authenticated, for him to specify the JS origins he accepts ( As long as an arbitrary JS can't just edit that file. )
There was a problem hiding this comment.
Ok! Not sure to get the gun metaphore, but I'll add both.
I agree with you for the list in the webId. I guess the server could have its own black list as well. I'm wondering how we can ask the user if the origin should be added to the trusted ones. I guess we could do a redirection to the server holding the WebId. Not sure if it can be done on an OPTIONS request though.
There was a problem hiding this comment.
Ok, I have written up a fuller explanation of what I think is actually needed on the Web Access Control wiki page.
https://www.w3.org/wiki/WebAccessControl#Cors_User_Agents
I'll see if I get some feedback on this from the larger community. But let me see what you think.
There was a problem hiding this comment.
I think it's a pretty good solution. One remark, the CORS problem is not limited to Write operations. Even giving access to a script to private data may be a real issue, as that script can then send that data somewhere else.
Another detail, I'm not sure to understand why the term class is used to specify the origin in the example ACL.
|
There is a good answer from @michielbdejong on the WebID mailing list which messes up the proposed solution as far as browsers go, and leads me back to the idea that a full proxy answer is the correct one. |
|
I may agree with you that the proxy solution is more robust, but I'm pretty sure app developers will require to be able to trigger CORS request from the client. I think both need to be supported. |
|
In both my proposed solutions the CORS is triggered from the client. In the proxy the calls are just routed through a web proxy first. Without the CORS proxies you need to solve the problem described for resources that are non public. ( And for public resources there are issues of efficiency as each additional OPTIONS request is very time consuming ) |
|
I agree with that, but it means that application designers are restrained in a certain design, and I'm not sure most will make their apps that way. My point is that RwwPlay! should support this design even if it's not the best one, as I expect most applications will be made this way. |
|
I asked on W3C Webapp-sec mailing list about wether they had a Simple Description of CORS. I think one needs to study those answers, to get a good understanding of what the security issues may be. |
|
Interesting discussion. I didn't read all the COWL papers, so I don't really understand how this model would work, but that might be a good answer. In the meantime, I don't see anything better than asking the user. I have to add that although the proxy solution would bypass the CORS mechanism, I don't think it solves the security issue raised here. It could be even worse if it implies sharing some credentials with a proxy you don't necessarily trust. |
|
Mhh so according to an answer by @annevk on issue #118 it looks like the proposal of using WebID information to allow the server to specify the Origin for authenticated requests may in fact work. He wrote there:
|
|
Alright, but we still need some mechanism for user decision about trusted origin right? |
|
Please see http://en.wikipedia.org/wiki/Ambient_authority about putting trust in origins. On the face of it that doesn't seem like a good idea. It's not entirely clear to me what you're trying to accomplish here though. |
bblfish
force-pushed
the
dev
branch
2 times, most recently
from
de8655e to
bf355c8
Compare
WARNING: this version doesn't take care of where the request is coming from, nor if the user actually wants it. I'm not sure how to ensure it in an open decentralized world. A few ideas:
Any ideas welcome