search

nodeSolidServer / node-solid-server

Solid server on top of the file-system in NodeJS
https://solidproject.org/for-developers/pod-server
Other
1.78k stars 297 forks source link

WebID's from v5.3 server not working to access resource on v5.2.3 server #1439

Closed michielbdejong closed 4 years ago

michielbdejong commented 4 years ago

I can edit https://solidos.solid.community/Team/SolidOs%20team%20chat/index.ttl#this with my https://michielbdejong.solid.community/profile/card#me webid, but not with myhttps://michielbdejong.inrupt.net/profile/card#me webid (getting a 503)

bourgeoa commented 4 years ago

solid.community his still on NSS 5.2.3 It was not stated that there was a webId compatibility issue with the introduction of an additional new protocol.

michielbdejong commented 4 years ago

I'll update it to >=5.3 soon, that should resolve the issue.

bourgeoa commented 4 years ago

There is a solid.community test server : https:solid.community:8443 running NSS 5.3

michielbdejong commented 4 years ago

ha cool, I wasn't aware of that. I just volunteered in https://gitter.im/solid/node-solid-server to take over from @jaxoncreed as "primary bug responder" for NSS. We're also tagging a new version of mashlib and once that's done, I'll update the mashlib version in NSS, tag v5.4, and deploy it to solid.community.

bourgeoa commented 4 years ago

@michielbdejong @jaxoncreed We will test it has soon it is available

We are also waiting to see included :

michielbdejong commented 4 years ago

I'll have a look at both of those, thanks for the heads up.

bourgeoa commented 4 years ago

@michielbdejong Does that mean that the new token is automatically used by the server under v5.3.0 ? Then webId's are not anymore compatible with all running servers (NSS or others) if they are not upgraded ?

I don't know the reasons behind the new token. Where can I find information and a discussion on the compatibility/migration problems ?

michielbdejong commented 4 years ago

The new token format is described in https://github.com/solid/authentication-panel/blob/master/oidc-authentication.md. The reason for switching to it is to align webid-oidc more with OAuth2 in general, and that way we benefit more from the security expertise that exists outside the Solid community.

This issue is a bug, and upgrading is a workaround, not a fix or a part of the planned upgrade path. Maybe we can still fix it, and then newer versions of NSS will be compatible with older versions again. But the priority of that depends on how many v5.2 servers will remain by then. We can discuss in our video chat now!

bourgeoa commented 4 years ago

I would like to continue the discussion on this bug, because I feel I do not understand what is happening.

I thought that the premises are :

The consequence should be :

I understand that NSS is both a webId provider and a solid-server. So my questions are :

I recently read that in general when using API entry points you should be able to say what version you understand or are using. So you should ask I'm expecting v1 version and be returned a v1 compatible or an error. Is it the actual philosophy.

bourgeoa commented 4 years ago

I made some tests adding NSS 5.3.0 webId to acl in resources of a NSS 5.2 server.

I do not get a 503 error I can access the resources with the 5.3.0 webId (Read Write Control) and do read create delete resources

The only point is : there seem to be a very bad performance.

megoth commented 4 years ago

The reduced performance might be related to https://github.com/linkeddata/rdflib.js/issues/419

bourgeoa commented 4 years ago

I made some more tests adding acl:agent to acl rule (so that a rule as more than one acl:agent)

I does not seem to be related to the new token introduced in 5.3.0 I open a new issue