ipv6 ready

Note 1. After making use of a jump within this page, such as clicking Fig.7, you should be able to jump back by going back one page using your web browser's back button.

Note 2. Before extending the topic I coined at Symptom: Access to Main ("index") Page Denied for Owner's WebID When Setting Up a Solid Server on a Windows Machine (formely Setting Up a Solid Server on a Windows Machine) - Server Administration - Solid Community Forum.htm to this site, the quality of the symptom description presented at that site suffered from the fact that their new users as I then was, can only put one image and only two links in a post. This site has not got such limitation imposed. However, take note of the fact that this site due to origin server maintenance is intermittently operated with intermediate interruptions, as a general rule between 20:00 and 07:00 GMT/UTC o'clock, and temporarily only.

Symptom: Access to Main ("index") Page Denied for Owner's WebID When Setting Up a Solid Server on a Windows Machine

Windows 8 v6.2.9200 (x64), Node.js v10.13.0-x64 (/v8.12.0-x64 up to 2018-11-08 GMT/UTC+1 (CET)), npm 6.4.1, Node Solid Server (NSS) 4.2.0-rc.0

A (Node) Solid Server is one, possibly the first, of completely decentralized and linked data applications being by design fully in users' hand, linked data being WebIDs, their sum hosted on a URI (a Solid Server instance URL) occasionally being called a unique personal online data store (PODS or pods). WebID is a standardized method for internet services and members to know who they are communicating with. The WebID specifications define a set of proposed standards for identity, identification and authentication on HTTP based networks. Technically speaking, a WebID is an HTTP URI that denotes ("refers to" or "names") an agent on an HTTP based network such as the Web or an enterprise Intranet. In line with linked data principles, when a WebID is de-referenced ("looked up"), it resolves to a profile document (a WebID-Profile) that describes its referent (what it denotes). The user may distribute personal information among several pods and retains complete ownership and control of data in them: what data each pod contains and which applications have permission to use the data.

This is just to better visualize the topic at hand. A picture is worth a thousand words.

I did not find the time to blur the NSS prototype site Uniform Resource Locator (URL), as a Uniform Resource Identifier (URI) that happens to point to the site (as a resource) over a network, being characteristic of the symptom.

Validation of the NSS Installation

Running the Linked Data Platform

An attempt to run the symptomatic NSS linked data platform deplorably fails on unknown option '--no-webid', cf. Fig.0a.

Fig.0a - Running the linked data platform: Error: unknown option '--no-webid'.

Running the Linked Data Platform.png presented temporarily only

Testing NSS Locally

xxx testing NSS locally 12 info lifecycle [email protected]~standard: Failed to exec standard script, cf. Fig.0b.

Fig.0b - Testing NSS locally: 12 info lifecycle [email protected]~standard: Failed to exec standard script.

Testing NSS Locally.png presented temporarily only

Symptom Overview

After the installation of a NSS prototype by the npm package manager, a command line client included as a recommended feature in Node.js run-time environment installer that interacts with a remote registry and independent of the server TLS/SSL certificate, I am hitting a solid:server Error page because of: { [HTTPError: Access to https://solid.durdik.ch:8443\index.html requires authorization]..., cf. Fig.8a and solid:server Error page because of: { [HTTPError: Access to https://solid.durdik.ch:8443\index.html denied for https://solid.durdik.ch:8443/profile/card#me]..., cf. Fig.14, eventually making for No permission to access this resource: You are currently logged in as https://solid.durdik.ch:8443/profile/card#me, but do not have permission to access https://solid.durdik.ch:8443/, cf. Fig.13.

Symptom Details

Initial Access Authorization

Given

... this is what you are presented with when either accessing the freshly by the nmp package manager installed symptomatic NSS for the first time or deleting possibly available and still valid (session) cookie solid.durdik.ch and accessing the NSS straight after restarting it asking you for owner's log in and implicitly letting it seem like his (possibly alternative) registration was an option:

Fig.7 - Accessing the freshly installed symptomatic NSS prototype at URL https://solid.durdik.ch:8443/ either for the first time or straight after restarting it.

@a.png presented temporarily only

.The working hypothesis is that this page is generated «home-made» in a format as if it was generated by OAuth 2.0, an authorization framework, cf. Section Access Authorization Denial. Take note of the favicon.ico protected by the Web Access Control (WAC) and read out from the NSS's filesystem root, cf. Fig.8a, and as expected displayed in the upper left corner of the web browser's window.

However, take note of the index.html analogously, cf. Fig.2 and Fig.3, protected by WAC and unexpectedly not read out from the NSS's filesystem root, cf. ibid. line reading solid:server Error page because of: { [HTTPError: Access to https://solid.durdik.ch:8443\index.html requires authorization]..., additionally also cf. Fig.14.

Fig.8 - NSS Console before accessing the freshly installed symptomatic NSS prototype either for the first time or straight after restarting it.

@b.png presented temporarily only

Take note of the C:\inetpub\solid.durdik.ch\data being the NSS's filesystem root.

Take note of the fact that the NSS console output is divided in Fig.8 and Fig.8a to make for more feasible comparison with Fig.14.

Fig.8a - NSS Console strait after accessing the freshly installed symptomatic NSS prototype at URL https://solid.durdik.ch:8443/ either for the first time or straight after restarting it resulting in symptomatic NSS prototype's demanding of (owner's) logging in, cf. Fig.7.

@ba.png presented temporarily only

In fact, cf. Fig.8, the symptomatic NSS is first initializing issuing fathomable and useful, but also partly cryptic messages, like

  1. solid:settings Server URI: https://solid.durdik.ch:8443...
  2. solid:settings Auth method: oidc...
  3. solid:settings Db path: ./.db...
  4. solid:settings Config path: ./config...
  5. solid:settings Suffix Acl: .acl...
  6. solid:settings Suffix Meta: .meta...
  7. solid:settings Filesystem Root: C:\inetpub\solid.durdik.ch\data/...
  8. solid:settings Allow WebID authentication: true...
  9. solid:settings Live-updates: true...
  10. solid:settings Multi-user: false...
  11. solid:settings Suppress default data browser app: undefined...
  12. solid:settings Default data browser app file path: default...
  13. solid:settings Base URL (--mount): /...
  14. solid:settings SSL Private Key path:...
  15. solid:settings SSL Certificate path:...
  16. Solid server (4.2.0-rc.0) running on https://localhost:8443/
    Press <ctrl>+c to stop
  1. solid:authentication No provider keys found, generating fresh ones...
  2. solid:authentication Error: Cannot read property 'toString' of null
  3. solid:authentication at RSASSA_PKCS1_v1_5.generateKey (C:\Users\solid.durdik.ch\AppData\Roaming\npm\node_modules\solid-server\node_modules\@trust\webcrypto\src\algorithms\RSASSA-PKCS1-v1_5.js:187:13)
  4. solid:authentication at Promise (C:\Users\solid.durdik.ch\AppData\Roaming\npm\node_modules\solid-server\node_modules\@trust\webcrypto\src\SubtleCrypto.js:207:42)
  5. solid:authentication at new Promise (<anonymous>)
  6. solid:authentication at SubtleCrypto.generateKey (C:\Users\solid.durdik.ch\AppData\Roaming\npm\node_modules\solid-server\node_modules\@trust\webcrypto\src\SubtleCrypto.js:205:12)
  7. solid:authentication at RsaKeyPair.generateKey (C:\Users\solid.durdik.ch\AppData\Roaming\npm\node_modules\solid-server\node_modules\@solid\keychain\src\algorithms\RsaKeyPair.js:56:8)
  1. solid:authentication at Function.generateKey (C:\Users\solid.durdik.ch\AppData\Roaming\npm\node_modules\solid-server\node_modules\@solid\keychain\src\KeyChain.js:47:22)
  2. solid:authentication at Promise.all.Object.keys.map.key (C:\Users\solid.durdik.ch\AppData\Roaming\npm\node_modules\solid-server\node_modules\@solid\keychain\src\KeyChain.js:145:27)
  3. solid:authentication at Array.map (<anonymous>)
  4. solid:authentication at KeyChain.rotate (C:\Users\solid.durdik.ch\AppData\Roaming\npm\node_modules\solid-server\node_modules\@solid\keychain\src\KeyChain.js:139:27)
  5. solid:authentication at Promise.all.Object.keys.map.key (C:\Users\solid.durdik.ch\AppData\Roaming\npm\node_modules\solid-server\node_modules\@solid\keychain\src\KeyChain.js:160:23)...
making, as has just been presented, cf. Fig.8a, for... or rather making, cf. Fig.14, for... or rather making for, xxx Use Case 1, but without all /*.acl files, including /.acl or rather making for, xxx Use Case 1, but without all /*.acl files but /.acl or rather making for, xxx Use Case 2, but without all /*.acl files, including /.acl or rather making for, xxx Use Case 2, but without all /*.acl files but /.acl
Use Case 1 Use Case 2 Use Case 3 Use Case 4 Use Case 5 Use Case 6
Step 1 solid:authentication Logging in via username + password... solid:authentication Logging in via username + password... xxx
Step 2 solid:authentication Attempting to login user: solid.durdik.ch:8443/profile/card#me... solid:authentication Attempting to login user: solid.durdik.ch:8443/profile/card#me... xxx
Step 3 solid:authentication User found, password matches... solid:authentication User found, password matches... xxx
Step 4 solid:authentication Initializing user session with webId: https://solid.durdik.ch:8443/profile/card#me... solid:authentication Initializing user session with webId: https://solid.durdik.ch:8443/profile/card#me... xxx
Step 5 solid:authentication Login successful, redirecting to https://solid.durdik.ch:8443... solid:authentication Login successful, redirecting to https://solid.durdik.ch:8443... xxx
Step 6 solid:accounts Account solid.durdik.ch is not available (for /)... solid:accounts Account solid.durdik.ch is not available (for /)... solid:accounts Account solid.durdik.ch is not available (for /)... solid:accounts Account solid.durdik.ch is not available (for /)... solid:accounts Account solid.durdik.ch is not available (for /)... solid:accounts Account solid.durdik.ch is not available (for /)...
Step 7 solid:index Looking for index in /... solid:index Looking for index in /... solid:index Looking for index in /... solid:index Looking for index in /... solid:index Looking for index in /... solid:index Looking for index in /...
Step 8 solid:index Found an index for current path... solid:index Found an index for current path... solid:index Found an index for current path... solid:index Found an index for current path... solid:index Found an index for current path... solid:index Found an index for current path...
Step 9 solid:ACL Using ACL https://solid.durdik.ch:8443\index.html.acl for ./solid.durdik.ch:8443\index.html... solid:ACL Using ACL https://solid.durdik.ch:8443\index.html.acl for ./solid.durdik.ch:8443\index.html... xxx solid:ACL Read access denied to https://solid.durdik.ch:8443/profile/card#me... xxx
Step 10 solid:permissions Checking access for agent undefined... solid:permissions Checking access for agent https://solid.durdik.ch:8443/profile/card#me... xxx xxx
Step 11 solid:permissions No groups authorizations exist... solid:permissions No groups authorizations exist... xxx xxx
Step 12 solid:ACL Read access denied to (none)... solid:ACL Read access denied to https://solid.durdik.ch:8443/profile/card#me... solid:ACL Read access denied to (none)... xxx xxx
Step 13 solid:server Error page because of: { [HTTPError: Access to https://solid.durdik.ch:8443\index.html requires authorization] xxx, status: 401 }... solid:server Error page because of: { [HTTPError: Access to https://solid.durdik.ch:8443\index.html denied for https://solid.durdik.ch:8443/profile/card#me] xxx, status: 403 }... solid:server Error page because of: { [HTTPError: Access to https://solid.durdik.ch:8443\index.html requires authorization] xxx, status: 401 }...
solid:server Error page because of: { [HTTPError: Access to https://solid.durdik.ch:8443\index.html requires authorization] xxx, status: 401 }...
solid:server Error page because of: { [HTTPError: Access to https://solid.durdik.ch:8443\index.html denied for https://solid.durdik.ch:8443/profile/card#me] name: 'HTTPError', message: 'Access to https://solid.durdik.ch:8443\\index.html denied for https://solid.durdik.ch:8443/profile/ca rd#me', status: 403 }...
solid:server Error page because of: { [HTTPError: Access to https://solid.durdik.ch:8443\index.html requires authorization] xxx, status: 401 }...
Step 14 solid:server Display login-required for https://solid.durdik.ch:8443/... solid:server Display login-required for https://solid.durdik.ch:8443/... solid:server Display login-required for https://solid.durdik.ch:8443/... xxx xxx xxx
Step 15 xxx xxx solid:ACL Read access denied to (none)... xxx xxx xxx
Step 16 xxx xxx solid:server Error page because of: { [HTTPError: Access to https://solid.durdik.ch:8443/favicon.ico requires authorization] name: 'HTTPError', message: 'Access to https://solid.durdik.ch:8443/favicon.ico requires authorization', status: 401 }...
solid:server Error page because of: { [HTTPError: Access to https://solid.durdik.ch:8443/favicon.ico requires authorization] name: 'HTTPError', message: 'Access to https://solid.durdik.ch:8443/favicon.ico requires authorization', status: 401 }...

aaa█solid:server Error page because of: { [HTTPError: Access to https://solid.durdik.ch:8443/favicon.ico requires authorization] name: 'HTTPError', message: 'Access to https://solid.durdik.ch:8443/favicon.ico requires authorization', status: 401 }...

solid:server Error page because of: { [HTTPError: Access to https://solid.durdik.ch:8443/favicon.ico requires authorization] name: 'HTTPError', message: 'Access to https://solid.durdik.ch:8443/favicon.ico requires authorization', status: 401 }...
Step 17 xxx xxx solid:server Display login-required for https://solid.durdik.ch:8443/favicon.ico... xxx xxx xxx

█xxx

and successively is, cf. Fig.8a and Fig.14, ...

solid:ACL Using ACL https://solid.durdik.ch:8443/favicon.ico.acl for ./favicon.ico...

resulting in successfully, cf. Fig.8a and Fig.14, ...

solid:handlers GET -- Reading C:\inetpub\solid.durdik.ch\data\favicon.ico...

though both index.html.acl and favicon.ico.acl are stored in one and the same directory on the NSS and first of all the Web Access Control (WAC) permissions are defined analogously therein, cf. this section above. Strangely enough, the NSS is in virtually the same condition (cf. also analogous permissions in index.html.acl and favicon.ico.acl presented in Fig.3 and Fig.2) showing paths to the locations of those files in a different way: ./solid.durdik.ch:8443\index.html and ./favicon.ico.

The working hypothesis is that the symptomatic NSS for some reason did not consistently initialize itself, possibly with the owner's WebID using WebID-OIDC protocol when installed. Apart from this, preliminary analysis revealed that the culprit variable (alternatively) could be a flaw in symptomatic NSS scripts involved in dynamically reading out pages index.html. Anyway, take note of the favicon.ico read out as expected and displayed in the upper left corner of the web browser's window.

Welcome to the Solid Prototype vs "name":"durdik" – Solid Home

There is a file index.html—apart from one with the same content in C:\Users\solid.durdik.ch\AppData\Roaming\npm\node_modules\solid-server\default-templates\server—in C:\inetpub\solid.durdik.ch\config\templates\server of the NSS ready to present a Welcome to the Solid Prototype. However, the page index.html stored in the NSS's filesystem root is ready to present a public homepage of "name":"durdik", whose WebID is https://solid.durdik.ch:8443/profile/card#me ("webId":"https://solid.durdik.ch:8443/profile/card#me").

This is an indication of a misunderstanding, since █xxx, cf. Fig.10 and Fig.11.

Apart from this, the C:\inetpub\solid.durdik.ch\data\common\ subdirectory i. a. containing css\ with CSS files linked into the index.html stored in the NSS's filesystem root is not stored in the NSS's filesystem root.

Thus, the installation of the symptomatic NSS might be at least with regard to some CSS files incomplete.[verification needed]

Independent of (non-nmp package manager) manual copying the directory common from C:\Users\solid.durdik.ch\AppData\Roaming\npm\node_modules\solid-server, the index.html stored in the NSS's filesystem root can be displayed via the NSS by typing its URI into the web browser, cf. Fig.9.

Fig.9 - Accessing the symptomatic NSS prototype at URL https://solid.durdik.ch:8443/index.html presenting a "name":"durdik" – Solid Home.

durdik - Solid Home.png presented temporarily only

Web Access Control (WAC) works for this particular reading out as expected.

This webpage possibly is not prepared dynamically during initial access authorization. Anyway, it is stored completed and ready to be accessed in the NSS's filesystem root before the NSS is restarted.

In contrast, this is what you are—as expected—presented with when accessing the corresponding two well-known NSS prototypes:

However, cf. the indication of a misunderstanding in this section above.

Fig.10 - Accessing the well-known NSS prototype at URL https://solid.comunity presenting a Welcome to the Solid Prototype.

@c.png presented temporarily only

Fig.11 - Accessing the well-known NSS prototype at URL https://inrupt.net presenting a Welcome to the Solid Prototype.

@d.png presented temporarily only

Log in with solid.durdik.ch:8443

Buttons denoted Log in on the symptomatic NSS's pages presented in Fig.7 and Fig.9 are active. Clicking on them results in a webpage with URI https://solid.durdik.ch:8443/common/popup.html, cf. Fig.12, even if the directory common is not contained in the NSS's filesystem, cf. Section Welcome to the Solid Prototype vs "name":"durdik" – Solid Home, and i. a. a button labeled Log in with solid.durdik.ch:8443 on it. This button is dead preposterous to reason, independent of the directory common being contained in the NSS's filesystem or not being contained there.

Apart from this, this popup webpage is not stored in the NSS's filesystem root C:\inetpub\solid.durdik.ch\data and seems to be read dynamically from C:\Users\solid.durdik.ch\AppData\Roaming\npm\node_modules\solid-server\node_modules\solid-auth-client\dist-popup.

Fig.12 - Logging in on the symptomatic NSS prototype at URL https://solid.durdik.ch:8443/common/popup.html.

Log in Popup.png presented temporarily only

Access Authorization Denial

Strangely enough, alternative logging in with a specific password, but with an arbitrary Username, including solid—independent of the directory common being stored in the NSS's filesystem root or not being stored there—makes for No permission to access this resource: You are currently logged in as https://solid.durdik.ch:8443/profile/card#me, but do not have permission to access https://solid.durdik.ch:8443/:

Fig.13 - Accessing the symptomatic NSS prototype at URL https://solid.durdik.ch:8443/ after an attempted owner's logging in.

@aa.png presented temporarily only

The working hypothesis is that this page is genuinely generated by OAuth 2.0. Again, take note of the favicon.ico displayed in the upper left corner of the web browser's window.

Fig.14 - NSS Console strait after an attempted owner's ("username":"jan", cf. Fig.5) logging in resulting in symptomatic NSS prototype's access authorization denial, cf. Fig.13.

NSS Console strait after an attempted owner's logging in.png presented temporarily only

A comparison with Fig.8a █xxx.

(Session) Cookie

When accessing the symptomatic NSS site, corresponding (session) cookie is not stored at the web browser client device at initial access authorization.[verification needed] It is stored at later stages as expected.

Installing Node.js v10.13.0(-x64)

In the meantime there is a new Node.js installer at node-v8.12.0-x64.msi installing non-beta Node.js v10.13.0(-x64) Long Term Support (LTS) including the npm package manager, a command line client included as a recommended feature in Node.js installer that interacts with a remote registry. The installation got much more sophisticated since mid-October 2018 and at least visually makes a professional impression. However, as expected, it does not everything it is promising.

I. a. the npm needs some of its modules to be compiled locally..., cf. Fig.100 and I haven't had necessary tools installed, cf. Fig.101.

Fig.100 - Installing Node.js v10.13.0(-x64):Setup / Tools for Native Modules Popup.

node install.png presented temporarily only

Fig.101 - Installing Node.js v10.13.0(-x64):Setup / Tools for Native Modules Installation Console.

node tools.png presented temporarily only

I let the new Node.js installer try to install those tools automatically. My computer didn't reboot as promised and expected and the installation didn't succeed in many respects. It still left my npm installer at version 6.4.1.

After involving the updated Node.js run-time environment, the reference symptom overview, slightly extended based on @Mordax's post, hasn't changed after all.

As a result, current reference working hypothesis is still valid. However, assuming no coding flaw in the NSS scripts themselves, I'm in the meantime slowly coming to conclusion that the NSS consistently initialized itself with the owner's WebID when installed and that the owner's WebID-OIDC protocol installation hardly is the culprit variable.

I'm hardly going to build Node.js from source in this reincarnation of myself.

The last resort would be trying to contact the authoring poets and asking them to at least buy a beer for each of us for lavishing their poem on us and (to an extent) wasting my youth on it.

Preliminary Thoughts

As far as can be seen, the symptomatic NSS is designed to host a unique personal online data store (PODS) of pods, its URI being https://solid.durdik.ch:8443/. Constituent pods are designed to be retrieved by their WebIDs https://[userName].durdik.ch:8443/profile/card#me of [userName]s at will. However, this is currently not what we are focused on, since the NSS actually declines to start properly not accepting owner's initial registering and denying permission to access itself as the resource https://solid.durdik.ch:8443/.

WebID is █xxx. WebID-based protocols (WebID-OIDC, WebID-TLS, WebID-TLS+Delegation) offer a new way to log into internet services. Instead of using a password, for example, the member of an internet service refers to another web address which can vouch for it, cf. en.wikipedia.org/wiki/WebID. The symptomatic NSS is configured to use WebID-OIDC, cf. Fig.8, OIDC being OpenID Connect, an authentication layer, a standard controlled by the OpenID Foundation, on top of OAuth 2.0, an authorization framework, and WebID-TLS (as Login with (Client)Certificate) protocols. One of possible WebIDs is https://solid.durdik.ch:8443/profile/card#me and happens to be the owner's WebID of the symptomatic NSS.

... github.com/solid/solid/issues/153

.

█xxx

.

Current date display standard:

.