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

Become a Pod Provider Server Administration
1

I am setting up a Solid server running on Windows 8 (Node.js v10.13.0-x64 (/v8.12.0-x64 up to 2018-11-08 GMT/UTC+1 (CET)), npm 6.4.1) and understandably do not want to spend my youth with it.

As far as I understand, there is a two-stage authorization when accessing the server, which should make sure that the server is incorporated in the Solid project community. The authorization makes use of Web Access Control (WAC), cf. github.com/solid/web-access-control-spec#web-access-control-wac.

Since the server asked for my registration, I registered at Solid Community (probably www.w3.org/community/solid/), obtained a Web ID (https://[user name]./profile/card#me) and tried logging in on the server with the result being ‘Account [server name part of [site URL]] was not available (for /)’.

Symptom details follow (The [site URL] makes of HTTPS on dedicated port 8443).

Web browser

You are currently logged in as https://[user name A].solid.community/profile/card#me, but do not have permission to access [site URL]'.

Solid server

solid:accounts Account [server name part of [site URL]] is not available (for /) +5s solid:index Looking for index in / +2ms
solid:index Found an index for current path +0ms
solid:ACL Read access denied to https://[user name].solid.community/profile/card#me +3ms
solid:server Error page because of: { [HTTPError: Access to [site URL]\index.html denied for https://[user name].solid.community/profile/card#me] name: 'HTTPError',
message: 'Access to [site URL]\\index.html denied for https://[user name].solid.community/profile/card#me',
status: 403 } +0ms
solid:server Display no-permission for [site URL]/ +1ms

file /.acl


# Root ACL resource for the user account
@prefix acl: .

<#owner>

a acl:Authorization;


acl:agent <[site URL]/profile/card#me> ;

# Optional owner email, to be used for account recovery:
acl:agent <mailto:[a correct e-mail address from registration at the solid community>;

# Set the access to the root storage folder itself
acl:accessTo </>;

# All resources will inherit this authorization, by default
acl:defaultForNew </>;

# The owner has all of the access modes allowed
acl:mode
    acl:Read, acl:Write, acl:Control.



# Data is private by default; no other agents get access unless specifically

# authorized in other .acls

file /index.html.acl


@prefix acl: .
@prefix foaf: .

<#owner>

a acl:Authorization;


acl:agent
    <[site URL]/profile/card#me>;

acl:accessTo </index.html>;

acl:mode
    acl:Read, acl:Write, acl:Control.



<#public>

a acl:Authorization;


acl:agentClass foaf:Agent;  # everyone

acl:accessTo <./index.html>;

acl:mode acl:Read.

Please comment.
1 Like
2

Admittedly, I haven’t done any Solid installations on Windows myself, so take this with a grain of salt.

I’m wondering if this isn’t a case of slash direction.

You can see that the logs are complaining about lack of access to ‘\index.html’, but your acl file has the definition for ‘/index.html’. I would have to go and double-check how the ACL check code in NSS is dealing with resource paths, but have you tried changing to a backslash in acl:accessTo?

3

No, the slash type in
acl:accessTo <./index.html>;

is not the culprit here. Neither is the end of line coding.
Though frankly, the double backslash in a server log line like this:

message: 'Access to [site URL]\\index.html denied for https://[user name].solid.community/profile/card#me',

is somehow suspicious. Anyway, this occurs independently of the slash type.

Unrelatedly, I changed aforementioned *.acl files on the Solid server to the extent that the https://[user name].solid.community/profile/card#me WebID having been logged in with on it was explicitly defined as Web Access Control (WAC) acl:agent in them in the meantime. The Solid server still had a whinge like this:

solid:ACL Using ACL [site URL]\index.html.acl for ./[server name part of [site URL]]\index.html +9ms

solid:permissions Checking access for agent https://[user name].solid.community/profile/card#me +143ms

solid:permissions No groups authorizations exist +1ms

solid:ACL Read access denied to https://[user name].solid.community/profile/card#me +7ms

solid:server Error page because of: { [HTTPError: Access to [site URL]\index.html denied for https://[user name].solid.community/profile/card#me

Hence the WAC implementation by the Solid Project in the Solid server provided for download and the WebID implementation by the Solid Community do not match at present., at least for Windows 8, Node.js v8.12.0-x64, and my relatively empty WebID. Bummer!
4

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

Let us the Solid server call Node Solid Server (NSS).

I did not find the time to blur the NSS Site URL being characteristic of the symptom.

This is what you are presented with when accessing the symptomatic NSS Site for the first time:

![%40a|690x279](upload://7aoRRzjYvg4GixnXx5T9Sx6QJkm.png)
@a.png presented temporarilly only
Presented temporarilly only880×357 18.3 KB

This is what the symptomatic NSS has to say before accessing it and, again, what it complains about when accessing it for the first time:

... and this is what you are - as expected - presented with when accessing the corresponding two well-known NSS prototypes:


When accessing the symptomatic NSS Site, corresponding cookie for the site solid.durdik.ch is not stored at the web browser client device at this stage yet as expected. It is stored at later stages as expected.

Unfortunately, I do not get how to upload images to this forum inline. Apart from this, new users as me can only put one image in a post. Hence, take note of the fact that images presented above due to origin maintenance are presented with intermediate interruptions, as a general rule between 20:00 and 07:00 GMT/UTC o'clock, and temporarilly only.

5

Would this make it possible to you to see the whole story?: nssforum.durdik.ch

6

The working hypothesis is that the symptomatic NSS for some reason did not consistently initialize itself with the owner's WebID when installed, cf. nssforum.durdik.ch.

7

The updated reference 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.

With full details cf. Section Initial Access Authorization presented on an intermittently with intermediate interruptions, as a general rule between 20:00 and 07:00 GMT/UTC o'clock, and temporarily operated web server.

8

The installation of the symptomatic NSS is at least with regard to some CSS files incomplete, cf. nssforum.durdik.ch.

9

After belated (non-NPM) manual correction of the NSS installation by 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.

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

However, this does not solve the issue at hand, intermittently cf. nssforum.durdik.ch/.

10

Just to recap where you’re getting stuck. You are getting an authorization error when using your solid.community webid?

Does your ACL file give permission to that webid?

I see in your examples you specified [site URL]/profile/card#me, but if you are using your solid.community webid, then [site URL] in your ACL examples would need to be your solid.community URL.

11

Apart from my appreciation, still nothing has changed with the symptom so far: Using any WebID I know, I am still hitting a solid:server Error page because of: { [HTTPError: Access to https://solid.durdik.ch:8443\index.html requires authorization]..., cf. Fig.8a, 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.

With full details, straight after its installation by the npm package manager, a command line client included as a recommended feature in Node.js installer that interacts with a remote registry, and starting the NSS prototype, it is asking the owner for log in and implicitly lets it seem like his (possibly alternative) registration was an option. Playing with it around, you are inter alia presented with a webpage with URI https://solid.durdik.ch:8443/common/popup.html and a button labeled Log in with solid.durdik.ch:8443. However, the button is dead preposterous to reason. Whatever else you do and wherever you go, the NSS at its best keeps insisting on 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/.

Now, this message is incorporated also in intermittently operated nssforum.durdik.ch/. Take note of the fact that references (links) above still may shift over time.

Before extending this topic at Setting Up a Solid Server on a Windows Machine - Server Administration - Solid Community Forum.htm to the intermittently operated nssforum.durdik.ch/, I reported on unsuccessful switching to my WebID https://[user name].solid.community/profile/card#me after redefining the Web Access Control (WAC) acl:agent in the relevant *.acl files, i. e. [site URL] being my solid.community URL, when trying enlivening the cryptic NSS.

In fact, it was not me who wanted to use a solid.community WebID with the symptomatic NSS. The NSS does not authorize me as owner with https://solid.durdik.ch:8443/ based WebID to access it, so I just tried what came to my mind at that time. I did not incorporate this attempt in the aforementioned intermittently presented authoritative symptom description, since I feel in the meantime that using other than https://solid.durdik.ch:8443/ based owner's WebID is not what the poet meant to say. However, you better ask the poet, Justin.

Take note of the fact that new users as me can only put one image and only 2 links in a post.

12

Take note of the fact that Fig.8 was divided to make for more feasible comparison with another figure. Hence, the link in the post above shifted from Fig.8 to Fig.8a.

I appreciate being promoted up a trust level. Nevertheless, it is below the line definitely not reasonable to move nssforum.durdik.ch/ here.

13

Take note of the fact that the links below are presented on an intermittently with intermediate interruptions, as a general rule between 20:00 and 07:00 GMT/UTC o'clock, and temporarily operated web server.

This is an update of the reference 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.

14

@gandalfprime How did you set up your SSL? I’m also getting the not allowed permission - I wonder if it has to do with self generated SSL Certs.

15

I don't make use of a self-signed server TLS/SSL certificate and I haven't tried to. Thanks to you, now I also need not try.

Assuming you also are making use of Node.js v8.12.0-x64, take note of the fact that in the meantime there is a new Node.js installer 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 do everything it is promising.

With full details cf. Section Installing Node.js v10.13.0(-x64) presented on an intermittently with intermediate interruptions, as a general rule between 20:00 and 07:00 GMT/UTC o'clock, and temporarily operated web server.

After involving the updated Node.js run-time environment, the reference symptom overview, slightly extended based on @Mordax's post, hasn't changed significantly 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—no offense meant—lavishing their poem on us and for (to an extent) wasting my youth on it.

16

How did you create the private key and certificate pem files in Windows? Most forums and tutorials will use openssl and other external libs. Did you also use any external libs? I am using a university system and it does not allow installations. It does however have PowerShell.

17

For other projects I’ve used java to make the key and pem. Over Thanksgiving I’ll try setting up solid on my Windows box

1 Like
18

Thanks for the suggestion. Will try Java.

19

Did someone say PowerShell? Try https://docs.microsoft.com/en-us/powershell/module/pkiclient/new-selfsignedcertificate?view=win10-ps - it will create all the certificates you want. But they are stored in the Windows Certificate Store, so you need to export them afterwards as PEM-files (which apparently also is what Windows call CER-file) - see https://certsimple.com/help/windows-export-pem-private-key

20

@DameLyngdoh, on the one hand, should you ask about PEM PKI public key TLS/SSL server certificate and TLS/SSL server private key file format because you want to contribute adding your two cents to solve the symptom at hand, take note of the fact that PEM X.509 public key certificate and private key files format is nothing special and is in form identical with some public key certificate files formats or at least with Base64 alternatives of some public key certificate and private key files formats on Windows. Hence, this and on an intermittently with intermediate interruptions, as a general rule between 20:00 and 07:00 GMT/UTC o'clock, and temporarily operated web server presented Fig.8 obviate that these formats are not a culprit variable in the symptom at hand...

Take note of the fact that I moved a symptom unrelated part of this post to the topic Pell-Mell on Setting Up a Solid Server on Windows.

I am looking forward to hearing of anybody who can reproduce the symptom at hand or who can contribute to solving it.