Skip to content
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

LWP should recalculate digest auth after redirects [rt.cpan.org #24711] #131

Open
oalders opened this issue Mar 30, 2017 · 1 comment · May be fixed by #284
Open

LWP should recalculate digest auth after redirects [rt.cpan.org #24711] #131

oalders opened this issue Mar 30, 2017 · 1 comment · May be fixed by #284

Comments

@oalders
Copy link
Member

@oalders oalders commented Mar 30, 2017

Migrated from rt.cpan.org#24711 (status was 'new')

Requestors:

From oliviert@cpan.org on 2007-02-01 03:04:13:

Scenario

1)  client requests / on secure.example.org port 80
2) server replies HTTP/1.1 301 Moved Permanently Location:
http://secure.example/Team
3) client request /Team
4) server replies with 401 challenge (digest auth)
5) client requests /Team again, with auth
6) server replies HTTP/1.1 301 Moved Permanently Location:
http://secure.example/Team/
7) client requests /Team/, with same auth headers

However, the digest authentication response is calculated based (among
other things) on the requested URI, so the response for /Team and /Team/
are different.

Running
% GET -uUsSx http://secure.example.org/Team
returns
[...]
GET http://secure.example.org/Team/
Authorization: Digest username="myusername", realm="REALMNAME",
qop="auth", algorithm="MD5", uri="/Team", nonce=[...]

and so...

8) server say "thanks, but no thanks". 400 Bad Request
logs say:
[Mon Jan 22 01:16:12 2007] [error] [client 133.27.228.213] Digest: uri
mismatch - </Team> does not match request-uri </Team/>


LWP (and, I suppose, LWP::Authen::Digest) should calculate the digest
based on the new URI after a redirect.


---- System info ----

LWP 5.805
perl v5.8.6 built for darwin-thread-multi-2level
Darwin 8.8.0 Darwin Kernel Version 8.8.0: Fri Sep  8 17:18:57 PDT 2006;
root:xnu-792.12.6.obj~1/RELEASE_PPC Power Macintosh powerpc
@colinnewell
Copy link
Contributor

@colinnewell colinnewell commented Apr 27, 2017

I setup a server to reproduce this problem and discovered it doesn't seem to be a problem anymore. LWP::UserAgent appears to do the right thing. All the files for testing are in this gist, https://gist.github.com/colinnewell/c067b843ba10ca7a8b7ee6db0f1e794e.

Using jq to summarize the har file with the resultant network traffic you can see a) the auth is recalculated and b) we get a 200 as we should.

jq .log.entries[]|{url:.request.url, status:.response.status, headers:.request.headers[] | select(.name | . and contains("authorization"))} digest.har
{
  "url": "http://172.17.0.2/private",
  "status": 301,
  "headers": {
    "name": "authorization",
    "value": "Digest username=\"colin\", realm=\"private area\", qop=auth, algorithm=\"MD5\", uri=\"/private\", nonce=\"FzcjdytOBQA=35956263a3522d3cd55a56f0c2668fc2947b5ea1\", nc=00000001, cnonce=\"59024ed0\", response=\"8354b3973ad1f3d421d828d34f7333dd\""
  }
}
{
  "url": "http://172.17.0.2/private/",
  "status": 200,
  "headers": {
    "name": "authorization",
    "value": "Digest username=\"colin\", realm=\"private area\", qop=auth, algorithm=\"MD5\", uri=\"/private/\", nonce=\"FzcjdytOBQA=35956263a3522d3cd55a56f0c2668fc2947b5ea1\", nc=00000002, cnonce=\"59024ed0\", response=\"6a4745e65d58e57839ca823d9f038c4e\""
  }
}
book added a commit to book/libwww-perl that referenced this issue Mar 2, 2018
The `Authorization` header is sent when retrying a query after a `401` response.
Usually, a cookie is set, which holds the "authorized" status of the agent.

If the query including the `Authorization` header is accepted, and the server sends a `3xx` response back,
the original query is cloned, and some headers are removed. The `Authorization` header must also be
removed, otherwise the query might fail again (with a `403`), for example when the `Location` in the `3xx`
response is a redirect to a different domain, in a different authorization realm.

This should fix libwww-perl#131.

Actual debugging and fix by Sergey Belikov.
book added a commit to book/libwww-perl that referenced this issue Mar 2, 2018
The `Authorization` header is sent when retrying a query after a `401`
response. Usually, a cookie is set, which holds the "authorized" status
of the agent.

If the query including the `Authentication` header is accepted
(i.e. authentication is valid), and the server sends a `3xx` response
back, the original query is cloned, and some headers are removed.

The `Authentication` header must also be removed, otherwise the query
might fail again (with a `403`), for example when the `Location` in
the `3xx` response is a redirect to a different domain, in a different
authorization realm.

Actual debugging and fix by Sergey Belikov.

This should fix libwww-perl#131.
@book book linked a pull request that will close this issue Mar 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

2 participants
You can’t perform that action at this time.