Super-administrator should not have all permissions over the api

mentioned in issue applications/hubl#935

I haven't written the changes suggested in #295 (closed) yet so I don't think this is related ?

I think that in general superuser accounts aren't supposed to be used as a day-to-day account, so in my opinion UX-wise it shouldn't be a problem ?

I haven't written the changes suggested in #295 (closed) yet so I don't think this is related ?

Yes, so actually users are super-administrators. At least 4 people per instance, sometime a lot more.

I think that in general superuser accounts aren't supposed to be used as a day-to-day account, so in my opinion UX-wise it shouldn't be a problem ?

Why? I mean, it does not make sense to have two identities as an user, I want the access to the Django's admin from the same user as the one I'm using on different applications.

Yes, so actually users are super-administrators

I'm confused, how is this happening ? In #295 (closed) the issue is that superusers aren't being given special permissions by the API

If people are having their permissions upgraded I think it's likely an issue relating to child containers being analysed based on parent permissions (will be fixed by !193 (merged) )

Why? I mean, it does not make sense to have two identities as an user

Because I think that (ideally) the superusers are one or two sysadmin accounts for the server that has a long and complicated password

In #295 (closed) the issue is that superusers aren't being given special permissions by the API

Actually, when you're a super-user, you have all permissions on everything on server?

Because I think that (ideally) the superusers are one or two sysadmin accounts for the server that has a long and complicated password

I don't think that this model fits for a solid approach, if we want this kind of behavior, maybe we would need a "Give me the power" thing that an authorized user can (de)activate whenever they want?

Actually, when you're a super-user, you have all permissions on everything on server?

I haven't written a unit test to validate what Sylvain said in the issue description but he was describing receiving a 403 when submitting POST from a superuser account. Certainly the permissions serialized for a superuser wouldn't reflect superuser status, though, so it shouldn't be the cause of the UI problems

In Django they have a lot of is_super catches but in the LDPPermissions we don't - our use of has_permission and has_object_permission is extending Django/DRF but the serialization of permissions on resources is custom

I don't think that this model fits for a solid approach

Solid: hack me once, hack me everywhere

I suppose this is already an issue with OIDC, and even if you can just break into someone's phone (since you will have email + text for resetting passwords). In these cases it seems to me that people approach it with multi-factor authentication (e.g. apps often introduce a PIN)

I haven't written a unit test to validate what Sylvain said in the issue description but he was describing receiving a 403 when submitting POST from a superuser account. Certainly the permissions serialized for a superuser wouldn't reflect superuser status, though, so it shouldn't be the cause of the UI problems

I don't know for the Sylvain's issue. But here, using Hubl, whenever I'm super-user, I have every permissions everywhere and I can do whatever I want on app, it works without any 403.

OK strange - so I think we should re-evaluate when !193 (merged) is merged because it will be easier to debug

added BUG label

I need to implement intentional superuser permissions for Energie Partagée - I'm labelling this issue as a bug for now because it sounds like one

But we need to decide in #295 (closed) if we want the behaviour of SuperUserPermissions to be by default a part of LDPPermissions or not (on the issue I also suggested that we can extend OwnerAuthAnonPermissions to include a superuser_perms setting so that it's configurable)

Does this work for Hubl @jbpasquier ?

I'm writing it so that you can set in the server settings:

DEFAULT_SUPERUSER_PERMS = []

and they get nothing :)

With the above setting this issue should be fixed in !193 (merged) by the way

mentioned in commit 9c69c522

mentioned in merge request !193 (merged)

mentioned in commit a9bd62fb

closed via merge request !193 (merged)

Super-administrator should not have all permissions over the api

Designs

Child items 0

Activity