So the thing that may be the problem is fastcgi. There was a discussion
about an option you have to enable in fastcgi (we'll be updating the
auto-generated config for new sites, but existing ones need to be updated
manually). It turns out this part of the discussion happened off the list,
though, so I guess you wouldn't be able to easily find it...
So, fastcgi, like mod_wsgi, strips the Authorization header by default. From
these docs (
looks like there's a "FcgidPassHeader Authorization" directive you can place
in your fastcgi configuration to possibly work around this. I'd give that a
shot. Note this is for mod_fcgid. There's probably a related one for
mod_fastcgi. Depends on which you're actually using under the hood. So you
may have to google for variations on this if not using fcgid.
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com
On Thu, Mar 24, 2011 at 12:48 AM, Stein, Ruben <
> On 15.03.2011, at 21:46, Christian Hammond wrote:
> > Are you behind a proxy server?
> No, I am not behind a proxy server.
> > With 0.3.2, can you run with --debug and provide the output?
> The output is attached as "debug_output_rbtools_0.3.2.txt"
> I can report some details concerning the problem:
> 1. While playing around with the login problems I found out, that
> allowing anonymous read access brings post-review some steps further,
> but then again it stops asking for Web-API credentials although user
> name and password were provided via command line. See
> "debug_output_anonymous_read.txt" for the output.
> 2. The behavior of post-review 0.2 on osx does not differ from the one
> on windows, that was wrong. The difference resulted from the fact,
> that I had a valid cookie in my ".postreview-cookies.txt" on osx. As
> soon as I copy that cookie to the windows machine, I can authenticate
> there as well.
> 3. With the valid cookie in my .postreview-cookies.txt file it seems
> to to ignore any credentials on the command line. I start pushing a
> diff-file with a --username= argument, but without password. post-
> review then prompts for a password, as expected. But no matter what I
> type there, the operation will always succeed due to the cookie. Does
> review-board use the cookie as fallback authentication method if the
> password is false? I would expect the operation to fail if I provide a
> specific user name and an invalid password is typed. Maybe this is
> related to this older bug:
> See "debug_output_withoutcookie.txt" for an example.
> 4. My normal authentication mechanism is ActiveDirectory. Changing back to
> standard authentication does not solve the problem.
> Sorry for re-posting the message, I think I tamed the mail-client now.
> Regards, Ruben
> Want to help the Review Board project? Donate today at
> Happy user? Let us know at http://www.reviewboard.org/users/
> To unsubscribe from this group, send email to
> For more options, visit this group at
Want to help the Review Board project? Donate today at
Happy user? Let us know at http://www.reviewboard.org/users/
To unsubscribe from this group, send email to
For more options, visit this group at