How does authorization by `origin` work?

[renyuneyun]

I'm trying to allow an application to authenticate/authorize(?) itself by using Origin. From SolidOS interface, I changed the sharing permission to a file by adding "A Web app (origin)".

For simplicity, let's assume I have the following:

• http://localhost:9000
• https://my.domain
• http://my.other.domain

How do I make the query from my application? In particular, my application is CLI-based -- in fact, it is a long-running service.

---

My attempts:

I did not find the relevant document on how the request should work. Therefore, I'm using the most naive method: add Origin: xxx (where xxx is one of the origins) to the HTTP request header. For example (using httpie):

https GET https://URL/TO/my_res.ttl Origin:https://my.domain

But this does not work. I encountered slightly different behaviours:

• For NSS (solidcommunity.net), I get 401 Unauthenticated
• For CSS, I get 401 Unauthorized

If omitting the protocol (I assume this is incorrect by nature, as origin needs to have a protocol), I encounter:

• For NSS (solidcommunity.net), I get NamedNode IRI "my.domain" must be absolute
• For CSS, I get 401; the server prints [PermissionBasedAuthorizer] {Primary} warn: Unauthenticated agent has no read permissions in the console

[jeff-zucker]

My understanding is that ​CLI-based apps send a null origin. I am not aware of any way to get around that. The Solid specs have largely skirted the whole issue of CLI-based apps (if you looked back over the years you will me raising that as an issue repeatedly). This means that each server handles them differently. ESS assigns a WebID to each app so that can be used instead of origin. AFAIK, neither NSS nor CSS support authorization rules targeting CLI-based apps.

[jeff-zucker]

If it is a long-running app, does this mean there is basically only one instance of the app? If so, you could create a WebID for the app, have it login and write your authorization rules for that user.

[renyuneyun]

Thanks @jeff-zucker for the more detailed explanation! How does browser app handle the origin thing? Simply use the origin of the logged-in user's identity provider?

For the time being, I can assume there is only one instance of the app. How do I deal with that WebID for it? Simply create a Solid pod and log in to that pod from the app (how? from browser?)? And will it be possible to automatically log-in if the app restarts?

Or, is there a simpler way to just prove who I (the app) am? In the end, I just need to allow my app to identify itself in a way that any users' pods can set access control rules for it.

[jeff-zucker]

How does browser app handle the origin thing? Simply use the origin of the logged-in user's identity provider?

Browsers send the origin of the page the app is launched from. So if you use an app at http://example.com/someApp.html, then http://example.com is the origin. This is regardless of the user and their login status.

For the time being, I can assume there is only one instance of the app. How do I deal with that WebID for it? Simply create a Solid pod

Yes.

and log in to that pod from the app (how? from browser?)? And will it be possible to automatically log-in if the app restarts?

The readme for my Solid-Node-Client details what had been the ways to login from a CLI based app. It still works fine with NSS and CSS but may not work with ESS, you'd have to check the Inrupt docs. It can be automated.

Or, is there a simpler way to just prove who I (the app) am? In the end, I just need to allow my app to identify itself in a way that any users' pods can set access control rules for it.

Am I understanding correctly that your app would be operated from a server, not by a user? Or does the user operate your app as themself? If as themself, they can just make the resources private to them as a user and ignore the app permission. For CLI-based apps, app permission is not needed. If it is operating from a server but meant to operate on the resources of multiple pods, then I think the easiest is still going to be to create a user. So create a pod for AppX. Have your users create persmissions for AppX as a user, not as an app . Then have your app login as AppX when it runs. This way when it visits one of your user's pods, the pod will say _"the origin is null so I don't need to check app permissions and the user is AppX who is authorized here".

[jeff-zucker]

184 is another consequence of this lack of consistency about null origin in Solid - it focuses on the use case of a mobile app trying to login from a CLI and launch a browser session with it. The errors show up in the browser when using SolidOS, but It really doesn't have to do with SolidOS, rather with logging in from a CLI.

[timbl]

The Origin: is sent by the bowser automatically to warn the server that the request comes from a webapp. Isn't so much as the app gaining access from sending the Origin header -- it is the app avoiding blocked by the cross origin protection in the browser. A double negative thing. By default web apps are not allowed internally by the browser to read anything from any different origin. This makes using them with solid pods, public data sources, etc a pain.
So what you do is put the web app at the domain of choice, say https://my.domain, and give that origin access to the data the app will need, and the solid code will jump though the hoops necessary to persuade the browser to let the fetch() work.
See also https://www.w3.org/DesignIssues/WebAppDistrustCORS.html