Username Password
Bookmark and Share
View All Tickets
Using Basic Auth with WebGUI  (#12198)

When I turn on Basic Auth in the modproxy config and use an external htpasswd file, I'm seeing the following errors in the webgui.log file everytime a user accesses a protected page (which can be a significant number of errors):

2011/07/15 10:46:15 - WARN - servername.conf - WebGUI::Session::ErrorHandler::security[412] - Admin (3) connecting from  attempted to BA_USER failed to login using HTTP Basic Authentication

So, even if I get past the Apache basic auth in modproxy, WebGUI is throwing up another basic auth login which fails (even if I use a valid WebGUI username/password; presumably because my headers already contain basic auth credentials).

Something seems wrong with the implementation that it's generating all these errors as well as causing havoc with my users who have to occassionally hit the "cancel" button when the extra basic auth login message is presented from WebGUI.

Also, note that besides being an oddly worded error message (e.g., "attempted to USERNAME failed..."), the WebGUI::Session::ErrorHandler::secure() method is calling WebGUI::Session::Env::getIp to get the ip to insert into the error message and is coming up empty. Is that an Apache configuration issue? I'm using a fairly stock version of WRE.


Solution Summary
8/8/2011 6:31 pm
I'm not sure why it is failing to come up with the client IP, but I'm having that problem too.

Reading the code, it looks like it is intended to respond to HTTP auth requests by attempting to log the user into WebGUI with the username/password supplied.

The only fix for this I can think of is to make this behavior optional and configurable, with a default of continuing to do what it is currently doing.
8/8/2011 7:24 pm
I don't see a way in Apache2 API docs to see the results of previous request phases, but these docs are notoriously obtuse.

Another option would be to drop support for this entirely and not try to be backwards compat in this.
8/9/2011 8:09 pm
I'm not sure I understand the implications of "dropping support for this entirely." Are you suggesting that WebGUI stop using Basic Auth for tracking login status? That would be preferable for me as it would prevent this type of interference that I describe.
8/10/2011 1:59 am
preaction explained to me on IRC that support for logging in with HTTP Basic auth was written for people using simple bots, such as RSS feed readers, to use.  After brief discussion, it was decided that logging in by HTTP Auth should continue to work, but this problem should be worked around by never sending a failure code.  In the case of failure, the user stays logged in as visitor (or whoever they were logged in before sending the headers).

I've been wrestling with mod_perl all day.  Simple changes in the code broke everything.  mod_perl has you do this magical incantation:

$request = Apache2::Request->new($request);

That cycles your Apache2::RequestReq object into an Apache2::Request, but on my source install of mod_perl, with simple code changes, it didn't.  I spent most of my time fighting with this.  Since you need the latter type of object to get at decoded request parameters and other important things, it is necessary.  Pardon me while I vent.

Anyway, this seems to be working, but I need to look at again when I'm fresh and run tests on it.
9/7/2011 7:30 pm
commit 622391b61d29f91eb8e12fed9e63870a84f968dd:

Per IRC discussion with preaction, make HTTP auth failures soft failures.  Don't attempt to re-auth the user on failure.  Otherwise, .htaccess or similar put in place to protect a site and WebGUI get into a skirmish (users are asked to re-auth even if they did the .htaccess correctly, the log gets flooded, cats get radio shows, etc).

knowmad, I've written some tests for this and tested this a bit myself, but it would be helpful if you pulled the git/dev version of WebGUI and tested this in your environment.
Ticket Status Resolved  
Submitted Byknowmad 
Date Submitted2011-07-15 
Assigned To unassigned  
Date Assigned2019-08-25 
Assigned By 
Severity Critical (mostly not working)  
What's the bug in? WebGUI Stable  
WebGUI / WRE Version 7.10.19  
Related Files
Ticket History
6:38 PM
Resolved scottwalters
3:27 PM
Ticket created knowmad
© 2019 Plain Black Corporation | All Rights Reserved