search

uvdsl / solid-test-app

Just a test app for debugging :)
MIT License
0 stars 0 forks source link

403 Origin Unauthorized when served from Solid Pod #1

Closed uvdsl closed 2 years ago

uvdsl commented 2 years ago

Problem: When serving the app from a Solid Pod, agent that use the same IDP as the agent providing the app, face errors 403 Origin Unauthorized.

The problem does not occur, when the app is hosted on localhost or some other server. (afaik)

Example: The app is served at [1] at the Pod of uvdsl. When another user x of the same IDP (i.e. with WebId of [2]) uses the app and logs in, he is not prompted with the typical "Allow this application access"-screen. x is able to use the app, but has no access to private resources where she only receives a 403 Origin Unauthorized. This occurs even when the origin is manually added as a trusted app in x's profile. Users from other IDPs, such as inrupt.net, solidcommunity.net, etc. are not affected by this. The user uvdsl from whose pod the app is served is also not affected by this.

Steps to reproduce:

Variant (a) : On this particular instance, create an account at the mentioned IDP [3], though be warned, this is only a experimental node solid server which is regularly out of service as it is a playground for my students (and myself). (There is no guarantee that you won't loose that account if we need to scrap that server.) Then, using the app, you should be able to access your profile card as it is public but not your private folder as it is private and receive said 403. If you use some other IDP, then you should not have any issue at all.

Variant (b): If you are hosting a server yourself: If you want to reproduce this behaviour on your own Pod, make sure that your Pod is configured for multiuser. (0) Clone this repo. (1) cd into the created directory. (2) create a file vue.config.js with the content of module.exports={"publicPath":"/path/to/app/"} where "/path/to/app/" is the path where your app will be served from. In the example of [1], this is /apps/solid-test-app/. (exclude the hostname, use only the path). (3) npm i && npm run build (4) then copy all files from the dist directory to the corresponding location to be served. In the example of [1], I copied the files to the location that is served by the pod, i.e. .../node-solid-server/data/uvdsl.[hostname]/apps/solid-test-app/.

[1] https://uvdsl.solid.aifb.kit.edu/apps/solid-test-app/ [2] https://x.solid.aifb.kit.edu/profile/card#me [3] https://solid.aifb.kit.edu

bourgeoa commented 2 years ago

Tried variant [a] for me it is working. I had the same problem when I mistyped the trustedApp. The trustedApp https://uvdsl.solid.aifb.kit.edu must not end with a /

Agreed that we should be asked to add the trustedApp. Could you please open an issue on https://github.com/solid/node-solid-server ? There must be one but it will help add this on our reminder list.

Happy to see education using solid. Where are you located ? what are you experimenting ? It is helpful to have some ideas of experimental use of solid.

Hope this solve your problem. feel free to come back for questions. Just for information a new version of the server v5.6.18 is available hopefully 0.9 spec compatible.

uvdsl commented 2 years ago

Aaaah, got it. Jup. I missed that the trustedApp has the hostname as object. Not the URI of the app. I had https://uvdsl.host.name/apps/solid-test-app/ but it should only be https://uvdsl.host.name without the path. Would that be something to bring up somewhere (albeit a minor modelling inconvenience)?

Will create an issue as a friendly reminder :)

Thanks again for your help! Much appreciated.

Re your questions: I am a research associate and phd student at the Karlsruhe Institute of Technology (KIT), Germany. More specifically in the research group Web Science [1] at the Institute of Applied Informatics and Formal Description Methods.

Currently, I am looking at the whole hype around Self-Sovereign Identities, Decentralised Identifiers and Verifiable Credentials (VCs) [2], but from a web perspective (not from the crypto-world...) . Regarding possible applications on one hand, but also modelling and semantics on the other hand. As an example (for the server part of solid), imagine using a VC to authorize access to a resource on a solid server. (instead of only relying on the webid of the agent). I could allow my students to have access to my resources on my pod, if they can present a VC signed by the KIT that they are in-fact students.

[1] https://aifb.kit.edu/web/Web_Science/en [2] https://www.w3.org/TR/vc-data-model/