search

solid-contrib / web-access-control-tests

Tests if a Solid server implements web access control correctly
MIT License
2 stars 5 forks source link

Tests to add #3

Closed michielbdejong closed 3 years ago

michielbdejong commented 4 years ago

So far, I have a test that checks if the pod root ACL doc exists and has at least one triple. We want to test how an ACL doc affects access rights. For all tests we would create a test folder with some fixture tree in there, and see how the server interprets the ACL docs we put in. The fixture tree root could have an empty ACL doc, to make sure nothing outside the test folder affects the behaviour.

ACL doc application

Things you can do and necessary+sufficient access rights for it:

Create

Read

Update

Delete

Control

michielbdejong commented 4 years ago

so for instance for create:POST I could do 1 test with acl:Append (should succeed), one with acl:Write (should succeed), and then one with everything else (i.e. accessTo Read, Control and default R/A/W/C) and that should fail.

I should use two users for recursiveDelete to work after I set a restrictive ACL. Also, rdflib seems to hijack the fetcher, for instance:

Create › Using PUT › Is not allowed with default Read access

    Fetcher: <https://localhost:8443/solid-crud-tests-1599138436666/defaultRead/> Forbidden

      1082 |       }
      1083 | 
    > 1084 |       var err = new Error('Fetcher: ' + errorMessage); // err.ok = false // Is taken as a response, will work too @@ phase out?
           |                 ^
      1085 | 
      1086 |       err.status = statusCode;
      1087 |       err.statusText = errorMessage;

      at Fetcher.failFetch (../rdflib/lib/fetcher.js:1084:17)
      at ../rdflib/lib/fetcher.js:1792:26
          at runMicrotasks (<anonymous>)

where I'm only using authFetcher and not rdflib to run that test, so I'll use one authFetcher for setting up the fixtures and then a separate one for running the tests.