Build A Custom Login UI

[paulpixel]

I have no problem in using the normal methods to force an HTTP login challange. Each and every one of the scores of login scripts, libs, and methods I've looked at, just "validate" the user / pass pair, and then allow the user in to a particular script or page.

They don't SET the user / pass ( or the $PHP_AUTH_USER). I need to allow for edit perms for files in the public web tree, in an admin context. So the admin(s) can ediit html, and xml content in the public area of the site.

The Challange screens that the HTTP headers method brings up is totally unexeptable, and I need to feed the user / pass with a custom UI.

Does anyone out there know how to set these vars so that I can run as a "known and trusted user"

Thanks in Advance
Paul

[dalecosp]

Is PHP running as Apache module, or CGI?

dalecosp

[paulpixel]

module

[dalecosp]

Originally posted by paulpixel
They don't SET the user / pass ( or the $PHP_AUTH_USER).

The manual claims they do:

Once the user has filled in a username and a password, the URL containing the PHP script will be called again with the predefined variables PHP_AUTH_USER, PHP_AUTH_PW, and PHP_AUTH_TYPE set to the user name, password and authentication type respectively.

So if they don't, is it a bug or a feature 😉 ?

I need to allow for edit perms for files in the public web tree, in an admin context. So the admin(s) can ediit html, and xml content in the public area of the site.

Does anyone out there know how to set these vars so that I can run as a "known and trusted user"

Paul

Who owns the files now, who does the server run as, and do you have site administrator privileges? What area of the site is the "public" area....?

By way of example, I make stuff I want to change via PHP owned by the web user. It's not a great idea, but IMO it's not a great idea to let the webserver have any other privileges anyway. Your situation seems to differ from mine a bit, OTOH.

[paulpixel]

Well...

I'm running module mode, and with a pretty standard php 4.1.2 setup in an apache server running on linux.

When I pass off to this script with a simple form, I still get the standard login screen pop up, which of course means that trying to populate

$PHP_AUTH_USER or $PHP_AUTH_PW with passed get vars is just not working..

$PHP_AUTH_USER = $user_name;
$PHP_AUTH_PW = $password;

if ((!isset($PHP_AUTH_USER)) || (!isset($PHP_AUTH_PW))) {

header( 'WWW-Authenticate: Basic realm="Private"' ); 
header( 'HTTP/1.0 401 Unauthorized' ); 
echo 'Not Authorized'; 
exit; 

} else {

echo 'Authorized';
}

I also tried setting the vars and then write to a file owned by the root user.. I just get an Apache permission error.

I also tried making the form names pass the vals directly as in

<form action="auth_test2.php" method="POST">
<input type="text" name="PHP_AUTH_USER"><br>
<input type="text" name="PHP_AUTH_PW">
</form>

(I also tried the GET method)

Also no luck.. What gives.. this is VERY simple code here, not rocket science. What is the small point I'm just to stupid to get!

Paul the Pixel

[paulpixel]

PS...

I also have code that uses a socket connection to check to see if the submitted user / pass pair represents a known user/pass

There is some basic point here I'm just not getting with registering the client as a user with apache.

Paul

[dalecosp]

Well, I dunno for sure. One thing that comes to mind is that PHP_AUTH_USER is part of the $_SERVER superglobal, and it doesn't look like you're calling it with that.

This one, written by intenz, works...look at it here.

dalecosp

[paulpixel]

This is the same ol same ol.. All this will do is bring up the standard "built in" challange screens that are part of the browser DOM.

The problem is not looking to see if $_SERVER['PHP_AUTH_USER'] is set.. the problem is setting it via a regular HTTP post. ( or even setting from code within a page or template)

I'll try seeing if populating the core array makes a difference, but according to PHP documentation, $PHP_AUTH_USER is just as global as $_SERVER['PHP_AUTH_USER'].

I'll let you know if I have any success.

Paul

[paulpixel]

Yup..
as I thought

PHP------------------------------------------
$SERVER['PHP_AUTH_USER'] = "myrootname";
$SERVER['PHP_AUTH_USER'] = "myrootpassword";

if ((!isset($SERVER['PHP_AUTH_USER'])) || (!isset($SERVER['PHP_AUTH_PW']))) {

header( 'WWW-Authenticate: Basic realm="Private"' ); 
header( 'HTTP/1.0 401 Unauthorized' ); 
echo 'Not Authorized'; 
exit; 

} else {

echo 'Authorized';

}

doesn't work.. I can't set

$_SERVER['PHP_AUTH_USER']. Its behaving just as if I tried to over-ride a session var with POST var of the same name.. it just ignores it.

The whole problem is I HAVE to build branded custom login screens, with password help call backs etc.

All I want to be able to do is 'script' the login to known server user account(s). This is WAY easy in java, jsp, coldfusion or even TANGO! What gives.

Paul

[dalecosp]

Originally posted by paulpixel
All I want to be able to do is 'script' the login to known server user account(s). This is WAY easy in java, jsp, coldfusion or even TANGO! What gives.

Paul

OK, if this is really the issue here then I'm thinking these things.

1. You want to use PHP to log in a Unix/Linux user to 'root,' or some account in 'wheel' group or other elevated privilege user.

2. You cannot do this with Apache & mod_php, because Apache forks children with little privileges to hand user requests.

3. You MAY be able to do this with a compiled PHP binary in CGI, using suexec() or some such, but this is known to be fraught with peril and another solution should possibly be sought out and evaluated before you go ahead with the first idea.

from the manual's 'user contributed notes.'

If you're running PHP as apache module, it will always write files as "nobody", "www", "httpd", (or whatever user your webserver runs as) unless you specify a different user/group in httpd.conf, or compile apache with suexec support.
However, if you run PHP as a CGI wrapper, you may setuid the PHP executable to whatever user you wish (severe security issues apply). If you really want to be able to su to other user, I recommend compiling with suexec support.
AFAIK, PHP can't NOT use SuEXEC if apache does. If PHP is configured as an apache module it will act as whatever user the apache is. If apache SuEXEC's to otheruser:othergroup (e.g. root:root), that's what PHP will write files as, because it acts as a part of apache code. I suggest you double-check your SuEXEC configuration and settings. Note: you can't su to another user within the PHP code -- it has to be an apache directive, either through <VirtualHost>, or through .htaccess. Also note: I'm not sure how it all works (if it works at all) on Win32 platforms.
Check www.apache.org to see how it's done.

Good luck,

[paulpixel]

yup.

Last night I had tested the suexec route, and actually this may work for me. The main problem with using system executable commands of course is that if they are messagable from get or post args, you've just given every hacker and script kiddie in the universe the keys to the kingdom.

This may not be a problem for me and this is why.

The system I'm writing is an xml database. The security for the application is "Role" based. and the member profiles, roles, and passwords are blowfish128 encrypted. Plus the xml object lib lives behind web root.

So before any suexec command could run, the user would have already been authenticated as a known and trusted admin for the application, or they'd just get bounced back to the login screen.

The UI's themselves in the application control what is editable, viewable etc. based on perm controls embedded in each xml object (there are xml objects that control the behaviour of directories as well).

You're right though. I really will have to study all the implications of using suexec before I adopt that particular stratagy.

Some screen captures of the application can be found at
http://www.pauldempsey.com/Technology/array.htm

Thanks for your help

[dalecosp]

The system I'm writing is an xml database. The security for the application is "Role" based. and the member profiles, roles, and passwords are blowfish128 encrypted. Plus the xml object lib lives behind web root.

So before any suexec command could run, the user would have already been authenticated as a known and trusted admin for the application, or they'd just get bounced back to the login screen.

Just by way of thought, I'd probably look into setting this up over VPN or SSL rather than plaintext http.

A thought, and glad we're reading each other more accurately now. 😉