webid-provider-tests

The following three open source Solid server implementations currently implement the webid-provider role:

• NSS
• PSS
• Nextcloud

Solid CRUD

The following four open source Solid server implementations currently implement the storage role with CRUD:

• NSS
• PSS
• Nextcloud
• CSS

WAC

The following three open source Solid server implementations currently implement the storage role with WAC:

• NSS
• PSS
• Nextcloud
• CSS

Blocked on solid-contrib/test-suite#96

When I run:

loopy:php-solid-server michiel$ HOST=127.0.0.1 composer serve-dev
> ENVIRONMENT=development php -S "${HOST:-localhost}:${PORT:-8080}" -t web/ web/index.php

on my host machine, then all openid-config tests pass except for one http/https detail:

loopy:webid-provider-tests michiel$ SERVER_ROOT=http://localhost:8080 ./node_modules/.bin/jest test/surface/fetch-openid-config.test.ts 
 FAIL  test/surface/fetch-openid-config.test.ts
  ● The server's openid configuration › has the server root as the issuer

    expect(received).toEqual(expected) // deep equality

    Expected: "http://localhost:8080"
    Received: "https://localhost:8080"

      27 | 
      28 |   test("has the server root as the issuer", async () => {
    > 29 |     expect(configObj.issuer).toEqual(SERVER_ROOT);
         |                              ^
      30 |   });
      31 | 
      32 |   test("announces a jwks_uri", async () => {

      at test/surface/fetch-openid-config.test.ts:29:30
      at step (test/surface/fetch-openid-config.test.ts:33:23)
      at Object.next (test/surface/fetch-openid-config.test.ts:14:53)
      at test/surface/fetch-openid-config.test.ts:8:71
      at __awaiter (test/surface/fetch-openid-config.test.ts:4:12)
      at Object.<anonymous> (test/surface/fetch-openid-config.test.ts:28:45)

Test Suites: 1 failed, 1 total
Tests:       1 failed, 4 skipped, 12 passed, 17 total
Snapshots:   0 total
Time:        1.214 s, estimated 2 s

But I can't get the same result when running the php-solid-server docker image from this repo.
I tried both in the testnet and on https://localhost/. I get the "Hello, World!" message on / but the /.well-known/openid-configuration endpoint is a 404 somehow. I checked the git version in /app inside the container and it's really at the latest dev branch, and all the code is there. But it's somehow not behaving in the same way as on my host machine.

root@1cbea575891e:/solid-app-kit# cat test9.txt 
SET a " \":1"
root@1cbea575891e:/solid-app-kit# cat test9.txt |  redis-cli --pipe
All data transferred. Waiting for the last reply...
ERR unknown command '2'
ERR unknown command '$4'
ERR wrong number of arguments for 'echo' command
ERR unknown command '$20'
ERR unknown command ''
^C
root@1cbea575891e:/solid-app-kit# cat test9.txt | head | redis-cli --pipe
All data transferred. Waiting for the last reply...
Last reply received from server.
errors: 0, replies: 1
root@1cbea575891e:/solid-app-kit# 

I don't know what's happening here, but something seems to be going wrong with the way characters are escaped when piping data.txt to redis-cli --pipe. This only happens in the solid-app-kit docker image, not on my Mac OS laptop.

To work around it, I'll just | head, unless I can find the way to fix it properly some day.

https://localhost/ocm-provider/ works when I run with -p 443:443.
But https://server/ocm-provider/ does not work when I run with --network=testnet.
Not sure what causes the difference. Does the server decide only to expose the endpoint locally and not on the public interface?
Is there an old instance running on my Docker testnet that's serving the request instead of the system-under-test?
Will look at it with fresh eyes some other day.

• I'm running latest master of https://github.com/inrupt/solid-auth-fetcher on localhost.
• Executing DEBUG=* npm run dev-server
• browsing to http://localhost:3001 and entering my webID https://michielbdejong.inrupt.net/profile/card#me
• it retrieves https://michielbdejong.inrupt.net/.well-known/openid-configuration#me (see inrupt/solid-client-authn-js#186)
• it ends up on https://inrupt.net/authorize?response_type=id_token%20code&redirect_uri=http%3A%2F%2Flocalhost%3A3001%2Fredirect&scope=openid%20profile%20offline_access&client_id=coolApp&code_challenge_method=S256&code_challenge=FudSn-feQo7EFrt3myuLmqT13N7KNS6H_QbSaicbghs&state=ab5f0d2c-d9a8-457f-a010-bf5ea0b3f7ea but there is an Unauthorized error (doesn't prompt for login, even with cookies removed and private browsing etc).
• trying to use the local solid server also doesn't get me much further, see inrupt/solid-client-authn-js#187

I'll dive deeper into the code and try to reverse-engineer how the protocol is supposed to work on paper.

It's now possible to specify SERVER_ROOT and not use the testnet that ./runTests.sh and ./runTesterAgainstServer.sh use. I'll document this for @poef and @Potherca to use.

I see AuthManager.java will do a POST with fields "username" and "password". This works for NSS and should also work for PSS. For solid-nextcloud it will be harder because there we need Puppeteer to log in.

I added the rudimentary https://github.com/pdsinterop/test-suites/blob/master/servers/nextcloud-server/Dockerfile which runs Nextcloud on port 443, but it shows the initial "configure me" screen. We should probably add in a config.php file which creates a user `alice' / '123', adds in our Nextcloud app, and enables it.

The token test is currently failing against NSS. They used to work, until we changed them to work for Nextcloud-server. :)

The LDP-BasicContainer test suite is maybe just a small aspect of this.
Excludes the WAC part.

The code in https://github.com/solid/webid-provider-tests/blob/master/test/surface/authorize-endpoint.test.ts#L8
was only tested on node-solid-server. I should have a version for nextcloud-server, including:

curl -ki https://localhost/login | grep requesttoken
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  5524  100  5524    0     0  71740      0 --:--:-- --:--:-- --:--:-- 71740
 data-requesttoken="BAw3N1zas5Z8O8Z3dbH2tYhaHbSE963wtep3iLap+EU=:Vz1YZgS+mOxNS60cRdaRxu4tTuP0wMaE34IQsfTLkyI=">

and 'user' instead of 'username' in https://github.com/solid/webid-provider-tests/blob/master/test/surface/authorize-endpoint.test.ts#L13

There's a slight difference between the /ocm-provider/ JSON from Nextcloud and from ownCloud. This is the one from ownCloud, compared to the one from Nextcloud:

cd ./testers/open-cloud-mesh/tester
npm install
SERVER_ROOT=https://demo.owncloud.org npm run jest

> [email protected] jest /Users/michiel/gh/pdsinterop/test-suites/testers/open-cloud-mesh/tester
> jest

 FAIL  test/surface/discovery.test.ts
  ● Discovery at /ocm-provider/ › contains service description

    expect(received).toEqual(expected) // deep equality

    - Expected  - 6
    + Received  + 2

      Object {
        "apiVersion": "1.0-proposal1",
        "enabled": true,
    -   "endPoint": "https://localhost/ocm",
    -   "resourceTypes": Array [
    +   "endPoint": "https://demo.owncloud.org/apps/federatedfilesharing",
    +   "shareTypes": Array [
          Object {
            "name": "file",
            "protocols": Object {
              "webdav": "/public.php/webdav/",
            },
    -       "shareTypes": Array [
    -         "user",
    -         "group",
    -       ],
          },
        ],
      }

We can base this on https://github.com/solid/test-suite/tree/master/testers/websockets-pubsub and can contribute back there, but should expand it add to tests for access control based on the AUTH command.

Gathering some information about Solid's new webid-oidc protocol with DPop, as a basis for writing the test suite for that:

• solid-auth-fetcher, a client-side library for it
• Solid spec issue
• Node-Solid-Server PR
• A Trellis PR detailing old and new format
• DPop Internet Draft
• Spec panel meeting notes with ongoing report on Adam's upcoming spec doc

I haven't found any automated tests for it so far, although I guess the solid-auth-fetcher examples can be used for manual testing.