Authentication Failure returns invalid HTTP Response (content-length incorrect)

XmlRpcPlugin is not involved in authentication at all, so moving it to that other plugin.

Hint: Use {{{ .... }}} blocks when pasting pre-formatted text.

I am also seeing this behavior, however I will add that if you keep retrying, it does eventually spit out the right response, but only every very rarely.

I am using a similar setup, i am running trac 0.13dev-r10668 (this was not intentional, I installed from trunk and didn't realise I would end up with 0.13 oops), tracxmlrpc 1.1.2-r9970, trachttpauth 1.1, tracaccountmanager 0.3dev-r9929.

Any suggestions would be greatly appreciated

OK I think I just fixed it for myself :)

I changed this section (starting line 57) from

        if req.method != 'HEAD':
            req.write(auth_req_msg)

to (added a line)

        if req.method != 'HEAD':
            req.write(auth_req_msg)
	    req.end_response()

This seems to have fixed my issue, hope it helps someone else.

Ignore my last post, didn't get any time to check it. end_response isn't even a method ;)

Python is new to me ;)

So I have checked through the API, and the wierd thing is what coderanger has put in seems to be correct, the process_request method sends the valid response then raises the RequestDone? exception which is a notification that the request has been sent and to stop processing.

However Trac seems to be still processing after the exception is raised.

However this is just a "side effect" ultimately if you want to authenticate with XML-RPC.NET you will need to manually add the header yourself, you will even note in your issue that the Request header doesn't include the Authorization header, hence HTTPAuth is trying to tell you that it is invalid.

So do this when you setup your proxy

Trac.Headers("Authorization") = "Basic " & Convert.ToBase64String(System.Text.Encoding.UTF8.GetBytes(Username & ":" & Password))

Where "Trac" is the "proxy" you have created using the XmlRpcProxyGen?.Create method and "Username" and "Password" are variables holding the credentials.

This should work for you, but this ticket is still valid on the grounds that if you have a "invalid" login you will receive a malformed HTTP Response. (ie. content-length not being correct)

Note that you'll get a similar issue when you try the xmlrpclib client example snippet:

>>> from xmlrpclib import ServerProxy
>>> p = ServerProxy("http://user:pass@localhost:port/trac/login/rpc")
>>> p.system.getAPIVersion()
Traceback (most recent call last):
  ...
xmlrpclib.ProtocolError: <ProtocolError for user:pass@localhost:port/trac/login/rpc: 401 Unauthorized>

And the Trac log shows:

127.0.0.1 - - [26/May/2012 10:37:35] "POST /cblaptop-trac/login/rpc HTTP/1.1" 401 -
127.0.0.1 - - [26/May/2012 10:37:35] code 400, message Bad HTTP/0.9 request type ('<?xml')
127.0.0.1 - - [26/May/2012 10:37:35] "<?xml version='1.0'?>" 400 -

This will happen if you use Digest authentication on the Trac side (with tracd), as xmlrpclib only supports Basic authentication.

Likewise, when using curl for testing, don't forget to add the --digest flag.

I haven't investigated yet if this is really a problem in Trac (more specifically tracd and the way it handles digest auth with clients which don't support it). To find out, it would be interesting to know how this behaves with the same clients but another web front-end like Apache and mod_auth_digest.

[PATCH] Adding Connection: close when sending errors for Trac 0.12-stable

And the Trac log shows: ... 127.0.0.1 - - [26/May/2012 10:37:35] code 400, message Bad HTTP/0.9 request type ('<?xml') ...

I've gotten the same problem during development of fulmo.

I think that is the Trac issue. That happens if the client send POST request to tracd with authentication using HTTP/1.1. Because tracd does not read the body of POST request from the client, or close the connection, before it sends 401 Authentication Required. Therefore, it wrongly reads the body as the next request.

Here is the proposal patch, t8558-close-conn-trac-0.12-r11474.diff, for Trac 0.12-stable. It works well for me.

Jun: I don't think this plugin is being maintainer, so if you'd like commit access to push your change, just let me know.

Sorry, the patch in comment:6 is for similar issue of Trac core. I'll create a new ticket on t.e.o later.

Also, I reproduced the original issue on Trac 0.12-stable, acct_mgr 0.3.2 and httpauthplugin latest. I created the following patch to solve and confirmed the fix.

Ryan: I would like to push it. Could you please grant the commit right?

Index: httpauth/filter.py
===================================================================
--- httpauth/filter.py  (revision 12390)
+++ httpauth/filter.py  (working copy)
@@ -52,6 +52,8 @@
         req.send_header('Cache-control', 'no-cache')
         req.send_header('Expires', 'Fri, 01 Jan 1999 00:00:00 GMT')
         req.send_header('Content-Length', str(len(auth_req_msg)))
+        if req.get_header('Content-Length'):
+            req.send_header('Connection', 'close')
         req.end_headers()

         if req.method != 'HEAD':

Replying to jun66j5:

... Ryan: I would like to push it. Could you please grant the commit right?

You should be all set now.

(In [12394]) Fixed broken communication between client on tracd using HTTP/1.1 if sending 401 Unauthorized. Sends Connection: close header in this case.

Closes #8558.

Replying to rjollos:

Ryan: I would like to push it. Could you please grant the commit right?

You should be all set now.

Thanks, Ryan! I just applied the patch.