Re: Optional HTTP Authentication ?
Jean-Michel Hiver <[EMAIL PROTECTED]> writes: > > However, if the structure were > > > > http://bigmegamarket.com/index.pl/56765454151/grocery/fruits/bananas, > > say, with the number being the session ID, the URL then is hackable > > within that (good) definition. > > Yes, however there are quite a number of issues with bookmarks and > search engines... But that's for sure another interesting and less-ugly > option. Very true. I was solving only the stated problem, and didn't think much about the other problems that would then appear. > > I'm a big fan of cookies myself, for the thing they were made for, > > namely session tracking. I share your frustration :-(. > > Yep. It's a shame that cookies which were a good idea at first get such > a bad name because of all these moronic marketing companies which dream > of knowing you inside out to send you more shit spam abuse them. But I'm > off topic here :-) And that's all it is; a bad *name*. With the option to refuse to deliver cookies to a domain different from the domain of the top-level page, they have no actual problems. And they solve the problem they're supposed to solve nearly perfectly. Obviously for individual projects one has to do what the people with the checkbook say, but we shouldn't be just rolling over on cookies; we should be arguing the point strenuously. -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
Re: Optional HTTP Authentication ?
Thanks to the list and two days of hard work, I have my optional HTTP
authentication thingie working :-)
Basically here is how it looks in my apache config file:
# This method handler ensures that users must enter their credentials
# for any URI which looks like /foo/bar/login.html
AuthName "MKDoc Login"
AuthType Basic
PerlAuthenHandler MKDoc::Auth::SQL_HTTP->handler
require valid-user
# This method handler affects the whole site, it sets the
# $ENV{REMOTE_USER} variable if the credentials have been sent, or
# leave it undef otherwise.
PerlFixupHandler
MKDoc::Auth::SQL_HTTP->handler_opt
# if the user successfully logged in when hitting a /foo/bar/login.html
# location, then we want to redirect him where he came from
SetHandler perl-script
PerlHandler
MKDoc::Auth::SQL_HTTP->handler_redirect
require valid-user
* Now if you go to /properties.html BEFORE sending the credentials,
* You're redirected to /login.html?from=/properties.html where you login,
* Which redirects you to /properties.html... but this time your browser
sends the credentials!
This is interesting because it's up to the handlers to decide wether
they need authentication or not and does non depend on the location.
> More important is the fact that if a page does not require authentication,
> the users login and password will not be sent. So a page like index.html that
> is not normally authenticated will not receive the username, and no
> Admin this page will be possible.
This is not true, once you've entered the credentials on /login.html the
browsers send them everywhere. Tested under Opera (Linux), Mozilla
(Linux) and IE from version 3 to version 6 (Windows), IE 3 (Mac),
Netscape 4 (Mac).
One exception: links :-(. But the browser support seems to be there...
In the future I plan to have some kind of hybrid handler which would
accept either HTTP credentials OR a cookie... that would be cool :-)
> I'm not 100% sure this is possible without the use of cookies. I'm pretty sure
> you could write some custom handler to handle the auth, but without a cookie
> to note which users have authenticated, you might be out of luck.
Well I seem to have done it, so it must be possible thanks to you guys
;-. I will send the code to anyone who's interested but I don't want
to post it to the list because I suspect that most people aren't.
Thank you everyone,
Cheers,
--
IT'S TIME FOR A DIFFERENT KIND OF WEB
Jean-Michel Hiver - Software Director
[EMAIL PROTECTED]
+44 (0)114 255 8097
VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
Hi there, On 30 Jun 2002, Randal L. Schwartz wrote: > What? The EU is going to make cookies *illegal*? I highly doubt this. There is already EU legislation which might make the use of cookies suspect. It concerns, for example, the monitoring of individual keyboard operators to measure their performance. That's been illegal in the EU for some time. You only have to start counting your cookies to be treading on shaky ground. 73, Ged. BTW it's modperlperlapacheorg
Re: Optional HTTP Authentication ?
On Mon, Jul 01, 2002 at 10:30:36AM +0100, Jean-Michel Hiver wrote:
> > > browser sent the credentials, or leave $ENV{REMOTE_USER} undef
> > > otherwise, without sending a 401 back.
> >
> > I didn't think a browser would send authentication unless the server
> > requested it for an authentication domain. How are you going to
> > get some people to send the credentials and some not unless you
> > use different URLs so the server knows when to request them?
>
> The idea is that on a "location" which requires authentication I'll
> redirect the user to a /login.html, or maybe a /?login=1 which will do
> the following:
Umm... Perhaps I don't understand the significance of the login.html. Under
HTTP auth, if a page is protected via .htaccess then auth is immediatly
requested, and no redirect is possible.
More important is the fact that if a page does not require authentication,
the users login and password will not be sent. So a page like index.html that
is not normally authenticated will not receive the username, and no
Admin this page will be possible.
I'm not 100% sure this is possible without the use of cookies. I'm pretty sure
you could write some custom handler to handle the auth, but without a cookie
to note which users have authenticated, you might be out of luck.
Good luck,
Rob
Re: Optional HTTP Authentication ?
>From: "Jean-Michel Hiver" <[EMAIL PROTECTED]> > Oh but I have that already. I know that I need to password protect > > /properties.html > /content.html > /move.html > /foo/properties.html > /foo/content.html > /foo/move.html > etc... > > Is it possible to password-protect a class of URIs using regexes? That > would be another good option. I thought you meant that you wanted the same location to be accessed by different people with/without passwords. You should be able to put the authentication directives in a container in this case. Another approach would be to use mod_rewrite to map the request to a directory containing a symlink to the script and an appropriate .htaccess file. This is kind of brute-force but it lets you do anything you want with a request including proxying to an otherwise unreachable port or server for certain content. Unfortunately I think the symlink approach appears as a different script to mod_perl so it will cache a separate copy in memory. Les Mikesell [EMAIL PROTECTED]
Re: Optional HTTP Authentication ?
> > browser sent the credentials, or leave $ENV{REMOTE_USER} undef
> > otherwise, without sending a 401 back.
>
> I didn't think a browser would send authentication unless the server
> requested it for an authentication domain. How are you going to
> get some people to send the credentials and some not unless you
> use different URLs so the server knows when to request them?
The idea is that on a "location" which requires authentication I'll
redirect the user to a /login.html, or maybe a /?login=1 which will do
the following:
IF user is authenticated => redirect to location it came from
ELSE send 401 authorization required
This way users should get a login box strictly when necessary. Almost
all the request go thru an Apache::Registry friendly CGI script:
Alias /.static /opt/chico/static
Alias //opt/mkd/cgi/mkdoc.cgi/
Everything is treated using $ENV{PATH_INFO} in the script, and the
script knows when something needs authentication or not.
> Note that you don't have to embed session info here, just add
> some element to the URL that serves as the point where you
> request credentials and omit it for people that don't log in. Or
> redirect to a different vhost that always requires authentication but
> serves the same data.
Oh but I have that already. I know that I need to password protect
/properties.html
/content.html
/move.html
/foo/properties.html
/foo/content.html
/foo/move.html
etc...
Is it possible to password-protect a class of URIs using regexes? That
would be another good option.
Cheers,
--
IT'S TIME FOR A DIFFERENT KIND OF WEB
Jean-Michel Hiver - Software Director
[EMAIL PROTECTED]
+44 (0)114 255 8097
VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
> However, if the structure were > > http://bigmegamarket.com/index.pl/56765454151/grocery/fruits/bananas, > say, with the number being the session ID, the URL then is hackable > within that (good) definition. Yes, however there are quite a number of issues with bookmarks and search engines... But that's for sure another interesting and less-ugly option. > I'm a big fan of cookies myself, for the thing they were made for, > namely session tracking. I share your frustration :-(. Yep. It's a shame that cookies which were a good idea at first get such a bad name because of all these moronic marketing companies which dream of knowing you inside out to send you more shit spam abuse them. But I'm off topic here :-) Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
>From: "Jean-Michel Hiver" <[EMAIL PROTECTED]>
>
> I *CANNOT* use cookies nor URIs for any kind of session tracking.
> Otherwise I don't think I would have posted this message to the list in
> the first place :-)
>
> I agree that HTTP Basic authentication is totally and uterly ugly, but I
> am going to have to stick with it no matter what... My problem is:
>
> How do I tell apache to set the $ENV{REMOTE_USER} variable if the
> browser sent the credentials, or leave $ENV{REMOTE_USER} undef
> otherwise, without sending a 401 back.
I didn't think a browser would send authentication unless the server
requested it for an authentication domain. How are you going to
get some people to send the credentials and some not unless you
use different URLs so the server knows when to request them?
Note that you don't have to embed session info here, just add
some element to the URL that serves as the point where you
request credentials and omit it for people that don't log in. Or
redirect to a different vhost that always requires authentication but
serves the same data.
Les Mikesell
[EMAIL PROTECTED]
Re: Optional HTTP Authentication ?
Hi, Jean-Michel: the "official" way to retrieve the remote user name under
Basic Authentication is to call for $r->connect->user(), or $r->user() in
mod_perl 2.0, I think. With a ticket authentication, one gets the user name
in the same way only AFTER the access control phase, because it is simulated
from the ticket, see e.g. my Apache::CookieAccess source at
modperl.home.att.net. BTW, for me, Basic Authnetication is not that ugly, it
is surpringly stable (than most of other Apache ideas) since day one.
Peter Bi
- Original Message -
From: "Jean-Michel Hiver" <[EMAIL PROTECTED]>
To: "Peter Bi" <[EMAIL PROTECTED]>
Cc: "Jean-Michel Hiver" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, June 30, 2002 12:20 PM
Subject: Re: Optional HTTP Authentication ?
> On Sun 30-Jun-2002 at 10:47:26AM -0700, Peter Bi wrote:
> > Please check that the idea of this kind of authentication is to encrypt
the
> > ticket, instead of a plain session ID. If cookie is not available,
having
> > it on URI is a good idea. (Then one needs to have all links in a
relative
> > manner; see the Cookbook). Cookie itself does not make a secure session
ID
> > or a secure ticket. It is the encryption that does.
>
> I *CANNOT* use cookies nor URIs for any kind of session tracking.
> Otherwise I don't think I would have posted this message to the list in
> the first place :-)
>
> I agree that HTTP Basic authentication is totally and uterly ugly, but I
> am going to have to stick with it no matter what... My problem is:
>
> How do I tell apache to set the $ENV{REMOTE_USER} variable if the
> browser sent the credentials, or leave $ENV{REMOTE_USER} undef
> otherwise, without sending a 401 back.
>
> Cheers,
> --
> IT'S TIME FOR A DIFFERENT KIND OF WEB
>
> Jean-Michel Hiver - Software Director
> [EMAIL PROTECTED]
> +44 (0)114 255 8097
>
> VISIT HTTP://WWW.MKDOC.COM
>
Re: Optional HTTP Authentication ?
Jean-Michel Hiver <[EMAIL PROTECTED]> writes: > > Why is a user "hacking" their URLs? > > I can answer that. http://www.useit.com/alertbox/990321.html > > > * a domain name that is easy to remember and easy to spell > * short URLs > * easy-to-type URLs > * URLs that visualize the site structure > * URLs that are "hackable" to allow users to move to higher levels of > the information architecture by hacking off the end of the URL > * persistent URLs that don't change > I generly agree with alertbox, and I agree in this instance. > i.e. http://bigmegamarket.com/grocery/fruits/bananas/ is cool, > http://bigmegamarket.com/index.pl?id=231223412&sid=56765454151 is not. Both true. However, if the structure were http://bigmegamarket.com/index.pl/56765454151/grocery/fruits/bananas, say, with the number being the session ID, the URL then is hackable within that (good) definition. > Again it doesn't always make implementation easy :-/ True enough; and my proposal is a bit harder to implement. I'm a big fan of cookies myself, for the thing they were made for, namely session tracking. I share your frustration :-(. -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
Re: Optional HTTP Authentication ?
On Sun 30-Jun-2002 at 10:47:26AM -0700, Peter Bi wrote:
> Please check that the idea of this kind of authentication is to encrypt the
> ticket, instead of a plain session ID. If cookie is not available, having
> it on URI is a good idea. (Then one needs to have all links in a relative
> manner; see the Cookbook). Cookie itself does not make a secure session ID
> or a secure ticket. It is the encryption that does.
I *CANNOT* use cookies nor URIs for any kind of session tracking.
Otherwise I don't think I would have posted this message to the list in
the first place :-)
I agree that HTTP Basic authentication is totally and uterly ugly, but I
am going to have to stick with it no matter what... My problem is:
How do I tell apache to set the $ENV{REMOTE_USER} variable if the
browser sent the credentials, or leave $ENV{REMOTE_USER} undef
otherwise, without sending a 401 back.
Cheers,
--
IT'S TIME FOR A DIFFERENT KIND OF WEB
Jean-Michel Hiver - Software Director
[EMAIL PROTECTED]
+44 (0)114 255 8097
VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
Please check that the idea of this kind of authentication is to encrypt the ticket, instead of a plain session ID. If cookie is not available, having it on URI is a good idea. (Then one needs to have all links in a relative manner; see the Cookbook). Cookie itself does not make a secure session ID or a secure ticket. It is the encryption that does. Peter Bi - Original Message - From: "Jean-Michel Hiver" <[EMAIL PROTECTED]> To: "Randal L. Schwartz" <[EMAIL PROTECTED]> Cc: "Jean-Michel Hiver" <[EMAIL PROTECTED]>; "Andrew Moore" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, June 30, 2002 10:07 AM Subject: Re: Optional HTTP Authentication ? > > What? The EU is going to make cookies *illegal*? I highly doubt > > this. > > Sorry, I am neither the lawyer nor the client, so I can't tell you... > I know it's really stupid, but I am going to have to deal without > cookies. > > > Jean-Michel> * For usability reasons encoding session IDs on URIs would be really > > Jean-Michel> bad... users needs to be able to 'hack' the URIs without f***ing their > > Jean-Michel> sessions! > > > > Why is a user "hacking" their URLs? > > I can answer that. http://www.useit.com/alertbox/990321.html > > > * a domain name that is easy to remember and easy to spell > * short URLs > * easy-to-type URLs > * URLs that visualize the site structure > * URLs that are "hackable" to allow users to move to higher levels of > the information architecture by hacking off the end of the URL > * persistent URLs that don't change > > > i.e. http://bigmegamarket.com/grocery/fruits/bananas/ is cool, > http://bigmegamarket.com/index.pl?id=231223412&sid=56765454151 is not. > > Again it doesn't always make implementation easy :-/ > > > Jean-Michel> Therefore I have to use HTTP authentication... > > > > Even though the user/password is transmitted *in the clear* on > > *every single hit*, because you can't just use a session identifier? > > This is so very wrong from a security perspective. > > I have to agree with you on that. Cookies are probably far better than > HTTP authentication. But I cannot use cookies. Period. I wish I could, > because this was what I did in the first place and it was working fine! > > Cheers, > -- > IT'S TIME FOR A DIFFERENT KIND OF WEB > > Jean-Michel Hiver - Software Director > [EMAIL PROTECTED] > +44 (0)114 255 8097 > > VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
> What? The EU is going to make cookies *illegal*? I highly doubt > this. Sorry, I am neither the lawyer nor the client, so I can't tell you... I know it's really stupid, but I am going to have to deal without cookies. > Jean-Michel> * For usability reasons encoding session IDs on URIs would be really > Jean-Michel> bad... users needs to be able to 'hack' the URIs without f***ing their > Jean-Michel> sessions! > > Why is a user "hacking" their URLs? I can answer that. http://www.useit.com/alertbox/990321.html * a domain name that is easy to remember and easy to spell * short URLs * easy-to-type URLs * URLs that visualize the site structure * URLs that are "hackable" to allow users to move to higher levels of the information architecture by hacking off the end of the URL * persistent URLs that don't change i.e. http://bigmegamarket.com/grocery/fruits/bananas/ is cool, http://bigmegamarket.com/index.pl?id=231223412&sid=56765454151 is not. Again it doesn't always make implementation easy :-/ > Jean-Michel> Therefore I have to use HTTP authentication... > > Even though the user/password is transmitted *in the clear* on > *every single hit*, because you can't just use a session identifier? > This is so very wrong from a security perspective. I have to agree with you on that. Cookies are probably far better than HTTP authentication. But I cannot use cookies. Period. I wish I could, because this was what I did in the first place and it was working fine! Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
> "Jean-Michel" == Jean-Michel Hiver <[EMAIL PROTECTED]> writes: Jean-Michel> * For political reasons and compliance with future european legislation Jean-Michel> I cannot use cookies, What? The EU is going to make cookies *illegal*? I highly doubt this. Jean-Michel> * For usability reasons encoding session IDs on URIs would be really Jean-Michel> bad... users needs to be able to 'hack' the URIs without f***ing their Jean-Michel> sessions! Why is a user "hacking" their URLs? Jean-Michel> Therefore I have to use HTTP authentication... Even though the user/password is transmitted *in the clear* on *every single hit*, because you can't just use a session identifier? This is so very wrong from a security perspective. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Optional HTTP Authentication ?
> It seems that Apache::AuthCookie allows a way to make areas > to which one can authenticate if s/he wants. I suppose that > then in those areas you can tell if the user is logged in > and affect the pages if so. Indeed the best option would be to be using one of the Apache::Session module and use the provided hash to store the login information. I have read the whole portion of the eagle book dedicated to authentication / authorization before posting my crack-smoked question to the list ;-) Unfortunatly: * For political reasons and compliance with future european legislation I cannot use cookies, * For usability reasons encoding session IDs on URIs would be really bad... users needs to be able to 'hack' the URIs without f***ing their sessions! Therefore I have to use HTTP authentication... Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
