On Mon, 11 Oct 1999, Ofer Inbar wrote:
Eugene Sotirescu [EMAIL PROTECTED] wrote:
[...snipped...]
When a browser session comes in without appropriate authentication
cookies, they get a login screen. When they post username and
password, check that against the locally stored user table, and
Gunther Birznieks [EMAIL PROTECTED] wrote:
On Mon, 11 Oct 1999, Ofer Inbar wrote:
Eugene Sotirescu [EMAIL PROTECTED] wrote:
[...snipped...]
When a browser session comes in without appropriate authentication
cookies, they get a login screen. When they post username and
password,
--- "Randal L. Schwartz" [EMAIL PROTECTED] wrote:
I was actually looking at a PerlTransHandler that I'd drop into
my site-wide files that would do something like the following:
my $uri = $r-uri;
if ($uri =~ s#/@@(\d+)@@/#/#) {
$session = $1;
$r-uri($uri);
On Sun, Oct 10, 1999 at 12:34:56AM -0700, Randal L. Schwartz wrote:
"Jeffrey" == Jeffrey W Baker [EMAIL PROTECTED] writes:
Jeffrey Cookies are an acceptable way to make the browser remember
Jeffrey something about your site.
Speak for yourself. I'd change that to "... one possible way
"Jeffrey" == Jeffrey W Baker [EMAIL PROTECTED] writes:
Jeffrey Randal, how do you suppose that HTTP basic auth works? The
Jeffrey user agent stores the username and password and transmits
Jeffrey them to the server on every request.
The difference between a cookie and a basic-auth password is
"John" == John D Groenveld [EMAIL PROTECTED] writes:
John Well if you're going to generate your HTML on the fly, URL mangling
John isn't too bad. HTML::Mason and probably the other embedded perl modules
John would allow you to more selectively and consistently place session id
John into your
"Jamie O'Shaughnessy" [EMAIL PROTECTED] writes:
On 11 Oct 99 15:05:23 +0100, you wrote:
I was actually looking at a PerlTransHandler that I'd drop into
my site-wide files that would do something like the following:
my $uri = $r-uri;
if ($uri =~ s#/@@(\d+)@@/#/#) {
Dave Hodgkinson writes:
"Jamie O'Shaughnessy" [EMAIL PROTECTED] writes:
On 11 Oct 99 15:05:23 +0100, you wrote:
I was actually looking at a PerlTransHandler that I'd drop into
my site-wide files that would do something like the following:
my $uri = $r-uri;
Michael Peppler [EMAIL PROTECTED] writes:
Don't use the IP address. Some proxy systems have a non-static IP
address for requests coming from the same physical client (some of
AOLs proxies work that way, if I remember correctly...)
"...or something..." ;-)
--
David Hodgkinson, Technical
Dave Hodgkinson [EMAIL PROTECTED] wrote:
Michael Peppler [EMAIL PROTECTED] writes:
Don't use the IP address. Some proxy systems have a non-static IP
address for requests coming from the same physical client (some of
AOLs proxies work that way, if I remember correctly...)
"...or
Eugene Sotirescu [EMAIL PROTECTED] wrote:
I'd like to authenticate users via a login form (username, password
text fields) instead of using the standard dialog box a browser pops
up in response to a 401 response code.
Here's what I do in an application I'm currently working on...
Application
"Jeffrey" == Jeffrey W Baker [EMAIL PROTECTED] writes:
Jeffrey Cookies are an acceptable way to make the browser remember
Jeffrey something about your site.
Speak for yourself. I'd change that to "... one possible way ..." instead
of "acceptable way", and add "... for a single session".
The point that should be taken is that if one must use a cookie for auth,
expire it early and often. What would _really_ be nice is if there were
a javascript or ecmascribble or whatever it's called object that can _set_
or _unset_ the auth request headers so one _could_ do a form driven
On Sun, 10 Oct 1999, Spidaman The Defenestrator wrote:
[...snip...]
But I digress. Go ahead, use cookies and mangle them into auth headers
but make sure they aren't persistent cookies. And don't use this level of
security for banking or commerce; those get mangled URL paths. In a self
"Randal L. Schwartz" wrote:
"Jeffrey" == Jeffrey W Baker [EMAIL PROTECTED] writes:
Jeffrey Cookies are an acceptable way to make the browser remember
Jeffrey something about your site.
Speak for yourself. I'd change that to "... one possible way ..." instead
of "acceptable way", and
Andrew McNaughton wrote:
Gunther Birznieks [EMAIL PROTECTED] wrote:
[2] Mangled URL Paths
Isn't it possible to browse the history on the harddrive... so is this
really more secure than non-persistent cookies?
Relying on browser based client side expiration is not a good idea, either
Spidaman The Defenestrator wrote:
The point that should be taken is that if one must use a cookie for auth,
expire it early and often. What would _really_ be nice is if there were
a javascript or ecmascribble or whatever it's called object that can _set_
or _unset_ the auth request headers
Many thanks to all who replied.
1. I think I can summarize the responses so far as boiling down to how I
do session management (hidden fields, URL mangling, cookies) and that I
will have to develop my own authentication mechanism.
(The reason I hoped there might be a solution using Apache's
I'd like to authenticate users via a login form (username, password text
fields) instead of using the standard dialog box a browser pops up in
response to a 401 response code.
Can this be done while still using Apache's authentication mechanism?
I understand that authentication happens in 2
19 matches
Mail list logo
