Allow bitten to use form login (as provided by the account manager plugin)

[davidf@…]

I have a patch to enable bitten to login using form submission This is required if the trac site uses the Account Manager? plugin

[davidf@…]

patch to allow form login to trac from bitten-slave

[anonymous]

Hi,

I've patched the slave but it caused the following error: (with #tracd --port 9090 /home/projects/Test/env)

# bitten-slave --form-login --user=USERNAME --password=PWD --work-dir=/tmp/work/ --interval=30 --verbose ​http://IPADDR:9090/env/builds [DEBUG ] Enabling authentication with username 'USERNAME' [DEBUG ] Requesting login form from ​http://IPADDR:9090/env/login [DEBUG ] Sending GET request to '​http://IPADDR:9090/env/login' [DEBUG ] Submitting login request using token [DEBUG ] Sending POST request to '​http://IPADDR:9090/env/login' [WARNING ] Server returned error 400: Bad request Traceback (most recent call last):

File "/usr/local/bin/bitten-slave", line 7, in ?

sys.exit(

File "/usr/local/lib/python2.4/site-packages/Bitten-0.6dev-py2.4.egg/bitten/slave.py", line 403, in main

dump_reports=options.dump_reports)

File "/usr/local/lib/python2.4/site-packages/Bitten-0.6dev-py2.4.egg/bitten/slave.py", line 123, in init

self.login_using_form(username, password)

File "/usr/local/lib/python2.4/site-packages/Bitten-0.6dev-py2.4.egg/bitten/slave.py", line 155, in login_using_form

resp = self.request('POST', login_url, body, {'Content-Type': 'application/x-www-form-urlencoded', 'Content-Length': str(len(body))})

File "/usr/local/lib/python2.4/site-packages/Bitten-0.6dev-py2.4.egg/bitten/slave.py", line 134, in request

return self.opener.open(req)

File "/usr/lib/python2.4/urllib2.py", line 364, in open

response = meth(req, response)

File "/usr/local/lib/python2.4/site-packages/Bitten-0.6dev-py2.4.egg/bitten/slave.py", line 47, in http_response

response = self.parent.error(

File "/usr/lib/python2.4/urllib2.py", line 402, in error

return self._call_chain(*args)

File "/usr/lib/python2.4/urllib2.py", line 337, in _call_chain

result = func(*args)

File "/usr/lib/python2.4/urllib2.py", line 480, in http_error_default

raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)

urllib2.HTTPError: HTTP Error 400: Bad request

Can you help me what can be the problem?
Thanks a lot.

[davidf@…]

Updated patch to handle redirect error codes better (based on r517)

[anonymous]

Replying to anonymous:

Hi,

I've patched the slave but it caused the following error: (with #tracd --port 9090 /home/projects/Test/env)

# bitten-slave --form-login --user=USERNAME --password=PWD --work-dir=/tmp/work/ --interval=30 --verbose ​http://IPADDR:9090/env/builds [DEBUG ] Enabling authentication with username 'USERNAME' [DEBUG ] Requesting login form from ​http://IPADDR:9090/env/login [DEBUG ] Sending GET request to '​http://IPADDR:9090/env/login' [DEBUG ] Submitting login request using token [DEBUG ] Sending POST request to '​http://IPADDR:9090/env/login' [WARNING ] Server returned error 400: Bad request

[snip]

Can you help me what can be the problem?
Thanks a lot.

I fixed a bunch of errors with handing redirect errors and this is working more reliably for me now - could you try the new form-login.2.patch​ above and see if that works for you?

[anonymous]

Hi,

unfortunately the result is the same as above. But we use a special version of trac with a lots of plug-ins. I'll try to debug it later but I think not before Christmas.

Btw, thanks for your help. I'll keep on my eye on this ticket if somebody will give some response.

[anonymous]

Replying to anonymous:

Hi,

unfortunately the result is the same as above. But we use a special version of trac with a lots of plug-ins. I'll try to debug it later but I think not before Christmas.

Btw, thanks for your help. I'll keep on my eye on this ticket if somebody will give some response.

OK cool - if you could induce the trac server to give a traceback it may help, and I'll try and respond fairly quickly to any discoveries...

[anonymous]

Just a small response, the trac log in debug level: 2007-12-20 13:38:12,809 Trac[api] DEBUG: Get password store: htpasswd 2007-12-20 13:38:12,809 Trac[api] DEBUG: Store: htpasswd 2007-12-20 13:38:12,809 Trac[api] DEBUG: Get sync store: pamsync 2007-12-20 13:38:12,810 Trac[api] DEBUG: Store: pamsync 2007-12-20 13:38:12,810 Trac[api] DEBUG: Get sync store: pamsync 2007-12-20 13:38:12,810 Trac[api] DEBUG: Store: pamsync 2007-12-20 13:38:12,811 Trac[api] DEBUG: Get password store: htpasswd 2007-12-20 13:38:12,811 Trac[api] DEBUG: Store: htpasswd 2007-12-20 13:38:12,871 Trac[main] WARNING: 400 Bad Request (Missing or invalid form token. Do you have cookies enabled?)

[anonymous]

Sorry for the missing enters after each line.

One more thing might be useful: I use 10.3 trac version and I can't change it unfortunately.

[davidf@…]

Aha - it's not getting the form token. I should have picked that up from the original log message (Submitting login request using token ) - it indicated that the token is blank. We should check and make that a warning/error trac 10.3 probably just has a different layout so my hacky code to get the token broke. If you attach the HTML returned (as a file attachment) when viewing ​http://ipaddr:9090/env/login I can try take a look at it...

PS to include stuff with newlines in comments etc just add code markers above and below the text...

[anonymous]

Hi,

I've just had time to continue this investigation and finally I had to realize that the power of space is huge...

The problem is that in our html page somebody entered one more space character between the type="hidden" and the name="FORM_TOKEN"

This is why the text search not worked... By the way thanks for your patch. It works as it's required for now.

[davidf@…]

Ah great - cmlenz any chance of this being applied then?

[TimN]

We have the same space-problem here. Why not use a regex instead? This should solve this problem in just one line and regardless of the number of spaces.

[cmlenz]

Can't you protect the /builds URL via HTTP authentication? I haven't tried this, but the form-based login on the /login URL should continue to work for the “human” users.

[TimN]

I'd like to have one login system to care about and not an exception in the HTTP config for the builds. Since I assume that more people prefer the form-based login this should be supported properly. There is already a patch, it just needs to be tweaked a bit to be robust.

[davidf@…]

I've now switched to using HTTP authentication for the builds. I still think it would be nicer to support form-based authentication as well, but I think this would be better done if that was native to trac, and didn't require screen-scraping the form token.

What flipped me over was trying to debug POSTs just hanging there on the client side...

[anonymous]

HTTP authentication works (check #247 to set it up with Apache 2+)

Regards, Patrick.

[osimons]

On #208 I've added a patch that switches the url to /login/builds in case username and password is provided. That way authentication will always be challenged. Used in combination with ​http://trac-hacks.org/wiki/HttpAuthPlugin that should allow certain paths to challenge for regular authentication using the account manager user/password database.

I don't use the account manager plugin myself, so cannot test this. Could someone try the latest patch on #208 in combination with the mentioned plugin, and see if this provides a usable experience?

[jhampton]

I updated osimons' patch on #208 and it now handles both the HTTP Auth on /login/builds as well as form based login via /login (using the --form-auth option on the slave).

I'd love testing of the patch for form based login. Additionally, I think that we should merge this ticket with #208.

[osimons]

This is now done as part of #208 and committed in [722].

[osimons]

...and closing.