search

williamh / pybugz

Python interface to Bugzilla.
http://www.liquidx.net/pybugz/
GNU General Public License v2.0
80 stars 60 forks source link

Add support for Bugzilla v4.4.3 and newer (login tokens) #78

Closed leif81 closed 10 years ago

leif81 commented 10 years ago

As of Bugzilla 4.4.3+ login cookies are no longer supported. The new way to do authentication is tokens. This means that pybugz fails to login to Bugzilla 4.4.3 or newer.

"The User.login WebService method now also returns a token argument containing a login token which you can use in subsequent calls to authenticate. For security reasons, this method no longer generates login cookies. (Bug 893195)"

http://www.bugzilla.org/releases/4.4.3/release-notes.html#v44_point http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService.html#LOGGING_IN

leif81 commented 10 years ago

FWIW, here's a couple different implementations for Bugzilla tokens

Here's how j2bugzilla did it:

https://github.com/leif81/j2bugzilla/commit/f225af190c95fb13dfedb2357730b4df29a3a0e9

And here's how python-bugzilla did it:

https://git.fedorahosted.org/cgit/python-bugzilla.git/commit/?id=e1af7160b3162d423fdfeb04e230067a75e9b584

williamh commented 10 years ago

The token support is mostly in place. The only thing I need to do is create a different file name to save each token in instead of overwriting .bugz_token every time. This is in connection.py and cli.py on the master branch.

williamh commented 10 years ago

It looks like the best way to support multiple tokens is going to be to use a configparser, similar to what python-bugzilla does. Let me be clear. The inspiration came from a brief look at python-bugzilla, but I will not be using their code.

Currently, ~/.bugz_token is where the only token pybugz stores. This file contains only one token, so the question is, should I try to migrate this file to the new format or just tell everyone to create new tokens with the new release?

leif81 commented 10 years ago

should I try to migrate this file to the new format or just tell everyone to create new tokens with the new release?

I like the idea of auto migrating the token file. The pybugz users probably don't care that Bugzilla changed it's auth scheme, so implementing it transparently if possible sounds good to me.

williamh commented 10 years ago

It isn't the auth scheme that I'm thinking about, it is how we store tokens that is changing. Currently, we create one file, with one token. That is going to change to a file that stores tokens for multiple connections. The file with the single token does not identify which connection the token is for. I can take the old token and write it to the file with the new format, but I'm thinking I'll have to have the user edit the generated file and fix the connection name. Thoughts?

leif81 commented 10 years ago

I suppose asking the user to modify their existing token file is reasonable. Worst case they would need to remove the token file and have pybugz make a new one?

williamh commented 10 years ago

The plan is to use a different name for the new file since it will be a completely different format. The current file is ~/.bugz_token, and the new file will be ~/.bugz_tokens.

It is easy enough to read in the old token, but to automatically migrate it to the new format I need to know which connection to associate it with.

Do you have any ideas how to figure that out?

leif81 commented 10 years ago

Sorry I don't. I'm not very familiar with pybugz and the old .bugz_token file to be honest. Only very recently I tried pybugz for the first time and I hit this issue that prevented me from logging in.

leif81 commented 10 years ago

Just so we're clear though and not mixing up issues, the Bugzilla_token for which this issue is about is a new string value returned by the Bugzilla User.login web service that was introduced in v4.4.3 for security reasons. Previously this was done with login cookies.

The pybugz .bugz_token and .bugz_tokens files you are referring to are for holding runtime configuration parameters? (one of which may be this new Bugzilla token string?). Sorry for the confusion if there is any regarding the term "token".

williamh commented 10 years ago

Correct, The current file that holds the token string is ~/.bugz_token. This file only holds one token string at a time.

The new file, in a different format, will be ~/.bugz_tokens. It will hold tokens for multiple bugzillas.

The question is, how to move the single token to the new file and map it to the correct bugzilla.

Two possibilities come to mind:

  1. read the token from the old file and assign it to the user's default bugzilla.

or

  1. read the token from the old file and allow the user to pick which bugzilla to assign it to.

I am leaning toward the first choice.

What do you think?

leif81 commented 10 years ago

I like the first option too. The less (or nothing at all) that the user has to do when migrating to a newer version the better I think.