On 10/06/2015 03:24 AM, Pierre-Yves Chibon wrote:
On Mon, Oct 05, 2015 at 03:31:49PM -0400, Cole Robinson wrote:
> On 10/01/2015 10:36 AM, Pierre-Yves Chibon wrote:
>> Hi all,
>>
>> I've seen a couple of reports on fedora-review and now one on pkgdb-cli
about
>> python-bugzilla raising an exception at an unexpected location.
>>
>> Here is the full report for pkgdb-cli:
>>
https://bugzilla.redhat.com/show_bug.cgi?id=1267821
>>
>> As you can see in the stacktrace:
>>>> BZCLIENT = Bugzilla(url=RH_BZ_API)
>>
>> raises:
>>
>>>> BugzillaError: Login failed: The username or password you entered is not
>>>> valid.
>>
>> This is surprising to me for a few points:
>> a) It is not passing any username/password
>> b) If the username/password are invalid, I would expect to not be authenticated
>> but not that it raises an exception.
>>
>
> Yes this is strange. Looking at the backtrace, the call the login() is guarded
> like this:
>
> if (self.user and self.password):
> log.info("user and password present - doing login()")
> self.login()
>
> But clearly no user or password value is being passed at class init, and the
> bug report has:
>
> Local variables in innermost frame:
> self: <bugzilla.rhbugzilla.RHBugzilla object at 0x7fb876392b10>
> password: None
> e: <Fault 300: 'The username or password you entered is not valid.'>
> user: None
>
> Does pkgdb use a bugzillarc file to store password values? python-bugzilla has
> support for reading info from /etc/bugzillarc and ~/.bugzillarc, but
> admittedly I always forget it exists since it's from before my time I've
never
> been sure if anyone is actually using it.
>
> Maybe the bugzillarc file is setting the user/pass to literal 'None' or
similar.
This would make sense indeed, but I just reproduced the bug again and I do not
have a ~/.bugzillarc
$ ls ~/.bug*
/home/pingou/.bugwarriorrc
/home/pingou/.bugzillacookies
/home/pingou/.bugzillatoken
You hit the same error as the original report? That's strange to me then. Can
you run the script I posted in the bug and paste the output?
>> After trying to replicate the issue in a python shell, the exception seems to be
>> gone but another is thrown in:
>> File "/usr/lib/python2.7/site-packages/bugzilla/base.py", line 1203, in
query
>> r = self._query(query)
>> ...
>> Fault: <Fault 32000: 'The cookies or token provide were not valid or have
>> expired. You may login again to get new cookies or a new token.'>
>>
>> Here as well, iirc it is possible to query a bug with python-bugzilla without
>> being logged in, so I would not expect this exception.
>>
>
> Yes, this bit seems new from the
bugzilla.redhat.com side AFAICT. But that's
> actually useful IMO; A common issue people have is that their credentials
> expire and it subtly changes the output of the bugzilla API... bugs stop
> showing up in queries since they are marked private, private info like
> qa_whiteboard disappears, etc. So if the user has an expired cached token I
> think it's better to bail out explicitly.
I guess I only partly agree. I use .logged_in() to check if I am logged in and
I have scripts that for which the user do not need to be logged_in. The new
workflow breaks them if their credentials are invalid, but the script doesn't
need these credentials. So, yes, I only partly agree and I would argue that the
script depending on the logged in status should check .logged_in().
Good point, but in the case when you know user doesn't need to be logged in,
you can explicitly request the bugzilla API _not_ use cached credentials by doing
bzapi = bugzilla.Bugzilla(url, cookiefile=None, tokenfile=None)
So I can see how this makes life a bit harder for scripts, but at the same
time it's a better default IMO for people using the API or /usr/bin/bugzilla
directly, especially for internal
bugzilla.redhat.com consumers working on
RHEL bugs, etc
Thanks,
Cole