Authenticate against /login

[doug.patterson@…]

This patch authenticates against /login and stores the resulting session cookie, i.e. normal Trac authentication. cookielib requires Python 2.4

[doug.patterson@…]

Patch bitten-slave to authenticate against /login

[doug.patterson]

Maybe the GET to /login should be conditional (e.g. if username and password:) to prevent problems on a Trac where login is not required. I don't have this setup to test against, so will leave this decision.

[thomas_mueller_ffb]

suggestion: add command line parameter to pass login url like: --logon-url=/login

[mike@…]

Any reason this can't be merged? It's really unintuitive that bitten, by default, can't authenticate against Trac, despite having a username and password.

[mike@…]

Replace /build with /login

[anonymous]

Added auth.2.patch which seems to work against the latest version.

[mike@…]

Updated patch for bitten-slave to authenticate against /login

[mike@…]

Whoops, auth.2.patch was an old version...

auth.3.patch works.

[osimons]

Answer to /login/builds as well.

[osimons]

I've made attachment:t208-authenticate-r641.diff​ as an alternative, and one that follows how some other Trac plugins enforce authentication. ​http://trac-hacks.org/wiki/XmlRpcPlugin is an example of this.

[osimons]

#354 closed as duplicate.

[osimons]

First attempt was a bit premature and just worked for polling. The second improved patch (attachment:t208-authenticate2-r641.diff​) also returns adjusted paths to build id's for use by slaves, and a full build cycle using -u and -p options now works for me (tested using digest auth).

Anyone want to test the patch?

[osimons]

Also returnes correct urls for pointing to build id's…

[osimons]

Could anyone please help test this patch and/or provide feedback? As it changes the primary URL for the build service when using auth, I'd like to hear what people think before committing.

[osimons]

Authentication patch updated to apply cleanly on top of r647.

[osimons]

With Trac 0.11 still supporting Python 2.3, I'd hesitate to use cookielib. Also, due to the digest timeout problem in #330, a new opener is now made for every request anyway so cookies won't be persisted anyway.

[ebray]

The latest patch is very similar to something I came up with when I was struggling with this issue a few months ago (in fact, I had probably seen this ticket and worked off of it but I don't remember).

In most cases it worked, but for some large builds we started running into strange problems. After much debugging I discovered this issue in httplib: ​http://bugs.python.org/issue5542

Long story somewhat shorter, when the Bitten slave would send a POST request without auth headers, the web server would immediately send a 401 response and close the connection as soon as it finished receiving the headers. But httplib is overeager, so before it even realizes "aha, a 401 response" it keeps trying to send the request body and fails with a 'broken pipe' error.

In many cases this didn't happen, because the request body was short enough that it would finish sending before the server closed the connection. But in larger POSTS (on the order of 32kb in this case) this would happen.

So my solution, anyways, was for the Bitten slave to send an empty GET to /login/builds before doing anything else, and have /login/builds respond to the request by calling trac.web.auth.LoginModule._do_login() and then send an empty response (along with the trac_auth cookie). Bitten slave stores the cookie in a CookieJar and then make all remaining requests to /builds.

I will post an updated patch that incorporates the relevant changes.

[ebray]

This patch implements a slightly different authentication solution that addresses the issues brought up in comment:11:ticket:208. I wouldn't necessarily recommend that this be used as is, but it is what "works for me" so to speak.

[cmlenz]

Replying to ebray:

So my solution, anyways, was for the Bitten slave to send an empty GET to /login/builds before doing anything else, and have /login/builds respond to the request by calling trac.web.auth.LoginModule._do_login() and then send an empty response (along with the trac_auth cookie). Bitten slave stores the cookie in a CookieJar and then make all remaining requests to /builds.

Sounds like a good idea, except that I'd suggest using a HEAD request here.

[ebray]

Replying to cmlenz:

Sounds like a good idea, except that I'd suggest using a HEAD request here.

You're right, that would make more sense.

[osimons]

Updated ebray's patch.

[osimons]

I've updated the patch to use HEAD and also fixed a wrong import for LoginModule.

I don't like the look of that Python bug either. However, I still also have some concerns about this way of doing it:

• Slave requires Python 2.4 (up from 2.3)
• Each POST on my slave is preceeded by a HEAD to login. Does the cookie not get stored and reused correctly? Shouldn't once be enough?
• What if an alternative login method is used for Trac? Does this work for Account Manager for instance as-is? It disables the Trac login module, so having Trac LoginModule provide cookies may not be what is accepted by the alternative implementation?

[osimons]

BTW, ebray: What frontend/auth mechanism where you using when experiencing the problems you described? A regular Apache digest/basic auth, or? I can't find any issue in Trac-related projects related to 'Broken Pipe' behaviour with regards to auth (just fcgi), so that suggests Apache and does not behave in a way that is problematic for httplib2?

[ebray]

Replying to osimons:

• Each POST on my slave is preceeded by a HEAD to login. Does the cookie not get stored and reused correctly? Shouldn't once be enough?

That's odd...I admit that the patch I submitted is not exactly the same was what I have in production. I updated it to work with the latest in Bitten's trunk, whereas what I have in production is a slightly older version of Bitten. I don't have this issue--it should store the cookie and it should only do the head request once.

• What if an alternative login method is used for Trac? Does this work for Account Manager for instance as-is? It disables the Trac login module, so having Trac LoginModule provide cookies may not be what is accepted by the alternative implementation?

I do use Account Manager's form-based login. This assumes that the HttpAuthPlugin is in use and configured for /login/builds. Should have mentioned that in the first place.

[ebray]

Replying to osimons:

BTW, ebray: What frontend/auth mechanism where you using when experiencing the problems you described? A regular Apache digest/basic auth, or? I can't find any issue in Trac-related projects related to 'Broken Pipe' behaviour with regards to auth (just fcgi), so that suggests Apache and does not behave in a way that is problematic for httplib2?

Using mod_python and as I said in my last comment, the Bitten slave is authenticating with Trac through the HttpAuthPlugin.

[osimons]

Replying to ebray:

Replying to osimons:

• Each POST on my slave is preceeded by a HEAD to login. Does the cookie not get stored and reused correctly? Shouldn't once be enough?

That's odd...

Chaning one line seems to do the trick - check if cookies have been received already:

if self.username and not self.cookiejar._cookies:

[osimons]

Full updated change for the relevant part:

bitten/slave.py

@@ -179 +184 @@
             url = urls.pop(0)
             try:
                 try:
+                    if self.username and not self.cookiejar._cookies:
+                        log.debug('Performing authentication')
+                        self.request('HEAD', url[:-7] + '/login/builds')
+                    elif self.cookiejar._cookies:
+                        log.debug('Reusing authentication cookie.')
+                    else:
+                        log.debug('Authentication not provided. Attempting to '
+                                  'execute build anonymously.')
                     job_done = self._create_build(url)
                     if job_done:
                         continue

One major question remains - is this worth making Python 2.4 a requirement? Hopefully cmlenz and others can weigh in on that question - I'm too fresh and don't have a real sense of the history and usage of Bitten. However, I don't think there are many setups now without at least 2.4 being available so personally I'm fine with moving on from 2.3.

[ebray]

Replying to osimons:

Full updated change for the relevant part: ...

Problem with that, is that if a user has passed the slave URLs to multiple Tracs that have separate authentication, that check for self.cookiejar._cookies will be a problem. Instead it needs to iterate through the cookiejar for a trac_auth cookie associated with the URL.

One major question remains - is this worth making Python 2.4 a requirement? Hopefully cmlenz and others can weigh in on that question - I'm too fresh and don't have a real sense of the history and usage of Bitten. However, I don't think there are many setups now without at least 2.4 being available so personally I'm fine with moving on from 2.3.

Given that Trac now requires 2.4, and that Bitten trunk is meant for Trac 0.11, I don't imagine it'd be a problem.

[osimons]

You're right, ebray. It needs to handle multiple urls of course. I'll fix.

Trac 0.11 requires Python 2.3 - it is Trac trunk (0.12) that will require 2.4.

[ludovic <ludovic.mercier@…>]

Hi,

i have Trac 0.11.4 and last Bitten trunk version. And bitten work with anonymous user. But bitten does'nt work with authenticate user. I have trying : "ebray patch" ​http://bitten.edgewall.org/attachment/ticket/208/t208-ebray-auth_with_cookies_r657.diff and this not work. I have trying ​http://bitten.edgewall.org/attachment/ticket/208/t208-authenticate-r647.diff and it's not work also. I use the plugin Trac Account Manager?-0.2.1dev_r5837-py2.4.egg, python2.4 and the trac.ini conf :

[account-manager]
account_changes_notify_addresses =
force_passwd_change = False
generated_password_length = 8
hash_method = HtDigestHashMethod
notify_actions = []
password_store = SessionStore

I use mod_python and sessionStore option for stored password information in the trac database. what is the good way (what is the good patch) to use bitten with an authentified user ??

In two case i have slave logs :

[WARNING ] Server returned error 403: Forbidden
[ERROR   ] HTTP Error 403: Forbidden

[ebray]

Replying to osimons:

You're right, ebray. It needs to handle multiple urls of course. I'll fix.

Trac 0.11 requires Python 2.3 - it is Trac trunk (0.12) that will require 2.4.

Oops, you're right. Since I moved to Python 2.5 I've barely thought about 2.4, not to mention 2.3.

We don't necessarily need to use cookielib. Could use a cookie handling implementation like Trac's. It was just the quickest and easiest implementation for me.

[ludovic <ludovic.mercier@…>]

patch for http-form login

[ludovic <ludovic.mercier@…>]

Hi,

i have uploaded a patch, that work with : python2.4 Trac 0.11.4 Trac Account Manager? 0.2.1dev-r5837 Bitten 0.6dev-r657 this patch use cookie and a first POST request to get TOKEN_FORM value from Trac Account Maanger?. After Bitten is logged via an HTML form instead of using HTTP authentication. This patch only modify the slave.py file.

[ludovic <ludovic.mercier@…>]

Hi,

new patch : t208-authenticate-cookie-form.r657.2.patch with an option --form-auth for enabling login form authentication.

[jhampton]

Super Magic Auth Support

[jhampton]

OK, I took both ludovic's and ebray's/osimons' patches and combined them. I fixed an issue when using tracd+account manager+httpauthplugin. I also fixed it such that it will look for a cookie matching the url path that is given.

So far it's working well for me. It still depends on cookielib, so it has the 2.4 dependence. Personally, I'm all for dropping 2.3 support. I sent a message to the mailing list to see what others think.

So, the patch does form based login via /login and HTTP auth based login via /login/builds. One thing that might be added is an override for those login paths. I don't think /login will ever change for form based. However, if one isn't using form based auth, then they probably have HTTP Auth configured on /login. In this case, setting up HTTP Auth on /login/builds is an extra step.

[osimons]

Updated the 'magic auth' patch - fix some errors and reworked some parts of it. Untested with form auth...

[osimons]

I've updated the 'magic' patch to fix some errors and simplify the cookie handling to just keep track of what urls are already authenticated. Also, all the changes are now contained to slave.py file.

Please test - I don't have account-manager, so that part is completely untested by me...

[osimons]

Last patch committed as [722].