[ acl:origin "https://cimba.co" ]

[slorber]

On @deiu 's cimba service

I can log in there with my play-rww webid. Then I try to create my storage space here which will be appended to my card.

I can see a request OPTIONS being sent by the js code of Cimba, but this leads to a technical error on our server:

[18:22:02][ERROR][application][] >>> 

! Internal server error, for (OPTIONS) [/card] ->

scala.MatchError: OPTIONS (of class java.lang.String)
    at Global$.onRouteRequest(Global.scala:24) ~[classes/:na]
    at play.api.GlobalSettings$class.onRequestReceived(GlobalSettings.scala:78) ~[play_2.10.jar:2.2-TLS]
    at Global$.onRequestReceived(Global.scala:11) ~[classes/:na]
    at play.core.server.Server$$anonfun$sendHandler$1$1.apply(Server.scala:53) ~[play_2.10.jar:2.2-TLS]
    at play.core.server.Server$$anonfun$sendHandler$1$1.apply(Server.scala:52) ~[play_2.10.jar:2.2-TLS]
    at scala.util.Success$$anonfun$map$1.apply(Try.scala:206) ~[scala-library-2.10.3.jar:na]
    at scala.util.Try$.apply(Try.scala:161) ~[scala-library-2.10.3.jar:na]
    at scala.util.Success.map(Try.scala:206) ~[scala-library-2.10.3.jar:na]
    at play.core.server.Server$class.sendHandler$1(Server.scala:52) [play_2.10.jar:2.2-TLS]
    at play.core.server.Server$$anonfun$getHandlerFor$4.apply(Server.scala:85) [play_2.10.jar:2.2-TLS]
    at play.core.server.Server$$anonfun$getHandlerFor$4.apply(Server.scala:84) [play_2.10.jar:2.2-TLS]
    at scala.util.Either$RightProjection.flatMap(Either.scala:523) [scala-library-2.10.3.jar:na]
    at play.core.server.Server$class.getHandlerFor(Server.scala:84) [play_2.10.jar:2.2-TLS]
    at play.core.server.NettyServer.getHandlerFor(NettyServer.scala:38) [play_2.10.jar:2.2-TLS]
    at play.core.server.netty.PlayDefaultUpstreamHandler$$anonfun$9.apply(PlayDefaultUpstreamHandler.scala:189) [play_2.10.jar:2.2-TLS]
    at play.core.server.netty.PlayDefaultUpstreamHandler$$anonfun$9.apply(PlayDefaultUpstreamHandler.scala:189) [play_2.10.jar:2.2-TLS]
    at scala.util.Either.fold(Either.scala:98) [scala-library-2.10.3.jar:na]
    at play.core.server.netty.PlayDefaultUpstreamHandler.messageReceived(PlayDefaultUpstreamHandler.scala:183) [play_2.10.jar:2.2-TLS]
    at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty.jar:na]
    at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty.jar:na]
    at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [netty.jar:na]
    at com.typesafe.netty.http.pipelining.HttpPipeliningHandler.messageReceived(HttpPipeliningHandler.java:62) [netty-http-pipelining.jar:na]
    at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88) [netty.jar:na]
    at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty.jar:na]
    at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [netty.jar:na]
    at org.jboss.netty.handler.codec.http.HttpContentDecoder.messageReceived(HttpContentDecoder.java:108) [netty.jar:na]
    at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty.jar:na]
    at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty.jar:na]
    at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [netty.jar:na]
    at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296) [netty.jar:na]
    at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:459) [netty.jar:na]
    at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:536) [netty.jar:na]
    at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:435) [netty.jar:na]
    at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty.jar:na]
    at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty.jar:na]
    at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [netty.jar:na]
    at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296) [netty.jar:na]
    at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462) [netty.jar:na]
    at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443) [netty.jar:na]
    at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303) [netty.jar:na]
    at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty.jar:na]
    at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty.jar:na]
    at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) [netty.jar:na]
    at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty.jar:na]
    at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty.jar:na]
    at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) [netty.jar:na]
    at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109) [netty.jar:na]
    at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312) [netty.jar:na]
    at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90) [netty.jar:na]
    at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) [netty.jar:na]
    at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty.jar:na]
    at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty.jar:na]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_51]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_51]
    at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]

On the client side, I also see:

app.js:730
OPTIONS https://sebas5.stample.io/card 500 (Internal Server Error) jquery.min.js:5
OPTIONS https://sebas5.stample.io/card No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://cimba.co' is therefore not allowed access. jquery.min.js:5
XMLHttpRequest cannot load https://sebas5.stample.io/card. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://cimba.co' is therefore not allowed access. 

---

Which seems normal because the header could not be set.
Maybe this operation should be done by a cors proxy that handles auth? Or should we add the Access-Control-Allow-Origin header?

---

For our technical error, I think the Global config file which handle request redirects is missing the OPTIONS verb:

object Global extends GlobalSettings {
  override def onRouteRequest(req: RequestHeader) = {
    import rww.play.EnhancedRequestHeader

    val uri = req.getAbsoluteURI

    if (
      uri.getPath.startsWith("/assets/")
      || uri.getPath.startsWith("/srv/")
      || uri.getHost().startsWith("www")
    ) {
      super.onRouteRequest(req)
    } else if (uri.getHost != controllers.plantain.host) {
      req.method match {
        case "GET" => Some(ReadWriteWebController.get(req.path))
        case "POST" => Some(ldp.ReadWriteWebController.post(req.path))
        case "PATCH" => Some(ldp.ReadWriteWebController.patch(req.path))
        case "MKCOL" => Some(ldp.ReadWriteWebController.mkcol(req.path))
        case "HEAD" => Some(ldp.ReadWriteWebController.head(req.path))
        case "PUT" =>  Some(ldp.ReadWriteWebController.put(req.path))
        case "DELETE" => Some(ldp.ReadWriteWebController.delete(req.path))
      }
    } else  super.onRouteRequest(req)
  }
}

[bblfish]

well spotted

[deiu]

Just to clarify something: I believe OPTIONS is being sent by jQuery (or maybe the browser?). Cimba does not send a specific OPTIONS request.

[slorber]

yes @deiu that's probably the case.

@bblfish I put the code with OPTIONS online. Notice that it seems your options() method seems to redirect to a HEAD, is this intended?

So this time I have:

Request URL:https://sebas5.stample.io/card
Request Method:OPTIONS
Status Code:200 OK
Request Headersview source
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en,fr-FR;q=0.8,fr;q=0.6,en-US;q=0.4,ms;q=0.2
Access-Control-Request-Headers:accept, content-type
Access-Control-Request-Method:POST
Cache-Control:no-cache
Connection:keep-alive
Host:sebas5.stample.io
Origin:http://cimba.co
Pragma:no-cache
Referer:http://cimba.co/
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36
Response Headersview source
Accept-Patch:application/sparql-update
Access-Control-Allow-Origin:*
Allow:GET, HEAD
Content-Length:0
Content-Type:text/turtle
Link:<http://www.w3.org/ns/ldp#Resource>; rel=type

Is it normal to not have OPTIONS in the Allow header?

Btw this still leads to an error on the server side:

OPTIONS https://sebas5.stample.io/card Wildcards cannot be used in the 'Access-Control-Allow-Origin' header when the credentials flag is true. Origin 'http://cimba.co' is therefore not allowed access. jquery.min.js:5
XMLHttpRequest cannot load https://sebas5.stample.io/card. Wildcards cannot be used in the 'Access-Control-Allow-Origin' header when the credentials flag is true. Origin 'http://cimba.co' is therefore not allowed access. 

@deiu I think this concerns you, I saw your rdflib change:
linkeddata/rdflib.js#35

[bblfish]

HEAD is GET without the content.
OPTIONS is more flexible, allowing the server to not have to calculate the Content-Length, but otherwise it is very similar.
LDP requires OPTIONS.
We should add the Access-Control-Allow-Origin on Options too of course. That is probably an error on the proxy - which should add that header I think.

[bblfish]

The following screen shot shows that the cimba JS is trying to request the card directly first, and is being stopped by CORS. It then gets it via the CORS proxy. Finally it makes an OPTIONS call, presumably because it wants to do a POST ( or PATCH ). (CORS requires the JS to do an OPTIONS call first on non-indempotent methods, to allow the browser to work out if it is allowed to execute the request). Those fail too since we have not enabled this.

It would be worth extending the acl ontology to give CORS agents access. Then the user could give a specific JS from a service write access to a file. Allowing any JS agent access would be too big a security hole.

I suggested as much in a mail to the rww list end of Nov 2013: Web Access Control Allowing CORS agents. An acl would then look like this:

@prefix acl: <http://www.w3.org/ns/auth/acl#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

 [] acl:accessToClass [ acl:regex "https://stample.io/2013/test/.*" ];
    acl:mode acl:Read, acl:Write;
    acl:agent [ acl:origin "https://cimba.co" . ]

If we do this then we can be more specific about JS agents. For example I could give a CORS agent access to a LDPC under my home directory.

If folks on cimba are willing to settle on this then we can implement it.

Note: This was already written up on the WebAccessControl wiki

[bblfish]

This is being discussed on SoLiD spec solid/solid#53