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

Comments

Projects
None yet
2 participants
@oalders
Member

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

This comment has been minimized.

Show comment
Hide comment
@colinnewell

colinnewell Apr 27, 2017

Contributor

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\""
  }
}
Contributor

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

Do not forward the Authentication header after 3xx
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 #131.

Actual debugging and fix by Sergey Belikov.

book added a commit to book/libwww-perl that referenced this issue Mar 2, 2018

Do not forward the Authentication header after 3xx
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 #131.

@book book referenced a pull request that will close this issue Mar 2, 2018

Open

Do not forward the Authentication header after 3xx #284

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment