Opened 15 years ago
Closed 14 years ago
#5848 closed defect (fixed)
1.0.6 returns different HTTP response code when privileges are insufficient
| Reported by: | Steffen Pingel | Owned by: | osimons |
|---|---|---|---|
| Priority: | normal | Component: | XmlRpcPlugin |
| Severity: | normal | Keywords: | |
| Cc: | Trac Release: | 0.11 |
Description (last modified by )
I noticed that some of the Mylyn tests failed after I updated the XML-RPC plugin from version 1.0.2 to 1.0.6. Some tests perform operations without being authenticated and expect an HTTP 403 "Forbidden" response. Instead a 200 response is returned with an error message.
I am also confused by the faultCode which is set to "1" which was previously only used if a method did not exist (and Mylyn relies on that for proper error handling).
Caputured output for version 1.0.6:
POST /trac011/xmlrpc HTTP/1.1 Content-Type: text/xml User-Agent: Mylyn HttpClient/3.1 Java/1.5.0_20 (Sun) Linux/2.6.31-10-generic-pae (i386) Host: mylyn.eclipse.org Content-Length: 117 <?xml version="1.0" encoding="UTF-8"?><methodCall><methodName>system.getAPIVersion</methodName><params/></methodCall>HTTP/1.1 200 Ok Date: Sun, 20 Sep 2009 19:29:19 GMT Server: Apache/2.2.0 (Linux/SUSE) Content-Length: 312 Content-Type: text/xml <?xml version='1.0'?> <methodResponse> <fault> <value><struct> <member> <name>faultCode</name> <value><int>1</int></value> </member> <member> <name>faultString</name> <value><string>XML_RPC privileges are required to perform this operation</string></value> </member> </struct></value> </fault> </methodResponse>
Captured output for 1.0.2:
POST /trac010/xmlrpc HTTP/1.1 Content-Type: text/xml User-Agent: Mylyn HttpClient/3.1 Java/1.5.0_20 (Sun) Linux/2.6.31-10-generic-pae (i386) Host: mylyn.eclipse.org Content-Length: 117 <?xml version="1.0" encoding="UTF-8"?><methodCall><methodName>system.getAPIVersion</methodName><params/></methodCall>HTTP/1.1 403 Forbidden Date: Sun, 20 Sep 2009 19:41:16 GMT Server: Apache/2.2.0 (Linux/SUSE) Cache-control: must-revalidate Expires: Fri, 01 Jan 1999 00:00:00 GMT Set-Cookie: trac_form_token=3697f2514a8b2dfafcb60c66; Path=/trac010; Set-Cookie: trac_session=f3401d36e4c23809577bfb82; expires=Sat, 19-Dec-2009 19:41:16 GMT; Path=/trac010; Content-Length: 2897 Content-Type: text/html;charset=utf-8 <!DOCTYPE html ...
Attachments (0)
Change History (5)
comment:1 Changed 15 years ago by
comment:2 Changed 15 years ago by
| Description: | modified (diff) |
|---|
Not quite sure how to handle this - part of the change was made so that useful error messages could actually be conveyed from methods. It may be basic permission, it may be missing information from a ticket update or a status change. That is why passing the full Trac error HTML page with just a status code is not a good solution - and particularly not as there are two different protocols (xml and json). Errors need better and differentiated handling.
What if we for XML passed the regular status code as fault code? So that a permission error would get a fault code of 403, and any non-specific error was 500?
I suppose I should re-read the spec again here...
comment:4 Changed 14 years ago by
| Description: | modified (diff) |
|---|
What if we for XML passed the regular status code as fault code? So that a permission error would get a fault code of 403, and any non-specific error was 500?
Yes, that might work. It would certainly make the error handling simpler if it was possible to differentiate errors based on the code as much as possible. Right now I am parsing the message to figure out what is going on.
comment:5 Changed 14 years ago by
| Description: | modified (diff) |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
This should now be fixed as part of [7916] for latest version in trunk (1.1.0).
Note that opening http://mylyn.eclipse.org/trac011/xmlrpc in a web browser returns the proper 403 response.