nodesolidserver / acl-check Goto Github PK

This module uses mostly console.log and is pretty chatty. We need to use a logger framework with at least info, debug and trace levels.

We should pick something that could be brought to v.next too, and so it should have more levels than that, be maintained and in common use, integrate well with test runs (so that different levels can be chosen directly on the command line), and be easy for people to set loglevels if they need help debugging stuff.

When no resource owners trust any apps, this error is thrown. Instead, a promise for the empty array should be returned.

I've been thinking, and I feel that it would be better to have a function accessDenied instead of and as the complement of checkAccess.

The main rationale is that rejecting access should always come with a reason. While we discussed this, and there is a possibility that checkAccess could be called with different parameters and so let NSS sort out the reason for rejection. However, it is much easier for the library to give the reason directly in the return value.

Then, the rationale for having the complement is that the reason can be given in a truthy value, e.g. simply a string, but no reason is needed for when access granted, so that can be given as simply false or some other falsy value. Then, you can always do

if (!accessDenied(...)) {
  // Give the resource to the client
}

if that's all you want to do.

Some other name for the function is also OK, I would primarily want the reason clear. I think this would simplify a lot.

Symptom: Attempt to PUT an ACL file fails "Not all modes needed" "missing mode: Control" when in fact the agent does have control.

This line seems to filter modes by origin trusted modes whether or not this request has an origin.

In https://github.com/solid/acl-check/blob/master/src/acl-check.js#L192

Given a folder contains a .acl file specifying permissions to a file inside that folder, but does not say something about permissions to the folder itself:

<#owner>
    a acl:Authorization;
    acl:agent <https://angelo.veltens.org/profile/card#me>;
    acl:accessTo <./file.ttl>;
    acl:mode acl:Read, acl:Write, acl:Control.

The parent folder grants all access for the same agent as default (acl:default)

.
├── .acl # grants all access via `acl:default`
├── acltest
│   ├── .acl # contains the content seen above
│   └── file.ttl

Actual behaviour:

Both, the folder and the file.ttl are unreachable for the agent (403 Forbidden).

Expected behaviour:

Since the .acl does not specify access control for the folder, the parent folder .acl should be checked and access granted to the folder (granted by parent .acl) and to the file.ttl (granted by the folder's .acl).

The root .acl file of NSS contains a mailto: based authorization like this:

# Optional owner email, to be used for account recovery:
acl:agent <mailto:[email protected]>;

When trying to create a file in the root of the POD, it fails and the following error appears in the NSS logs:

could not fetch owner doc NamedNode {                                                                                                   
  termType: 'NamedNode',                                                                                                                                                        
  value: 'mailto:[email protected]' } { [HTTPError: File not found: /opt/solid/datanull]                                                                                 
  name: 'HTTPError',                                                                                                                                                            
  message: 'File not found: /opt/solid/datanull',                                                                                                                               
  status: 404 }

When I remove the mailto: based acl:agent it works, but this is only a workarround.

There is some work needed around package.json and that needs to be done to release it to npm.

Expected behaviour:

A GET request to a resource, that is publically readable (e.g. a Solid WebID profile) should succeed with 200 OK from any orgin.

Actual behavour:

A GET request to such a resource is responed with 403 Forbidden when an origin header is set.

Example to reproduce:

ACL for https://angelo.veltens.org/profile:

# The public has read permissions
<#public>
    a acl:Authorization;
    acl:agentClass foaf:Agent;
    acl:accessTo <./>;
    acl:defaultForNew <./>;
    acl:mode acl:Read.

curl with origin:

▶ curl -I -H Origin:https://markbook.org https://angelo.veltens.org/profile/card
HTTP/2 403

curl without origin:

▶ curl -I https://angelo.veltens.org/profile/card                               
HTTP/2 200

From the spec:

[...] This is the algorithm the server must go through.

• If the requested mode is available to the public, then succeed 200 OK [...]

Source: https://github.com/solid/web-access-control-spec#referring-to-origins-ie-web-apps

You now need to call this library twice, once to get the trusted modes (passing it a fetcher callback, which is also a bit of a muddled boundary), and then to determine access.
The two functions even have a chunk of identical code at the beginning, so this can definitely be improved with a refactor.

Dear repository maintainer,

On behalf of the Solid Team, thanks for creating resources for the Solid project. We appreciate your efforts!

A new vision on the github.com/solid namespace

We want to give all projects the spotlights they deserve, and that's why we have taken the decision to re-envision what the github.com/solid namespace will contain going forward.

Today, it is a mix of documents that are authoritative to Solid (such as specifications and processes), and software code in various stages of completion, some of which date back to when Solid was an MIT project.

Starting May 2022, github.com/solid will be a space for the authoritative documents, as described in the process repository.

Please help us by moving this repository

For that reason, we kindly ask you to move this repository to a different GitHub organization. This could be your personal GitHub username, or an organization that bundles several of your Solid projects. The choice is entirely yours.

Please let us know what you decide, so we can link to your repositories in the future. Rest assured that the existing link will keep on working; GitHub will redirect it to its new place. If you need any help with the migration, we'll be happy to assist.

Repositories that have not been moved by 1 May 2022 will be moved automatically to https://github.com/solid-contrib/, from where you can still make the decision to move them to another place at a later point in time.

Thanks in advance for your help!

Kind regards,

The Solid Team

Please describe what you did in reproducible steps

1. Log into an SDK generated application (for example https://develop.generator.inrupt.com)
2. Click on the file uploader, which is represented by the profile image.
3. Upload a new file/image
4. Observe a 403 error on the PUT request

How did it work with 4.x series servers?

The file was uploaded properly, and our liveupdates triggered, refreshing the image displayed to the new image

What happened when you tried the same with the 5.x series server?

A 403 error is observed. The error said that I do not have permission to access the newly uploaded file.

Any material that will help, logs, error messages, etc.

Request URL: https://jmartin.inrupt.net/profile/_1560867172000_.jpeg
Request Method: PUT
Status Code: 403 Origin Unauthorized
No permission to access this resource
You are currently logged in as https://jmartin.inrupt.net/profile/card#me, but do not have permission to access https://jmartin.inrupt.net/profile/_1560865124000_.jpeg.

Today we use a simple console.log to output process of ACL-checks. I think we should make this configurable, so that projects depending on the code can configure how things should be logged.

This ties into a broader question of multi-level logging and such, but I think we should start by doing it easy and simply make the simple console.log configurable (i.e. it will be console.log by default, but can be something else if we want).

Does acl-check support this?

nodeSolidServer/node-solid-server#729

acl:trustedApp is described in the WAC specification, in the section Possible future, and describes how a user can list a set of trusted apps in their POD. This is a very useful feature for NSS v5 when strictOrigins are on.

I propose we implement this feature in such a way that it is optional, since it is a proposal in the specification.

See nodeSolidServer/node-solid-server#1362

Both origin and trustedOrigins are mentioned in the usage section in the README. What is this?