Issue Details (XML | Word | Printable)

Key: GALAXY-161
Type: Bug Bug
Status: Open Open
Priority: Minor Minor
Assignee: Dan Diephouse
Reporter: Todd Wells
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Galaxy

Attempting feed access without credentials returns HTTP 302 instead of HTTP 401

Created: 25/Mar/08 03:12 PM   Updated: 13/Aug/08 10:14 PM
Component/s: Core
Affects Version/s: 1.0-beta-2
Fix Version/s: 1.x Backlog

Time Tracking:
Not Specified

Issue Links:
Related
 

Labels:
User impact: Medium


 Description  « Hide
If you hit a feed URL, e.g. http://localhost:9090/api/registry/Default%20Workspace/myArtifact;history, and do not provide credentials, an HTTP 302 (meaning "requested resource resides temporarily under a different URI") is returned and it redirects you to login.jsp. The correct behavior when hitting a feed URL without credentials should be to return a 404 unauthorized, prompting clients to authenticate. A re-direct would be fine for a non-feed URL (e.g. a web console URL).

I discovered this when using apache HttpClient to authenticate against the service – by default HttpClient does not preemptively pass auth credentials (it will pass them if it gets a 404), so the client kept getting redirected to login.jsp. I finally resolved the issue by forcing HttpClient to pre-emptively authenticate.



 All   Comments   Work Log   Change History   Transitions   FishEye      Sort Order: Ascending order - Click to sort in descending order
Todd Wells added a comment - 25/Mar/08 03:13 PM
Oops, meant "if it gets a 401" in the second paragraph.

Dan Diephouse added a comment - 25/Mar/08 10:13 PM
I'll see if I can fix this for the next release. Its Acegi weirdness that I need to resolve.

Andrew Perepelytsya added a comment - 14/May/08 10:13 AM
Implementation note: making it return 401 instead of 302 would be semantically correct, but could break the re-login prompt (see GALAXY-245). Different servers may present 401 error differently, not sure if we can get a cross-server behavior consistently. Then, there's a limitation in current 1.4.x GWT, whereas onFailure() handler does not carry any context info (response). This is improved in GWT 1.5 (response code is available), see http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/bfe37326ce752550

So, I'd say don't touch this issue until we upgrade GWT.