Document what scopes the api token needs for which features #89

vee commented 2023年05月30日 17:39:48 +02:00

Like the title says, it would be useful to have berg auth login list what scopes are necessary for which features

For example, i needed to grant some privileges for berg user info to work and not error

Like the title says, it would be useful to have `berg auth login` list what scopes are necessary for which features For example, i needed to grant some privileges for berg user info to work and not error

RobWalt commented 2023年07月30日 21:00:55 +02:00

Hey, thanks for opening the issue! I didn't actually notice that yet! It's a bit tricky to find that out though.

Do you have any idea on how to approach this or if it is documented somewhere?

The best idea I have would be to just brute force try every action with any set of permissions which seems rather hard 😬

Hey, thanks for opening the issue! I didn't actually notice that yet! It's a bit tricky to find that out though. Do you have any idea on how to approach this or if it is documented somewhere? The best idea I have would be to just brute force try every action with any set of permissions which seems rather hard 😬

vee commented 2023年07月30日 21:24:56 +02:00

i have no idea unfortunately haha, I just ended up granting everything iirc, but obviously that's pretty bad practice

i have no idea unfortunately haha, I just ended up granting everything iirc, but obviously that's pretty bad practice

RobWalt commented 2023年07月30日 22:16:26 +02:00

Yeah makes sense! I totally get what you mean. I actually did the same for development reasons.

For now, I could at least add a disclaimer that we need to set some permission for the token, but leave the configuration with reasonable values to the user. If they care, they can fine tune it.

I'm not totally happy with that approach and I'd like to provide a more robust description of what's possible but I would really like to post-pone tackling the heart of the issue until the app reaches a fairly stable state (I'm currently working in private to cover more (maybe all?) of forgejos API)

So would it be ok with you if we:

1. add the disclaimer for now
2. I'll include the issue in a long-term todo list

?

Yeah makes sense! I totally get what you mean. I actually did the same for development reasons. For now, I could at least add a disclaimer that we need to set some permission for the token, but leave the configuration with reasonable values to the user. If they care, they can fine tune it. I'm not totally happy with that approach and I'd like to provide a more robust description of what's possible but I would really like to post-pone tackling the heart of the issue until the app reaches a fairly stable state (I'm currently working in private to cover more (maybe all?) of forgejos API) So would it be ok with you if we: 1. add the disclaimer for now 2. I'll include the issue in a long-term todo list ?

augustebaum commented 2024年11月11日 13:59:15 +01:00

Seconded; I've had to re-create a token for the third time now, adding new permissions each time.

Here's my contribution to the trial-and-error process:

• berg auth login requires the read:user permission
• berg pull create requires the write:repository permission

I probably could have deduced this myself to be fair, but having the tool be explicit about it would be better for sure.

Seconded; I've had to re-create a token for the third time now, adding new permissions each time. Here's my contribution to the trial-and-error process: - `berg auth login` requires the `read:user` permission - `berg pull create` requires the `write:repository` permission I probably could have deduced this myself to be fair, but having the tool be explicit about it would be better for sure.

Aviac commented 2025年09月17日 09:22:44 +02:00

I think I found a way to check this via integration tests. I will try to find it out there and once we have it I can document it!

I think I found a way to check this via integration tests. I will try to find it out there and once we have it I can document it!