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 databas
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, al
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 mo
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
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 ses
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 m
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
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 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 scri
-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
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
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 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 th
13 matches
Mail list logo
