nodeSolidServer / nodeSolidServer/node-solid-server
Access control by origin header not working?
Personne n'a encore pris cette issue.
- Langage dominant
- JavaScript
- Étoiles
- 1.8k
- Forks
- 308
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Description
First a disclaimer - it is very difficult to find any documentation about access control for web-apps, so I am possibly wrong here. But here we go anyway ...
Assuming I have a browser web-app that lets me register my pets. My pets are very valuable to me and I really don't want any other web-apps to snoop into my pet collection even if I am logged in to my POD with some third party web-app.
How do I prohibit other web-apps from accessing my pets? Well, first of all I make sure that access control for my /pets folder is "specific" according to the data browser, which seems to be identical to creating a .acl file for the container. Then what?
At https://www.w3.org/wiki/WebAccessControl#Giving_a_specific_resource_access_to_an_Origin the following is suggested:
[] acl:accessToClass [ acl:regex "https://bblfish.solid.example/.*" ];
acl:mode acl:Write;
acl:origin <https://apps.rww.io> .
So I add acl:origin <https://nothinguseful.org> to verify that no existing app, not even my own pet-app, have access and try to work with the data from the pet-app ... and still have complete access.
The ACL file is located at https://elfisk.solid.community/places/hobby/.acl and contains:
@prefix : <#>.
@prefix n0: <http://www.w3.org/ns/auth/acl#>.
@prefix hobby: <./>.
@prefix c: </profile/card#>.
:owner
n0:accessTo hobby:;
n0:agent c:me, <mailto:jw@elfisk.dk>;
n0:defaultForNew hobby:;
n0:mode n0:Control, n0:Read, n0:Write;
n0:origin <https://nothinguseful.org>.
The HTTP request sent is:
PUT https://elfisk.solid.community/places/hobby/yyy HTTP/1.1
Host: elfisk.solid.community
Connection: keep-alive
Content-Length: 347
authorization: Bearer ...
Origin: https://solidrc.azurewebsites.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36
content-type: text/turtle
Accept: */*
Referer: https://solidrc.azurewebsites.net/Home/Locations
Accept-Encoding: gzip, deflate, br
Accept-Language: da-DK,da;q=0.9,en-US;q=0.8,en;q=0.7,sv;q=0.6,nb;q=0.5
Cookie: connect.sid=...
DNT: 1
@prefix : <#>. ... more turtle stuff ...
As you can see, the origin header is Origin: https://solidrc.azurewebsites.net - which is not matching the acl:origin value.
Is this a bug or me completely misunderstanding it all?
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez par examiner les consignes liées de Web Access Control et l’ACL fournie dans /places/hobby/.acl avec l’en-tête Origin de la requête PUT. Suivez le traitement de l’autorisation du serveur pour acl:origin et vérifiez si une origine non correspondante est refusée, en distinguant le comportement CORS du navigateur du contrôle d’accès côté serveur. Le travail est terminé lorsque le comportement est expliqué et, s’il s’agit d’un bug, couvert par un test reproductible.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- javascript
- Domaine
- authorization, security
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- À l'abandon
- Clarté
- À clarifier
- Accessibilité débutants
- 25/100