1093622 - authenticated calls from bzapi are failing: 'Untrusted Authentication Request'

Status: RESOLVED WONTFIX

(bugzilla.mozilla.org :: API, defect)

Description

[:glob ✱]

authenticated calls from bzapi are failing: 'Untrusted Authentication Request'

https://api-dev.bugzilla.mozilla.org/latest/bug/?username=choller%40mozilla.com&value0-0-0=%5Bjsbugmon%3A&query_format=advanced&type0-0-0=substring&resolution=FIXED&field0-1-0=status_whiteboard&value0-1-0=verify-branch&include_fields=_default&password=XXX&type0-1-0=substring&field0-0-0=status_whiteboard

Comment 1

[:glob ✱]

this is caused by bug 1090427.

i'm going to back out those changes so we can figure out what we can do to provide csrf protection in a way which doesn't break bzapi.

Comment 2

[:glob ✱]

To ssh://[e-mail]/webtools/bmo/bugzilla.git
   64fc523..ede3ced  master -> master

Comment 3

[David Lawrence [:dkl]]

BzAPI, for some operations such as search, etc., is using the normal cgi's such as buglist.cgi to get data back. It takes username=[e-mail]&password=password and converts it to Bugzilla_login=[e-mail]&Bugzilla_password=password before calling buglist.cgi. buglist.cgi thinks the user is using the login form at the top of each Bugzilla page since it doesn't know the user is a webservice. The form normally has a token embedded that is missing in this case so the error is being thrown.

1) We can leave this out until api-dev is decommissioned soon
2) Fix BzAPI to use the native REST search function instead of buglist.cgi as WebServices do not need the embedded token to work.
3) Hack the BMO code to not look for the token if referrer is api-dev
4) or fix BzAPI to obtain a login token and pass it along with the credentials.

1) obviously is the easiest fix. I would need to talk to Gerv and see how much effort would be involved with 2-4.

Thoughts?

dkl

Comment 4

[Gervase Markham [:gerv]]

1) We're aiming to decommission api-dev starting in a couple of weeks. Because we plan to replace with a redirect, we don't have to have zero usage before we decommission. But it may take a little while longer to get the alternative (redirecting) server stood up and in place.

2) is not possible unless the native REST search function has received a substantial upgrade such that it's as powerful as buglist.cgi. Last I heard, this hadn't happened, but I could be out of date.

3) That sounds fairly simple.

4) This would slow down BzAPI by one RTT for every search. Given 1), this doesn't sound like a great solution.

So I'd suggest 1). Are you guys OK with that?

Gerv

Comment 5

[David Lawrence [:dkl]]

(In reply to Gervase Markham [:gerv] from comment #4)
> 1) We're aiming to decommission api-dev starting in a couple of weeks.
> Because we plan to replace with a redirect, we don't have to have zero usage
> before we decommission. But it may take a little while longer to get the
> alternative (redirecting) server stood up and in place.
> 
> 2) is not possible unless the native REST search function has received a
> substantial upgrade such that it's as powerful as buglist.cgi. Last I heard,
> this hadn't happened, but I could be out of date.

Bug.search (and therefore /bzapi/bug) supports full search functionality similar to buglist.cgi (minus saved searches) for quite a bit now.

> 3) That sounds fairly simple.

Rather not do this as it is a customization which we would need to maintain.

> 4) This would slow down BzAPI by one RTT for every search. Given 1), this
> doesn't sound like a great solution.

This would also break getting a single bug as well I think since I remember you use show_bug.cgi?ctype=xml for that and it also requires a embedded login token.

> So I'd suggest 1). Are you guys OK with that?

I am fine with 1) as well.

dkl

Comment 6

[ibrahimdd27]

Hello Bugmozillar help me and fix all my problem with Apple Safari imac and Google chrome thank you very much

Comment 7

[:glob ✱]

looks like a WONTFIX is required here.