HTTP-Authenticating on behalf of user?
Bogien
Suppose I have a directory in my htdocs which is protected
by HTTP-Authentication (.htpasswd file). Is there any way
to peform the authentication on behalf of user, knowing
his login & password? Of course, I can send HTTP refresh
with new url set to "http://login:pass...@www.server.com/mydir/".
But since the login-password pair is uncrypted, this method
is unsecure...
Thanks for any help!
Sundial Services
Implementing the site as secure (https:...) might encrypt the password
exchange.
But usually you build your own login-screen.
Serialtransmit
"http://login:pass...@www.server.com/mydir/".
is OK for Netscape and Opera. If You calling request in Internet Explorer, so IE request user name and password one more. And this is problem.
Calling this addeess for netscape, in Location You have:
"http://login:pass...@www.server.com/mydir/".
in Opera
"http://login:****@www.server.com/mydir/".
Tom
Martin Wickman
might => will
> But usually you build your own login-screen.
Why should he do that when basic authentication is the preferred and
only RFC:ed method? In conjunction with ssl/https it is extremely
secure.
Besides "build your own login-screen" implies creating your own
security model. Yeah, sounds clever. Leave that to apache.
KAH
news:slrnaqndop....@localhost.localdomain:
>> But usually you build your own login-screen.
>
> Why should he do that when basic authentication is the preferred and
> only RFC:ed method? In conjunction with ssl/https it is extremely
> secure.
>
> Besides "build your own login-screen" implies creating your own
> security model. Yeah, sounds clever. Leave that to apache.
Why shouldn't he? Building your own user system gives you much more control
over how things work and makes things a lot easier. With sessions, you get
very high security (especially if you combine it with SSL) if PHP is
configured right (session data saved where nobody that isn't meant to be
able to get it can get it). Actually, I'd prefer using my own system over
basic auth because then I can implement a logout feature, something which
basic auth doesn't even have. That's one hell of a security hole,
especially if the user is in a place (like a in library) where the user
might not be able to end the browser session as to "log out". If you're
clever, you can create solutions that are more secure and more flexible
than basic auth. A custom user system may not be RFC-ed, but why should it
be? It's more effective not involving the client so much in the auth
process, and more secure.
KAH
Martin Wickman
>> security model. Yeah, sounds clever. Leave that to apache.
>
> Why shouldn't he? Building your own user system gives you much more
> control over how things work and makes things a lot easier.
1. Set up apache with basic auth
2. Use $REMOTE_USER variable if you want to know the users uid
How hard was that?
> With sessions, you get very high security (especially if you combine
> it with SSL) if PHP is configured right (session data saved where
> nobody that isn't meant to be able to get it can get it).
I dont say that sessions are bad. The problem is there are 1000s of
session systems out there and just the fact that you have to check the
session in each and every php-script you are writing makes this quite
easy to forget. Also make *absolutely* that your handwritten code is
fool-proof, and as well all know -- witing "hacker-proof" is not for
the timid. Also, I can guarantee that apaches code for basic auth is
better than anything you (or I) can produce in php.
> Actually, I'd prefer using my own system
> over basic auth because
> then I can implement a logout feature, something which basic auth
> doesn't even have. That's one hell of a security hole, especially if
> the user is in a place (like a in library) where the user might not
> be able to end the browser session as to "log out".
Granted, there is not logout function implemented in current browsers
and that may be one drawback, although I dont find it such a big deal.
> If you're clever, you can create solutions that are more secure and
> more flexible than basic auth.
Maybe more flexible, but I doubt more secure. It all boils down to the
browsers handling of the cookie, something which you cannot control.
> A custom user system may not be RFC-ed, but why should it be?
Here is the reason:
What I also find really interesting with basic auth, and in fact one
of the main reasons for using it is to accomplish single-sign-on!
Use ProxyPass + Basic auth in apache and any wellbehaved application
can be incorporated in your site with only one login prompt. For
instance, I have an IIS-asp accounting system, a Java TomCat
application, loads of PHP and even a Lotus Domino application under
the same apache server using this method (Not the same physical apache
obviously, but proxying to the IIS, Java and Notes server)
There is no way you can do that with php-sessions. Why? Becasue there
is no standard
> It's more effective not involving the client so much in the auth
> process
This basic auth the client need only to send one simple extra
header. Compare that to the houskeeping of cookies which occupies
thousands of C++ code in your browser.
> and more secure.
Except the "cannot log out part", I disagree with you.