Add a (privileged?) read-only permissions API

selfhoster1312 commented 2 months ago

So it turns out yunohost-portal-api still does not allow generic 3rd party portals, only client-side portal code where the permissions check reside alongside the cookie.

So we're back to square one with workarounds like reading /etc/ssowat/ssowat.json, reading /etc/yunohost/apps and/or connecting to LDAP directly.

I still want a supported/documented/recommended way to consume user permissions server side. I am ready to implement it. I just need to know what it should be in other people's opinions.

alexAubin commented 2 months ago

Not sure to understand what you mean exactly by permission and what's the use case you're thinking about in the back ?

selfhoster1312 commented 2 months ago

So i'm making a new portal. How does my portal query the current user's permission to display app tiles?

for client-side rendering (Javascript), query /yunohost/portalapi/me with the current cookie and you get the information
for server-side rendering (such as yunohost-portal-noscript), there is no recommended way

Previously it was established that the new portal API would address those needs, but now it's here and i'm messing with it i realize it doesn't? To be honest i'm still ok to read LDAP directly, or to read a JSON file on the server directly, as long as it's the recommended way to do things.

An alternative would be a local API on a socket which answers an equivalent of /me but for any user requested.

alexAubin commented 2 months ago

Sooo if I understand correctly you want a way to design a server-side rendered portal (with no JS on the client) ?

selfhoster1312 commented 2 months ago

Yes, that was always my goal since like forever ^^

alexAubin commented 2 months ago

So hmyeah i guess the "simplest"(?) way would be to not reimplement anything an use yunohost as a python lib, something like from yunohost.portal import portal_me (with the code running using the yunohost-portal user) but of course that implies using python

Otherwise yeah, ultimately you have to either reimplement the portal.py logic in your language (reading /etc/yunohost/portal/ and LDAP for the authentication) ...

alexAubin commented 2 months ago

Or I guess a third way would be that you server somehow queries the portal API with the user's cookie etc

selfhoster1312 commented 2 months ago

/etc/yunohost/portal looks great. Would it be ok for you that a portal application get membership of group ynh-portal to read the files in there? Is there a way to declare this in resources.system_user? Should we create a dedicated key? Or just place it in install scripts?

EDIT: actually /etc/yunohost/portal does not have all the features /me has. For example it does not expose the email aliases.

alexAubin commented 2 months ago

Sounds legit yes. I don't think we need a special thing in the system user resource (but maybe we should have a more generic/general way of adding user to arbitrary group, to be kept in mind for packaging v3). A "raw" usermod -a -G in the app script sounds fine

selfhoster1312 commented 2 months ago

So about the /me endpoint and user-specific information... Could i maybe add in user-related functions writing to a /etc/yunohost/portal/DOMAIN.d/user.json file that information, too? Just like app_ssowatconf function does permissions.

alexAubin commented 2 months ago

Theoretically yes, but the thing is that the "source of truth" for user info is supposed to be the LDAP db ... Like, I don't even understand how you're planning to validate that the user's cookie is authentic without using LDAP queries (or maybe you also plan to dump the password hash in the json ... or not check the cookie authenticity)

selfhoster1312 commented 2 months ago

Like, I don't even understand how you're planning to validate that the user's cookie

I don't. That's what SSOWat is for. The HTML form directly submits the login form to yunohost-portal-api which produces a valid cookie. That part's already working thanks to what you merged earlier today. And you can already try it on a real bookworm/unstable instance by placing this repo in a my_webapp/www folder.

That being said, i used to do the LDAP verification in a previous experiment and i'm happy to do that again. If the answer to my neverending questions is "LDAP is the single source of truth forever", then i'm happy with this answer. I was just asking for the recommended way to do things :)

I'm just not sure i can access all of the LDAP db without login, i'll need to check...

YunoHost / issues

Add a (privileged?) read-only permissions API #2433