-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docker login
reports sucessful login with incorrect password / token
#20563
Comments
FWIWI, this appears to be the relevant code: gitea/routers/api/packages/container/container.go Lines 137 to 152 in ff9b6fa
I would assume Doer is nil here, because of: gitea/routers/api/packages/api.go Lines 254 to 256 in ff9b6fa
Thus, since Doer is nil, it the first block of code uses the ghost user, and thus, succeeds. If my assumption is correct, then it should treat Doer being nil as an error and 403. Mind you, this is just my quick impression of the code, I have not verified either of the above assumptions. |
FWIW, I have a fix prepared for this, PR will be coming up shortly. |
...I spoke too soon. The ghost user is required for anonymous pulls, which also hit the token URL, so just going off of |
The Auth interface need to be refactored to have a new return argument which indicate should we continue the next auth method. |
This PR changed the Auth interface signature from `Verify(http *http.Request, w http.ResponseWriter, store DataStore, sess SessionStore) *user_model.User` to `Verify(http *http.Request, w http.ResponseWriter, store DataStore, sess SessionStore) (*user_model.User, error)`. There is a new return argument `error` which means the verification condition matched but verify process failed, we should stop the auth process. Before this PR, when return a `nil` user, we don't know the reason why it returned `nil`. If the match condition is not satisfied or it verified failure? For these two different results, we should have different handler. If the match condition is not satisfied, we should try next auth method and if there is no more auth method, it's an anonymous user. If the condition matched but verify failed, the auth process should be stop and return immediately. This will fix #20563 Co-authored-by: KN4CK3R <[email protected]> Co-authored-by: Jason Song <[email protected]>
…#22119) This PR changed the Auth interface signature from `Verify(http *http.Request, w http.ResponseWriter, store DataStore, sess SessionStore) *user_model.User` to `Verify(http *http.Request, w http.ResponseWriter, store DataStore, sess SessionStore) (*user_model.User, error)`. There is a new return argument `error` which means the verification condition matched but verify process failed, we should stop the auth process. Before this PR, when return a `nil` user, we don't know the reason why it returned `nil`. If the match condition is not satisfied or it verified failure? For these two different results, we should have different handler. If the match condition is not satisfied, we should try next auth method and if there is no more auth method, it's an anonymous user. If the condition matched but verify failed, the auth process should be stop and return immediately. This will fix go-gitea#20563 Co-authored-by: KN4CK3R <[email protected]> Co-authored-by: Jason Song <[email protected]>
…22259) backport #22119 This PR changed the Auth interface signature from `Verify(http *http.Request, w http.ResponseWriter, store DataStore, sess SessionStore) *user_model.User` to `Verify(http *http.Request, w http.ResponseWriter, store DataStore, sess SessionStore) (*user_model.User, error)`. There is a new return argument `error` which means the verification condition matched but verify process failed, we should stop the auth process. Before this PR, when return a `nil` user, we don't know the reason why it returned `nil`. If the match condition is not satisfied or it verified failure? For these two different results, we should have different handler. If the match condition is not satisfied, we should try next auth method and if there is no more auth method, it's an anonymous user. If the condition matched but verify failed, the auth process should be stop and return immediately. This will fix #20563 Co-authored-by: KN4CK3R <[email protected]> Co-authored-by: Jason Song <[email protected]>
Description
↑ this should fail as i entered gibberish for the password
↑ ACLs seem to generally work at least ;)
Gitea Version
692707f
Can you reproduce the bug on the Gitea demo site?
Yes
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
build from source
Database
SQLite
The text was updated successfully, but these errors were encountered: