Open ianw opened 1 year ago
ps: Get api/v1/orgs
will not response 401 now, as backport #24259 has been merged 4 days ago. (after this issue created)
You are right, I found document here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401
This status code is sent with an HTTP WWW-Authenticate response header that contains information on how the client can request for the resource again after prompting the user for authentication credentials.
It seems that 401 response should have WWW-Authenticate
header.
But if search http.StatusUnauthorized
, you will find that almost all of them have no WWW-Authenticate
header.
WWW-Authenticate
is for basic auth
but not all 401 requires a basic auth
?
WWW-Authenticate
is forbasic auth
but not all 401 requires abasic auth
?
https://www.rfc-editor.org/rfc/rfc7235#section-3.1 says
The 401 (Unauthorized) status code indicates that the request has not
been applied because it lacks valid authentication credentials for
the target resource. The server generating a 401 response MUST send
a WWW-Authenticate header field (Section 4.1) containing at least one
challenge applicable to the target resource.
If the request included authentication credentials, then the 401
response indicates that authorization has been refused for those
credentials.
As I read that, a blank request would return a WWW-Authenticate: Basic realm="gitea", Bearer
as basic auth and bearer auth are supported. From what I read, it seems like if the authentication token is provided, but incorrect, you should still send back 401
, but with a message indicating the provided auth was not accepted.
Really the first part is I guess the most important, because as noted the Ansible uri
helper for example doesn't, by default do "preauth" where it sends the basic auth token with the initial request -- it seems to be waiting for the 401 response to tell it what to do.
Is this still considered? Because I stumbled upon the problem when using git with http authentication. Apparently the git binary expects the WWW-Authenticate: Basic
header before sending the Authorization
header with credentials included in the remote url.
Update: Sorry, I had a configuration error with some middleware, everything is working as expected.
Description
Hello,
This is related to another issue https://github.com/go-gitea/gitea/issues/24159 I opened about the
api/v1/org
call becoming authenticated with 1.19.2As noted in that report, we have CI that tests our 1.18->1.19 transition. As part of this we use an Ansible URI call to get the org list
As noted in the other report, we've had to add user/password authentication to this for 1.19. However, it was surprising to find this didn't work when we simply added
user:
andpassword:
fields to the call to do Basic auth. We found that setting the ansibleforce_basic_auth
flag did make this work -- what this does is send the Basic authentication header in the first request, instead of responding to a 401. This uses Python urllib under the hood, so it seemed unlikely it would be an issue there.So pulling on that thread some more, it seems that 401 responses from gitea don't include a
WWW-Authenticate
header to instruct the client on how it can authenticate. You can see incurl
It's a real pain to replicate with an authenticated ssl call in the low-level
urllib
. The following program is essentially what Ansible is doing, and should make the API call, but it will fail to authenticate.I think the problem here is without
WWW-Authenticate
response, urllib doesn't know to respond to the 401 call.The same thing happens on our production 1.18.5 system; but it was the authentication discussed in with https://github.com/go-gitea/gitea/issues/24159 that made me look at this a bit further.
[1] https://docs.ansible.com/ansible/latest/collections/ansible/builtin/uri_module.html#parameter-force_basic_auth
Gitea Version
1.19.1
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?
We build from upstream and run in a container
Database
None