Implement OAuth login #5

Open
opened 3 months ago by fnetX · 3 comments
fnetX commented 3 months ago
Collaborator

As written in the README, the goal of this project is to live with minimal configuration. This means, that we do not want to maintain a user / access list as we currently do, or store many secrets on the server.

The idea is to allow anyone to sign in to the moderation team using OAuth from Codeberg.org, and map the roles based on some criteria, probably the membership in an org or team (ideally configurable).

E.g.:

  • let anyone view transparent action logs
  • allow Codeberg association members to propose actions for cases, maybe view more details about cases
  • let members of the moderation team view more details on cases (e.g. view private repos if reported) and review actions
  • let members of the admin team confirm and execute actions

If someone would like to build this, this is very appreciated.

As written in the README, the goal of this project is to live with minimal configuration. This means, that we do not want to maintain a user / access list as we currently do, or store many secrets on the server. The idea is to allow anyone to sign in to the moderation team using OAuth from Codeberg.org, and map the roles based on some criteria, probably the membership in an org or team (ideally configurable). E.g.: - let anyone view transparent action logs - allow Codeberg association members to propose actions for cases, maybe view more details about cases - let members of the moderation team view more details on cases (e.g. view private repos if reported) and review actions - let members of the admin team confirm and execute actions If someone would like to build this, this is very appreciated.
fnetX added the
enhancement
contribution welcome
labels 3 months ago

@fnetX would like to look into this

@fnetX would like to look into this
Poster
Collaborator

Hmm, I'm just reconsidering the permission model. I think we might want to use

PERMISSION_GUEST = 0 (no login, default)
PERMISSION_USER (registered at Codeberg)
PERMISSION_MEMBER (member of "Codeberg-e.V." organization)
PERMISSION_SUPPORT (member of "Support" team in "Codeberg-e.V.")
PERMISSION_MODERATOR (member of "Moderation" team in "Codeberg-e.V.")
PERMISSION_ADMIN (instance admin)

I think this does better reflect the different permission models we might want to use.

Hmm, I'm just reconsidering the permission model. I think we might want to use PERMISSION_GUEST = 0 (no login, default) PERMISSION_USER (registered at Codeberg) PERMISSION_MEMBER (member of "Codeberg-e.V." organization) PERMISSION_SUPPORT (member of "Support" team in "Codeberg-e.V.") PERMISSION_MODERATOR (member of "Moderation" team in "Codeberg-e.V.") PERMISSION_ADMIN (instance admin) I think this does better reflect the different permission models we might want to use.
Poster
Collaborator

I'd say that org and team matches should stay configurable, so the software can be re-used for other Gitea instances, and adapted later.

This could be a syntax like "orgname/team", allowing to use * as wildcard.

PERMISSION_USER = "*/*" or "*"
PERMISSION_MEMBER = "Codeberg-e.V./*"
PERMISSION_SUPPORT = "Codeberg-e.V./Support"
...
PERMISSION_ADMIN = "admin/*" or "admin", because the "admin" name is reserved anyway for the admin panel.

What do you think?

I'd say that org and team matches should stay configurable, so the software can be re-used for other Gitea instances, and adapted later. This could be a syntax like "orgname/team", allowing to use * as wildcard. ~~~ PERMISSION_USER = "*/*" or "*" PERMISSION_MEMBER = "Codeberg-e.V./*" PERMISSION_SUPPORT = "Codeberg-e.V./Support" ... PERMISSION_ADMIN = "admin/*" or "admin", because the "admin" name is reserved anyway for the admin panel. ~~~ What do you think?
fnetX referenced this issue from a commit 4 weeks ago
Sign in to join this conversation.
Loading…
There is no content yet.