Gitea asks for local user password even when connected through OpenID #3521
Comments
|
@arrfab I'm using gitea in my server and am planning to switch to OpenID. Is this still happening? |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions. |
|
I think this is designed. External user have to binding to a local user. |
|
@lunny except that such user doesn't know his "local password" and so can't even change it (as he was automatically registered through OpenID - see bug description) |
|
There should be an issue already filed about managing password-less
accounts. If I'm not wrong the only way out from OpenID when asked
for a password would be to use the "reset password" and rely on email
to get a chance to use a new password (but things could have been
changed since I last looked at this).
Try to find that "password less accounts" ticket as some design is
really useful to handle that.
|
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions. |
lunny
added
type/enhancement
|
A random password could be set when an external user login and user could change it when he need. |
This is what my initial implementation of the OpenID-2.0 authentication did. Was it changed recently ? |
|
This is the issue I was talking about: #1036 |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions. |
|
Please don't close this important issue. |
lunny
added
the
issue/confirmed
When a logged in user with no repositories visits their dashboard, it will display a search box that lists their own repositories. This is served by the `repo.SearchRepos` handler, which in turn calls `commitstatus_service.FindReposLastestCommitStatuses()` with an empty repo list. That, in turn, will call `git_model.FindBranchesByRepoAndBranchName()`, with an empty map. With no map, `FindBranchesByRepoAndBranchName()` ends up querying the entire `branch` table, because no conditions were set up. Armed with a gazillion repo & commit shas, we return to `FindReposLastestCommitStatuses`, and promptly call `git_model.GetLatestCommitStatusForPairs`, which constructs a monstrous query with so many placeholders that the database tells us to go somewhere else, and flips us off. At least on instances the size of Codeberg. On smaller instances, it will eventually return, and throw away all the data, and return an empty set, having performed all this for naught. We fix this by short-circuiting `FindBranchesByRepoAndBranchName`, and returning fast if our inputs are empty. A test case is included. Fixes go-gitea#3521. Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu> (cherry picked from commit 0d029eb)
[x]):Description
When registered and connected through OpenID, a user even with admin rights has to confirm some operations with his "local" password.
Problem is that $user doesn't know his local password, as he was authenticated/validated/registered through OpenID
There is no even possibility for the user to change his "local" password, as it asks for the actual one (that $user doesn't know, as auto-registered through openid)
It seems the only solution would be for $user to ask a reset of his "local" gitea password , but that defeats completely the SSO goal
...
The text was updated successfully, but these errors were encountered: