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 - [email protected] Review Board - https://www.reviewboard.org Beanbag, Inc. - https://www.beanbaginc.com On Tue, Aug 11, 2015 at 9:36 AM, Zach <[email protected]> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
