Perrin Harkins wrote (in a discussion with Michael L. Artz):
Well, I figured that the AuthenHandler already parsed the
authentication cookie and declared it valid, so I didn't really see
a point the in doing it at the beginning of every script. $r-user
just seemed more intuitive to me.
Perrin Harkins wrote:
Well, I'm not sure what's involved in determining $r-user aside from
reading the cookie. It may not make any difference.
Here's a typical pattern for this:
- Fetch the session key from the validated cookie.
- Load the session using that key.
- Grab the user ID from the
plus proxy), which is kind of popular now, one can
set it up in the light server to protect static content.
Peter
- Original Message -
From: Michael L. Artz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, June 10, 2003 6:47 PM
Subject: Re: Authentication design
Well, sorta. I am
On Wed, 2003-06-11 at 03:32, Frank Maas wrote:
The session stuff could be done in a separate phase before the content
handler, or it could be done on demand when your script calls some
utility method that knows how to get the current session. Same with
the user.
Isn't this more a
On Wed, 2003-06-11 at 08:32, Michael L. Artz wrote:
Not sure that I quite understand ... what do you mean by load the
session/user data if it is being done in a handler before content
phase? What would you use to store the retrieved data ... pnotes?
That's what I've done in the past,
Hmm, I see now. I don't really care about users who aren't logged in,
so I don't know that there is a need to store session data for them.
I guess my pattern is:
within PerlAuthenHandler
-Check to see if there are passed user/password params. If so,
validate params against user/pass in
Jonathan Gardner wrote:
It sounds like you are mixing HTTP-level authentication with
application-level
authentication.
Well, sorta. I am actually using a custom module very similar to the
one found in the cookbook (and AuthCookie, I think), i.e. create a
PerlAuthenHandler that sets the custom
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tuesday 03 June 2003 18:59, Michael L. Artz wrote:
I am trying to design/implement a fairly simple authentication scheme
using cookies and such, but wanted to air my design questions before I
run into too many issues.
It sounds like you are
On Tue, 2003-06-10 at 21:47, Michael L. Artz wrote:
I thought that this was a good way to go since I could protect my entire
application with a single module and a couple lines in the config file,
as opposed to bundling that authentication code into the beginning of
*every* registry script
Perrin Harkins wrote:
I'm not certain it won't work to use $r-user, but I don't see the point
when you already have a unique identifier in the cookie.
Well, I figured that the AuthenHandler already parsed the authentication
cookie and declared it valid, so I didn't really see a point the in
On Tue, 2003-06-10 at 23:43, Michael L. Artz wrote:
Well, I figured that the AuthenHandler already parsed the authentication
cookie and declared it valid, so I didn't really see a point the in
doing it at the beginning of every script. $r-user just seemed more
intuitive to me.
Well, I'm
I am trying to design/implement a fairly simple authentication scheme
using cookies and such, but wanted to air my design questions before I
run into too many issues.
I would like the site to be almost entirely publicly accessible, however
if you log in you get special options in addition to
Hi Michael --
My question basically centers around the best way to protect
the only
if you login pages. I was thinking of putting them in their own
directory and protecting them with a tiny PerlAuthzHandler,
which would
scatter scripts of the same nature in two separate places (i.e.
13 matches
Mail list logo
