Thanks Henry. Well I had looked there, but it all looked quite complicated - I have never cloned a git thingy before and I don't even know if Java is available on the host :-) But emboldened by your encouragement I went for the "The short version". I was very encouraged, as it seemed to do quite a lot, but seemed to hang after getting play-2-TLS-e6c58f64585b182f937358fa984474b86984d77d.tar.bz2
But, even when I tried to do it by hand (the Longer Version), I eventually got the java was killed for excessive resource usage. By which tim sit had downloaded 427MB of stuff. I don't think these are the sort of hosting costs I want to have. So I have a sense this is not the solution I was looking for :-) Very best Hugh By the way, the link in "An initial implementation of Linked Data Basic Profile" does a 404. On 9 Aug 2013, at 18:09, Henry Story <[email protected]> wrote: > > On 9 Aug 2013, at 18:55, Hugh Glaser <[email protected]> wrote: > >> Thanks. >> I've looked at quite a bit of this stuff, but still don't see where the ACL >> document gets stored and used. >> >> I am beginning to get the sense that I may have to write some code, other >> than the ACL rdf to do this. >> Surely Apache or something else will do this for me? >> Can't I "just" put the ACL in a file (as in htpasswd) and point something at >> it? >> I certainly don't want to be writing code to make one photo (or simply a >> static web site) available. >> Or is that the "delegated service" you are talking about? >> >> I've got my fingers crossed here. > > You can follow the instructions on installing > https://github.com/stample/rww-play > (It's under the Apache Licence and patches and contributions are welcome ) > > Then you'll be able to do the following: > > An initial implementation of the Linked Data Platform spec is implemented > here. The same way as theApache httpd server it servers resource from the > file system and maps them to the web. By default we map the test_www > directory's content to http://localhost:8443/2013/. > > The test_www directory starts with a few files to get you going > > $ cd > test_www > > $ > ls -al > total 48 > drwxr-xr-x 4 hjs admin 340 9 Jul 19:04 . > drwxr-xr-x 15 hjs admin 1224 9 Jul 19:04 .. > -rw-r--r-- 1 hjs staff 229 1 Jul 08:10 .acl.ttl > -rw-r--r-- 1 hjs admin 109 9 Jul 19:04 .ttl > lrwxr-xr-x 1 hjs admin 8 27 Jun 20:29 card -> card.ttl > -rw-r--r-- 1 hjs admin 167 7 Jul 22:42 card.acl.ttl > -rw-r--r-- 1 hjs admin 896 27 Jun 21:41 card.ttl > -rw-r--r-- 1 hjs admin 102 27 Jun 22:32 index.ttl > drwxr-xr-x 2 hjs admin 102 27 Jun 22:56 raw > drwxr-xr-x 3 hjs admin 204 28 Jun 12:51 > test > All files with the same initial name up to the . are considered to work > together, (and in the current implementation are taken care of by the same > agent). > > Symbolic links are useful in that they: > > • allow one to write and follow linked data that works on the file > system without needing to name files by their extensions. For example a > statement such as [] wac:agent <card#me> can work on the file system just as > well as on the web. > • they guide the web agent to which the default representation should be > • currently they also help the web agent decide which are the resources > it should serve. > There are three types of resources in this directory: > > • The symbolic links such as card distinguish the default resources > that can be found by an httpGET on http://localhost:8443/2013/card. Above the > card -> card.ttl shows that card has a defaultturtle representation. > • Each resource also comes with a Web Access Control List, in this > example card.acl.ttl, which set access control restrictions on resources on > the file system. > • Directories store extra data (in addition to their contents) in the > .ttl file. (TODO: not quite working) > • Directories also have their access control list which are published > in a file named .acl.ttl. > These conventions are provisional implementation decisions, and improvements > are to be expected here . (TODO: > > • updates to the file system are not reflected yet in the server > • allow symbolic links to point to different default formats ) > Let us look at some of these files in more detail > > The acl for card just includes the acl for the directory/collection . (TODO: > wac:include has not yet been defined in the Web Access Control Ontology) > > $ > cat card.acl.ttl > @prefix wac: < > http://www.w3.org/ns/auth/acl# > > . > @prefix foaf: < > http://xmlns.com/foaf/0.1/ > > . > > <> wac:include <.acl> . > > The acl for the directory allows access to all resources in the > subdirectories of test_www when accessed from the web as > https://localhost:8443/2013/ only to the user authenticated > as<https://localhost:8443/2013/card#me>. (TODO: wac:regex is not defined in > it's namespace - requires standardisation.) > > $ > cat .acl.ttl > @prefix acl: < > http://www.w3.org/ns/auth/acl# > > . > @prefix foaf: < > http://xmlns.com/foaf/0.1/ > > . > > > [] acl:accessToClass [ acl:regex "https://localhost:8443/2013/.*"; ] > ; > acl:mode acl:Read, acl:Write; > acl:agent <card#me> . > > Since card's acl includes only the above directory acl, <card#me> can read > that file. The following curlcommand does not specify the public and private > keys to use for authentication and so fails: > > $ curl -i -k https://localhost:8443/2013/card > > curl: > (56) SSL read > : error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate, > errno 0 > > As curl does not allow WANT TLS connections, but only NEED, a failure to > authenticate closes the connection. Most browsers have the more friendly > behavior allowing the server to return an HTTP error code and an explanatory > body. > > Requesting the same resource with a curl that knows which client certificate > to use, the request goes through. > > $ curl -i -k --cert ../eg/test-localhost.pem:test > https://localhost:8443/2013/card > > HTTP/1.1 200 OK > Link: < > MailScanner has detected a possible fraud attempt from "localhost:8443" > claiming to be https://localhost:8443/2013/card.acl>; rel= > acl > Content-Type: text/turtle > Content-Length: 1005 > > > < > #me> <http://www.w3.org/ns/auth/cert#key> _:node17vcshtjbx1 ; > > < > http://xmlns.com/foaf/0.1/name> "Your > Name"^^<http://www.w3.org/2001/XMLSchema#string > > ; > < > http://xmlns.com/foaf/0.1/knows> <http://bblfish.net/people/henry/card#me > > . > > _:node17vcshtjbx1 a < > http://www.w3.org/ns/auth/cert#RSAPublicKey > > ; > < > http://www.w3.org/ns/auth/cert#exponent> > "65537"^^<http://www.w3.org/2001/XMLSchema#integer > > ; > < > http://www.w3.org/ns/auth/cert#modulus> > "C13AB88098CF47FCE6B3463FC7E8762036154FE616B956544D50EE63133CC8748D692A00DAFF5331D2564BB1DD5AEF94636ED09EFFA9E776CA6B4A92022BB060BF18FC709936EF43D345289A7FD91C81801A921376D7BCC1C63BD3335FB385A01EC0B71877FCBD1E4525393CCD5F2922D68840945943A675CCAE245222E3EB99B87B180807002063CB78174C1605EA1ECFECF57264F7F60CD8C270175A1D8DD58DFC7D3C56DB273B0494B034EC185B09977CBB530E7E407206107A73CD4B49E17610559F2A81EA8E3F613C3D3C161C06FE5CB114A8522D20DED77CAAA8C761090022F9CD4AF2C8F21DF7CF05287E379225AEA6A3A6610D02C4A44AA7CEED2CC3"^^<http://www.w3.org/2001/XMLSchema#hexBinary > > . > > Notice the Link header above. Every resource points to its ACL file in such a > header. > > The client certificate in ../eg/test-localhost.pem contains exactly the > private key given in the above cert as you can see by comparing the modulus > and exponents in both representations. This is what allows the authentication > to go through, using the (WebID over TLS protocol)[http://webid.info/spec/]. > > $ > openssl x509 -in ../eg/test-localhost.pem -inform pem -text > Certificate: > Data: > Version: 3 > (0x2) > > Serial Number: 13633800264985240815 > (0xbd34fd1b251264ef) > > Signature Algorithm: sha1WithRSAEncryption > Issuer: > O=\xE2\x88\x85, CN= > WebID > Validity > Not Before: May 3 19:36:33 2013 GMT > Not After : May 3 19:46:33 2014 GMT > Subject: > O=ReadWriteWeb, CN=test > @localhost > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: > (2048 bit) > > Modulus: > 00:c1:3a:b8:80:98:cf:47:fc:e6:b3:46:3f:c7:e8: > 76:20:36:15:4f:e6:16:b9:56:54:4d:50:ee:63:13: > 3c:c8:74:8d:69:2a:00:da:ff:53:31:d2:56:4b:b1: > dd:5a:ef:94:63:6e:d0:9e:ff:a9:e7:76:ca:6b:4a: > 92:02:2b:b0:60:bf:18:fc:70:99:36:ef:43:d3:45: > 28:9a:7f:d9:1c:81:80:1a:92:13:76:d7:bc:c1:c6: > 3b:d3:33:5f:b3:85:a0:1e:c0:b7:18:77:fc:bd:1e: > 45:25:39:3c:cd:5f:29:22:d6:88:40:94:59:43:a6: > 75:cc:ae:24:52:22:e3:eb:99:b8:7b:18:08:07:00: > 20:63:cb:78:17:4c:16:05:ea:1e:cf:ec:f5:72:64: > f7:f6:0c:d8:c2:70:17:5a:1d:8d:d5:8d:fc:7d:3c: > 56:db:27:3b:04:94:b0:34:ec:18:5b:09:97:7c:bb: > 53:0e:7e:40:72:06:10:7a:73:cd:4b:49:e1:76:10: > 55:9f:2a:81:ea:8e:3f:61:3c:3d:3c:16:1c:06:fe: > 5c:b1:14:a8:52:2d:20:de:d7:7c:aa:a8:c7:61:09: > 00:22:f9:cd:4a:f2:c8:f2:1d:f7:cf:05:28:7e:37: > 92:25:ae:a6:a3:a6:61:0d:02:c4:a4:4a:a7:ce:ed: > 2c:c3 > Exponent: 65537 > (0x10001) > > X509v3 extensions: > X509v3 Basic Constraints: > CA:FALSE > X509v3 Key Usage: critical > Digital Signature, Non Repudiation, Key Encipherment, Key > Agreement > Netscape Cert Type: > SSL Client, S/MIME > X509v3 Subject Alternative Name: critical > URI:https://localhost:8443/2013/card#me > X509v3 Subject Key Identifier: > 3C:1B:CF:F2:E5:59:9A:E8:76:BE:83:1D:64:FB:07:4E:08:C6:FC:14 > Signature Algorithm: sha1WithRSAEncryption > 07:97:78:f5:11:58:00:50:17:91:14:e8:e3:0d:34:22:74:07: > ae:61:39:87:23:7a:6c:5c:14:af:13:a6:c8:54:ac:55:d4:41: > 25:45:eb:52:90:ff:56:b0:f9:71:be:ec:c8:2c:a1:19:1c:86: > 42:04:3c:55:7c:96:5c:60:70:0a:d7:ed:5b:53:11:56:7e:14: > 32:92:b9:22:a7:c6:ce:ff:77:17:4a:ac:da:02:ac:24:0e:0e: > 35:18:bd:e3:73:00:3b:8a:aa:ec:86:76:66:dd:4b:1b:da:0c: > c8:a1:d3:27:26:df:bf:6f:55:11:50:3b:8e:04:12:5a:b9:d4: > 7d:7e > > We would of course like to make the card world readable so that the > certificate can be used to login to other servers too. To do this the user > <card#me> can append to the <card.acl.ttl> file an authorization making card > world readable, using an obvious subset of SPARQL Update > > $ > cat ../eg/card.acl.update > PREFIX foaf: < > http://xmlns.com/foaf/0.1/ > > > INSERT DATA > { > [] acl:accessTo <https://localhost:8443/2013/card > > ; > acl:mode acl:Read; > acl:agentClass foaf:Agent . > > } > $ curl -X PATCH -k -i --data-binary @../eg/card.acl.update -H "Content-Type: > application/sparql-update; utf-8" --cert ../eg/test-localhost.pem:test > MailScanner has detected a possible fraud attempt from "localhost:8443" > claiming to be https://localhost:8443/2013/card.acl > It is now possible to read the card without authentication > > $ curl -i -k https://localhost:8443/2013/card > > HTTP/1.1 200 OK > Link: < > MailScanner has detected a possible fraud attempt from "localhost:8443" > claiming to be https://localhost:8443/2013/card.acl>; rel= > acl > Content-Type: text/turtle > > [...] > Next we can publish a couch surfing opportunity using HTTP's POST method as > explained by the LDP spec > > $ curl -X POST -k -i -H "Content-Type: text/turtle; utf-8" --cert > ../eg/test-localhost.pem:test -H "Slug: couch" -d @../eg/couch.ttl > https://localhost:8443/2013/ > > HTTP/1.1 201 Created > Location: > https://localhost:8443/2013/couch > > Content-Length: 0 > > The Location: header in the above response tells us that the name of the > created resource ishttps://localhost:8443/2013/couch. > > We can now look at the contents of the https://localhost:8443/2013/ > collection, where we should see - and do - the new couch resource listed as > having been created by ldp. > > $ curl -k -i -X GET --cert ../eg/test-localhost.pem:test > https://localhost:8443/2013/ > > HTTP/1.1 200 OK > Link: < > MailScanner has detected a possible fraud attempt from "localhost:8443" > claiming to be https://localhost:8443/2013/.acl>; rel= > acl > Content-Type: text/turtle > Content-Length: 119 > > > <> < > http://www.w3.org/ns/ldp#created> <raw/> , <card> , <test > /> , <couch> ; > a < > http://www.w3.org/ns/ldp#Container > > . > > We can find out about the ACL for this resource using HEAD (TODO: OPTIONS > would be better, but is not implemented yet ) > > $ curl -X HEAD -k -i --cert ../eg/test-localhost.pem:test > https://localhost:8443/2013/couch > > HTTP/1.1 200 OK > Link: < > MailScanner has detected a possible fraud attempt from "localhost:8443" > claiming to be https://localhost:8443/2013/couch.acl>; rel= > acl > Content-Type: text/turtle > Content-Length: 0 > > ( TODO: The Content-Length should not be 0 for HEAD. Bug in Play2.0 probably ) > > So we add the couch acl which gives access to that information in addition to > the default owner of the collection, to two groups of people > > $ curl -X PATCH -k -i -H "Content-Type: application/sparql-update; utf-8" > --cert ../eg/test-localhost.pem:test --data-binary @../eg/couch.acl.patch > MailScanner has detected a possible fraud attempt from "localhost:8443" > claiming to be https://localhost:8443/2013/couch.acl > > HTTP/1.1 200 OK > Content-Type: text/plain; > charset= > utf-8 > Content-Length: 9 > > Succeeded > > This makes it available to the test user and the members of the WebID and > OuiShare groups. If you have a WebID then try adding yours and test it. You > can also request different formats by changing theAccept: header such as with > the following request for RDF/XML > > $ curl -k -i -X GET -H "Accept: application/rdf+xml" --cert > ../eg/test-localhost.pem:test https://localhost:8443/2013/couch > or if you prefer rdf/xml over turtle as described by the Content Negotiation > section of the HTTP1.1 spec: > > $ curl -k -i -X GET -H "Accept:application/rdf+xml;q=0.9,text/turtle;q=0.7" > --cert ../eg/test-localhost.pem:test https://localhost:8443/2013/couch > It is then possible to also use SPARQL queries on particular resources. > (TODO: find a better example) > > $ > cat ../eg/couch.sparql > PREFIX gr: < > http://purl.org/goodrelations/v1# > > > SELECT ?D > WHERE > { > > > [] a <http://bblfish.net/2013/05/10/couch#Surf > >; > gr:description ?D . > > } > > > > $ curl -X POST -k -i -H "Content-Type: application/sparql-query; > charset=UTF-8" --cert ../eg/test-localhost.pem:test --data-binary > @../eg/couch.sparql https://localhost:8443/2013/couch > > HTTP/1.1 200 OK > Content-Type: application/sparql-results+xml > Content-Length: 337 > > <?xml > version='1.0' encoding='UTF-8' > ?> > <sparql > xmlns='http://www.w3.org/2005/sparql-results#' > > > <head> > <variable > name='D' > /> > </head> > <results> > <result> > <binding > name='D' > > > <literal > datatype='http://www.w3.org/2001/XMLSchema#string' > >Comfortable couch in Artist Stables</literal> > </binding> > </result> > </results> > </sparql> > > > Finally if you no longer want the couch surfing opportunity to be published > you can DELETE it. ( It would be better to express that it was sold: > DELETEing resources on the Web is usually bad practice: it breaks the links > that other people set up to your services ) > > curl -k -i -X DELETE -H "Accept: text/turtle" --cert > ../eg/test-localhost.pem:test https://localhost:8443/2013/couch > > HTTP/1.1 200 OK > Content-Length: 0 > > And so the resource no longer is listed in the LDPC > > $ curl -k -i -X GET --cert ../eg/test-localhost.pem:test > https://localhost:8443/2013/ > > HTTP/1.1 200 OK > Link: < > MailScanner has detected a possible fraud attempt from "localhost:8443" > claiming to be https://localhost:8443/2013/.acl>; rel= > acl > Content-Type: text/turtle > Content-Length: 109 > > > <> a < > http://www.w3.org/ns/ldp#Container > > ; > < > http://www.w3.org/ns/ldp#created> <card> , <raw/> , <test > /> . > > To create a new container one just creates an LDP Resource that contains the > triple<> a ldp:Container. > > $ > cat ../eg/newContainer.ttl > @prefix ldp: < > http://www.w3.org/ns/ldp# > > . > @prefix foaf: < > http://xmlns.com/foaf/0.1/ > > . > > <> a ldp:Container; > foaf:topic > "A container for some type X of resources" > ; > foaf:maker <../card#me> . > > > $ curl -X POST -k -i -H "Content-Type: text/turtle; utf-8" --cert > ../eg/test-localhost.pem:test -H "Slug: XDir" -d @../eg/newContainer.ttl > https://localhost:8443/2013/ > > HTTP/1.1 201 Created > Location: > https://localhost:8443/2013/XDir/ > > Content-Length: 0 > > Note that directories can only be deleted if all ldp:created resources were > previously deleted. > > Creating a WebID Certificate > > After starting your server you can point your browser to > http://localhost:9000/srv/certgen or to the service over https and create > yourself a certificate. For testing purposes and in order to be able to work > without the need for network connectivity use > `http://localhost:8443/2013/cert#me'. The WebID Certificate will be signed by > the agent with Distinguished Name "CN=WebID,O=∅" and added by your browser to > its keychain. > > ( Todo: later we will add functionality to add create a local webid that also > published the RDF ) To make the WebID valid you will need to publish the > relavant rdf at that document location as explained in the WebID spec >
