Review Board

beta

Improvement to post-review when using webauth

Pending Review
Updated 3 months, 2 weeks ago

Xavier Duret Reviewers
reviewboard
513 chipx86
None Review Board SVN 
Ensure that "post-review" does not try to access the login page before checking whether webauth is enabled. There is a ugly hack in the patch. Instead to trying to access a review, "post-review" should access a specific page. I still have to figure out how to create a new webapi page on the server.
This was tested on the company server that is webauth enabled.
David Trowbridge
Posted 4 months, 2 weeks ago (July 8th, 2008, 12:06 a.m.)
Yeah, this is too ugly.  Creating a little "ping" API node sounds appropriate.
  1. Xavier Duret 3 months, 2 weeks ago (August 3rd, 2008, 4:40 a.m.) 
    What about the new patch.
Christian Hammond
Posted 3 months, 1 week ago (August 14th, 2008, 11:11 p.m.)
So, I'm not sold on this just yet. I'm not sure why post-review needs something special or why urllib should be asking for the username/password when we already do. I'd much rather we integrate things on the server-side such that the existing login URL works with the webauth code.

If done right, post-review won't need any special changes, the settings.WEBAUTH key won't need to exist, and the settings webapi path won't need to exist. I'm actually very reluctant to expose authentication method info in a public API call.
  1. Xavier Duret 3 months, 1 week ago (August 15th, 2008, 4:39 a.m.) 
    So what about using a HTTPPasswordMgr object when calling the login page. The "account_login" function on the server would ignore username and password if webauth is activated. This scheme however still require the user to type in its username and password which goes against deployment of single sign on with kerberos / ActiveDirectory.

As far as settings.WEBAUTH is concerned, its original purpose was to provide a variable for which to test in the templates (see bug #513). The login and logout links should be displayed or not based on its value. This was added because it turned out that actual end users were confused by the non functional login and logout links. When working using webauth, the webserver always asks for a password to access the page and the browser is happy to provide it. So unless there is a way to request the browser to forget about the password once the logout link has been clicked, it might be difficult to get rid of settings.WEBAUTH.