I think you want to look at the Apache::AuthCookie module
That will allow you to have a nice HTML screen that forces users to log in.
You can also provide a logout link. You have to provide an algorithm for
generating a cookie for the user and a way to turn the cookie back into a
user id.
Then, you should be able to get the user's id from the $ENV{ REMOTE_USER }
variable. You could use that for a key into Apache::Session.
Brian
-----Original Message-----
From: Puneet Kishor [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 03, 2003 4:02 PM
To: [EMAIL PROTECTED]
Subject: Re: [htmltmpl] securing an H::T site with username/password
w/session mgt1
Thanks to everyone who responded thus far. Really appreaciate your
thoughts and guidance.
Summary follows -- I asked: I have a H::T-based website. How do I
protect it with a username/password? How do I use the login to manage
session until the user logs out?
==============
Kapoor, Nishikant X wrote:
> It may sound a bit strange but I am curious, why do you want > to
protect .tmpl files? I fail to see their usefulness to anyone > in their
current form.
I had a misconception (or rather... I just presumedthat my templates
would reside with my scripts... dunnow why I did that). Hence I asked
how would I protect my .tmpl files.
Well, now that you ask, I really don't know why? There really is no good
reason because there is nothing secret in the templates... except, that
templates, unless filled out, look ugly... images names and paths, and
other variables, that are dynamically generated othewise appear broken, etc.
Anyway, I can simply move the templates to a directory not under the web
root. So, that is solved.
==============
Joel wrote:
> Basically, I have one script control the entire site. All calls to > the
site go through that one script and it handles the checking of > a cookie
on the user's browser. The cookie contains session or > login information
and if it's not there, they get dumped onto the > login screen. If it's
there, they are allowed in. I have the option > of logging out by deleting
the cookie from their browser.
That is one way of doing this... however, it is a bit kludgy because I
end with with a mongo script with all manner of things in it even if
they are logically unrelated. Keeping scripts restricted in their scope
to what they are supposed to do allows me to separate code into
digestible pieces.
==============
Ron Mahoney wrote:
> A question for your issue is, what is your target platform? And, > what
kind of control do you have over it? If you are creating > a generic cgi
script that will be distributed to many people > with different hosting
environments then you're probably stuck > coding the authorization into
your content handlers (probably > something like in a base class for all
your cgi scripts check > for a cookie user_id and verify it).
my bad... I should have specified this upfront -- I am not depending on
mod_perl. I can't. So, it has to be something that will work with
non-mod_perl but ideally should be portable. Which is why I am seeking a
database-query-response-session based solution. I can't even depend on
.htpasswd because that has to be moved around (besides other problems
with it).
===============
Keith Jackson wrote:
> I use Apache::session to do exactly what you are talking about. > You DO
have to have a line or 2 of code at the top of every script > to fetch the
session info but that's not too bad.
so... it seems I _have_ to do this. Now, instead of putting this code at
the top of every script, is there any way to force the server to look at
this code automatically? Like via .htaccess or some such?
And, finally...
any thoughts on Apache::Session vs. CGI::Session from those who might
have tried both?
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Html-template-users mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/html-template-users
------------------------------------------------------------------------------
This message is intended only for the personal and confidential use of the
designated recipient(s) named above. If you are not the intended recipient of
this message you are hereby notified that any review, dissemination,
distribution or copying of this message is strictly prohibited. This
communication is for information purposes only and should not be regarded as
an offer to sell or as a solicitation of an offer to buy any financial
product, an official confirmation of any transaction, or as an official
statement of Lehman Brothers. Email transmission cannot be guaranteed to be
secure or error-free. Therefore, we do not represent that this information is
complete or accurate and it should not be relied upon as such. All
information is subject to change without notice.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Html-template-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/html-template-users
