443210 - Implement Bugzilla.parameters to access parameters used in Bugzilla

Status: RESOLVED FIXED

(Bugzilla :: WebService, enhancement)

Description

[Max Kanat-Alexander]

In bug 428659, we throw an error if ssl is "authenticated sessions" and User.login is called without SSL. However, there's no way for a client to know if Bugzilla requires SSL for login or not, or even if it supports ssl!

So we have to include some way to get the ssl parameter.

Comment 1

[Max Kanat-Alexander]

Attachment: v1 for 3.2

Okay, here's the only two parameters that I think are very important to have for 3.2.

Comment 2

[Max Kanat-Alexander]

Attachment: WIP for HEAD

And this is more what it will look like on HEAD, although I'm not done yet.

Comment 3

[Frédéric Buclin]

IMO, the information listed in "WIP for HEAD" should not be disclosed if requirelogin = 1 and you are not logged in, because you cannot normally access this data from the web and there is no reason to bypass it using the API. The patch for 3.2 seems fine though as this information is already available when accessing the login page.

Comment 4

[David Lawrence [:dkl]]

Comment on attachment 327823 [details] [diff] [review]
v1 for 3.2

I dont see that the Bugzilla::WebService::type function is available under the 3.2 branch, only on HEAD. So you should use type() instead.

Comment 5

[Max Kanat-Alexander]

Since we got the ssl redirect working, this isn't a 3.2 blocker anymore, and in fact won't even go into 3.2 anymore.

Comment 6

[Frank Becker]

Attachment: patch, V3

If you think that we need some more parameters, please tell me what parameter you mean.

Comment 7

[Frédéric Buclin]

Comment on attachment 437087 [details] [diff] [review]
patch, V3

All parameters should be accessible as long as I'm in the tweakparams group.

Comment 8

[Frank Becker]

(In reply to comment #7)
> (From update of attachment 437087 [details] [diff] [review])
> All parameters should be accessible as long as I'm in the tweakparams group.

What should a user see who is not in he tweakparams group? 
* Nothing or some selected(which)

Comment 11

[Frédéric Buclin]

Attachment: patch, v4

I really need this for our QA tests, so taking!

Comment 12

[Max Kanat-Alexander]

Comment on attachment 585617 [details] [diff] [review]
patch, v4

Review of attachment 585617 [details] [diff] [review]:
-----------------------------------------------------------------

Awesome!

::: Bugzilla/WebService/Bugzilla.pm
@@ +42,5 @@
>      version
>  );
>  
> +# Logged-out users do not need to know more than that.
> +use constant PARAMETERS_WHITELIST => qw(

Let's call this PARAMETERS_LOGGED_OUT.

@@ +48,5 @@
> +    requirelogin
> +);
> +
> +# These parameters are guessable from the web UI when the user
> +# is logged in. So it's safe to access them.

The only problem is that you're also providing these values to third-party sites who *can't* log in, via JSONP. But I suppose that's true for all our APIs, so it's not like this would be a new security issue.

@@ +49,5 @@
> +);
> +
> +# These parameters are guessable from the web UI when the user
> +# is logged in. So it's safe to access them.
> +use constant PARAMETERS_WHITELIST_EXTENDED => qw(

And this PARAMETERS_LOGGED_IN.

@@ +387,5 @@
> +    C<useqacontact>,
> +    C<usestatuswhiteboard>,
> +    C<usetargetmilestone>.
> +
> +A user being in the tweakparams group can access all existing parameters.

Remove "being".

Right after this sentence, add:

The list of parameters returned by this method is not stable and will never be stable.

Comment 13

[Frédéric Buclin]

I fixed everything you said on checkin. Thanks! :)

Committing to: bzr+ssh://[e-mail]/bugzilla/trunk/
modified Bugzilla/WebService/Bugzilla.pm
Committed revision 8066.

Comment 14

[Frédéric Buclin]

Added to relnotes for 4.4.