Add OTP and scopes to login #546

jolheiser · 2023-04-20T03:59:20Z

jolheiser commented

2023-04-20 03:59:20 +00:00

Resolves #542

jolheiser added 1 commit 2023-04-20 03:59:21 +00:00

feat: add otp and scopes to login

Signed-off-by: jolheiser <john.olheiser@gmail.com>

check-and-test / check-and-test (pull_request) Successful in 1m36s

Details

a3e2879d4c

jolheiser force-pushed token-scope from a3e2879d4c to bbaf379554

2023-05-07 01:39:48 +00:00

Compare

NullOranje referenced this pull request

2023-05-22 15:13:59 +00:00

tea login add creates token without scopes #542

6543 commented

2023-06-06 13:28:33 +00:00

we should store the scope of the token in the login struct, so if we exec sub-commands we can check if we have permission before we even call the ui

or should we lookup the token scope via api on each exec?
or just let it fail on insuficient permisions?

we should store the scope of the token in the login struct, so if we exec sub-commands we can check if we have permission before we even call the ui or should we lookup the token scope via api on each exec? or just let it fail on insuficient permisions?

jolheiser commented

2023-07-15 03:05:18 +00:00

we should store the scope of the token in the login struct, so if we exec sub-commands we can check if we have permission before we even call the ui

or should we lookup the token scope via api on each exec?

I think we'd still need to look it up, as a user could use a token that was already created and thus we'd have no idea what perms existed. Alternatively at that point we could cache it somewhere so it's a one-time exec.

or just let it fail on insuficient permisions?

This sounds like a bad UX, I think we should avoid it if we can. At least if we can fail early it won't cost a network trip.

> we should store the scope of the token in the login struct, so if we exec sub-commands we can check if we have permission before we even call the ui > > or should we lookup the token scope via api on each exec? I think we'd still need to look it up, as a user could use a token that was already created and thus we'd have no idea what perms existed. Alternatively at that point we could cache it somewhere so it's a one-time exec. > or just let it fail on insuficient permisions? This sounds like a bad UX, I think we should avoid it if we can. At least if we can fail early it won't cost a network trip.

jolheiser commented

2023-09-03 04:17:23 +00:00

@6543 Any further thoughts on this, or is this good at least as a stopgap for now?

jolheiser force-pushed token-scope from bbaf379554 to 025cebeb38

2023-09-18 15:58:49 +00:00

Compare

jolheiser added 1 commit 2023-09-18 16:01:46 +00:00

chore: make docs

Signed-off-by: jolheiser <john.olheiser@gmail.com>

check-and-test / check-and-test (pull_request) Successful in 1m17s

Details

ea9ca70efc

jolheiser added 1 commit 2023-11-14 02:04:45 +00:00

Merge branch 'main' into token-scope

check-and-test / check-and-test (pull_request) Successful in 1m17s

Details

cca7027767

6543 approved these changes 2024-01-27 21:12:44 +00:00

6543 added 1 commit 2024-01-27 21:12:52 +00:00

Merge branch 'main' into token-scope

check-and-test / check-and-test (pull_request) Successful in 1m17s

Details

92e115a28b

6543 requested review from Maintainers 2024-01-27 21:13:21 +00:00

jolheiser merged commit c8c8e9758b into main

2024-02-14 16:49:29 +00:00

jolheiser referenced this issue from a commit

2024-02-14 16:49:30 +00:00

Add OTP and scopes to login (#546)

jolheiser deleted branch token-scope

2024-02-14 16:49:31 +00:00

Sign in to join this conversation.

No reviewers

gitea/Maintainers

No Milestone

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: gitea/tea#546