Hi Zach,

We haven't made any changes on our end. If there's a problem, then this is
an area where we'll likely need someone with such a setup to work with us
on a patch.

I'm looking at the differences between post-review and RBTools, and where
this is concerned, there are changes but minor ones. Most of the
distinctions between the two arguments were actually for the old Review
Board 1.0 API, which we no longer support.

In the modern API (Review Board 1.5 onward), HTTP basic auth is always used
for authentication. When --username is passed, we pre-set the Authorization
header for the request with the username/password provided, which will
result in the credentials being validated and a cookie returned (or an
error if invalid). This was true on both post-review and modern RBTools.

In post-review, the major distinction between the two was when using the
1.0 API. --http-username would be used for any Basic Auth requests, and
--username would be used for the old API to say "Log in with these
credentials."

When using old post-review against the modern API, it looks like both would
end up feeding to the same values. If --username was provided, but
--http-username was not, then --username would be used for pre-filling the
Basic Auth credentials. If that failed to authenticate, it would fall back
to the value in --http-username (if provided), and then fall back to asking
the user for credentials.

Note that this *only* applied to the "Web API" Basic Auth domain. For all
others, we fall back to the default behavior of Python's URL library, and
we don't provide any credentials there.

So in essence, for a modern API, --http-username/--http-password became the
second set of credentials to try if --username/--password failed for the
"Web API" domain. That's why we removed it. It didn't make much sense in a
world where we only needed to support the modern API.

Modern RBTools got rid of the distinction, allowing only the one set of
credentials to be used, but the rest of the logic remained as-is. If those
credentials failed, the user is prompted. If it's not the "Web API" domain,
we fall back to default Python behavior.

There is one difference I'm noting, which is more of an accident than an
intentional set of behavior in post-review. If you do not pass --username,
but you do pass --http-username, it will not prefill the auth but will send
the username/password when requested by the API, before trying to prompt.
In modern RBTools, passing --username will prefill, but not passing it
means it won't prefill. In the case of not prefilling, it will just prompt
the user.

It's a small difference, but what it means is that if you're going through
some sort of middle HTTP layer that would get tripped up by an unexpected
Authorization header, post-review with --http-username but not --username
will prevent an Authorization header from being sent until requested, but
modern RBTools won't do this. This should really only be a problem if the
HTTP layer is doing different things with an Authorization header depending
on whether the previous HTTP response to that client requested
authorization (which is a dangerous thing for an HTTP layer to do).

That may have all been confusing. What it boils down to is that I would
expect --username to work in all situations where --http-username worked,
with the exception of some HTTP proxy that's making bad assumptions about
when to expect Authorization headers.

Can you tell me more about your setup?

Christian

-- 
Christian Hammond - christ...@beanbaginc.com
Review Board - https://www.reviewboard.org
Beanbag, Inc. - https://www.beanbaginc.com

On Tue, Aug 11, 2015 at 9:36 AM, Zach <zach...@gmail.com> wrote:

> Meant to say that "the old `post-review` tool had --http-username and
> --http-password options that seemed to use basic auth ...".
>
>
> On Tuesday, August 11, 2015 at 12:34:51 PM UTC-4, Zach wrote:
>>
>> Hey Chris,
>>
>> Was there ever any progress made here? I notice that the old
>> `post-review` tool (
>> https://www.reviewboard.org/docs/manual/1.7/users/tools/post-review/)
>> but the new RBTools==0.7.4 only has --username and --password which do not
>> use basic auth against the api.
>>
>> Our company uses single-sign-on with fallback to basic auth (which
>> authenticates against active directory) and this feature will be important
>> to our users as well.
>>
>> >>> Making HTTP GET request to http://reviewboard/api/
>> >>> Got HTTP error: 401
>>
>> -Zach
>>
>> On Tuesday, June 24, 2014 at 1:38:03 AM UTC-4, Pierre Mariani wrote:
>>>
>>> We use Review Board at work. It is installed on a web server that
>>> is protected by HTTP Basic Authentication.
>>>
>>> We haven't been able to use RBTools to interact with it as we
>>> couldn't find the right configuration to pass this authentication
>>> wall.
>>>
>>> After looking through the code, I didn't see how it could be
>>> configured at all, and came to the conclusion that this feature
>>> wasn't supported.
>>>
>>> I also didn't find an obvious way to modify
>>> ReviewBoardHTTPBasicAuthHandler or ReviewBoardHTTPPasswordMgr to
>>> add that feature.
>>>
>>> I resorted to defining a new server option, and passing it
>>> through RBClient, SyncTransport and finally to ReviewBoardServer,
>>> where it is used to define a new urllib2.HTTPBasicAuthHandler
>>> which gets added to the list of handlers.
>>> You can see the diff at
>>> https://github.com/pmariani/rbtools/compare/basic-auth-hack
>>>
>>> It's hacky but good enough for my use case.  However, I would
>>> rather not maintain a fork and would like to be able to push
>>> similar changes back to the main RBTools repo.
>>>
>>> Can someone confirm that HTTP Basic Authentication isn't currently
>>> supported
>>>  in RBTools?
>>>
>>> Are there design resources that would let me adapt my hack to
>>> something acceptable by the project?
>>>
>>> Thank you
>>>
>>>
>>> --
> Supercharge your Review Board with Power Pack:
> https://www.reviewboard.org/powerpack/
> Want us to host Review Board for you? Check out RBCommons:
> https://rbcommons.com/
> Happy user? Let us know! https://www.reviewboard.org/users/
> ---
> You received this message because you are subscribed to the Google Groups
> "reviewboard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to reviewboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
Supercharge your Review Board with Power Pack: 
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: 
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
--- 
You received this message because you are subscribed to the Google Groups 
"reviewboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to