html-template-users Mailing List for HTML::Template (Page 69)
Brought to you by:
samtregar
Menu
▾
▴
html-template-users — Discussion of HTML::Template and related modules
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(42) |
Jul
(80) |
Aug
(77) |
Sep
(97) |
Oct
(65) |
Nov
(80) |
Dec
(39) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(63) |
Feb
(47) |
Mar
(45) |
Apr
(63) |
May
(67) |
Jun
(51) |
Jul
(78) |
Aug
(37) |
Sep
(45) |
Oct
(59) |
Nov
(50) |
Dec
(70) |
| 2004 |
Jan
(23) |
Feb
(90) |
Mar
(37) |
Apr
(53) |
May
(111) |
Jun
(71) |
Jul
(35) |
Aug
(58) |
Sep
(35) |
Oct
(35) |
Nov
(35) |
Dec
(20) |
| 2005 |
Jan
(51) |
Feb
(19) |
Mar
(20) |
Apr
(8) |
May
(26) |
Jun
(14) |
Jul
(49) |
Aug
(24) |
Sep
(20) |
Oct
(49) |
Nov
(17) |
Dec
(53) |
| 2006 |
Jan
(12) |
Feb
(26) |
Mar
(45) |
Apr
(19) |
May
(19) |
Jun
(13) |
Jul
(11) |
Aug
(9) |
Sep
(10) |
Oct
(16) |
Nov
(17) |
Dec
(13) |
| 2007 |
Jan
(9) |
Feb
(12) |
Mar
(28) |
Apr
(33) |
May
(12) |
Jun
(12) |
Jul
(19) |
Aug
(4) |
Sep
(4) |
Oct
(5) |
Nov
(5) |
Dec
(13) |
| 2008 |
Jan
(6) |
Feb
(7) |
Mar
(14) |
Apr
(16) |
May
(3) |
Jun
(1) |
Jul
(12) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(9) |
| 2009 |
Jan
(9) |
Feb
|
Mar
(10) |
Apr
(1) |
May
|
Jun
(6) |
Jul
(5) |
Aug
(3) |
Sep
(7) |
Oct
(1) |
Nov
(15) |
Dec
(1) |
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(9) |
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
(3) |
Mar
|
Apr
(28) |
May
|
Jun
|
Jul
(3) |
Aug
(4) |
Sep
(3) |
Oct
|
Nov
(8) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2016 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Ralf U. <rul...@we...> - 2003-09-25 15:16:12
|
hello,
this is my first mail to the list since i began using html::template one
year ago.
i have the following problem:
i have an threaded discussion forum for which I want to use
html::template. I get the guestbook-data via DBi from a MySQL-Server.
I process this data within a recursive function, which calls itself
until no record has any more children. By now I append all html-data with
$html .= $html;
and add it ot html::template as a scalar param ( $t->param('forum_data'
=> $html) and this works fine. but this is bad if you want to style
certain rows in a different way from other rows. But i don't know how to
handle this with TMPL_LOOP, since I never can know, how many children
exist for one parent and how deep this hierarchy will be.
has anyone on this list done something like this and could point me in
the right direction?
Thanks in advance for any help,
Ralf
|
|
From: Wojciech P. <wo...@it...> - 2003-09-25 09:50:19
|
Hi, I have two nested loops. Is there a way to get the value of outer <TMPL_VAR NAME=3D"__counter__"> from inner loop? Thank you in advance, Wojciech Pietro=F1 |
|
From: Sam T. <sa...@tr...> - 2003-09-22 19:39:11
|
On Mon, 22 Sep 2003, Brandon Bowersox wrote: > HTML::Template 2.6 dies with templates stored by Perl as UTF-8 under > perl-5.8.0-88 packaged by RedHat. Again, H::T is victim of buggy Unicode. Don't bother trying to fix HTML::Template, Perl 5.8 is broken by Redhat 8 and 9's default locale settings. Here's the Redhat bug for it: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=87682 One workaround is noted "export LANG=en_US" and I happen to know editing /etc/sysconfig/i18n works just as well. -sam |
|
From: Jeff P. <jp...@gr...> - 2003-09-22 19:18:09
|
Howdy! I had a few spare cycles waiting for another program to complete and started reading about using Perlscript in ASP pages. I tested some code and found that H:T with a template worked just great! :) Then I simply change the code to reference H:T:E instead and the page did not error out, but also did not produce any output - even with the debug statement set "on". I also edited the same code to run as a perl page and had no problems. I was wondering if anyone has ever run into this problem before and if so, how did you remedy this problem? Any thoughts or comments would be most appreciated! Otherwise I will try and devote some time after the end of this month. Thanx, Jeff. PAGE CODE: ============= <%@ LANGUAGE="PERLSCRIPT"%> <% use Win32::ASP; use HTML::Template; ############################################## ## HTML::TEMPLATE::EXPR PRODUCES NO OUTPUT ## ############################################## my $tmpl = HTML::Template->new( filename => 'test-ht.tmpl', path=>['C:/INETPUB/WWWROOT/DEVEL/HTDOCS/TEMPLATES'], die_on_bad_params => 0 , debug => 1 ); $tmpl->param( TEST => '123' ); ##print "Content-type: text/html\n\n", print $tmpl->output; %> HERE IS THE TEMPLATE CODE: ================================ <HTML> <HEAD> <TITLE>Testing <TMPL_VAR NAME="TEST"></TITLE> </HEAD> <BODY> <H3 ALIGN="CENTER">TESTING <TMPL_VAR NAME="TEST">!</H3> </BODY> </HTML> OUTPUT TO BROWSER: ==================== <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=Content-Type content="text/html; charset=windows-1252"></HEAD> <BODY></BODY></HTML> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information, the disclosure of which is governed by applicable law. If the reader of this e-mail is not the intended recipient(s), any unauthorized review, use, disclosure or distribution is prohibited. If you have received this message in error, please contact the sender by reply e-mail and destroy all copies of the original message immediately. |
|
From: Brandon B. <br...@oj...> - 2003-09-22 16:47:54
|
HTML::Template 2.6 dies with templates stored by Perl as UTF-8 under perl-5.8.0-88 packaged by RedHat. Again, H::T is victim of buggy Unicode. The script below causes HTML::Template to die complaining of invalid template syntax. This occurs on RedHat 8.0 (linux 2.4.18-...) and RedHat 9.0 (linux 2.4.20-...). We've worked around it on both RH8.0 and RH9.0 by downgrading to perl-5.8.0-55. This is similar but not a duplicate of the bug discussed here late in 2002: http://www.mail-archive.com/htm...@li.../msg00330.html So I've already got that patch in place: $which = $1; $which = uc($which); ####### reproduce the bug ####### #!/usr/local/bin/perl -w use strict; use HTML::Template; my $template = q(<html>).chr(560).q(<TMPL_VAR NAME=foo></html>); my $ht = HTML::Template->new(scalarRef=>\$template); print "ok 1\n"; ##Another way to get it to die by making sure it's in memory as utf8. #use Encode; #my $template2 = q(<html><TMPL_VAR NAME=foo></html>); #my $decoded2 = Encode::decode('iso-8859-1', $template2); #my $ht2 = HTML::Template->new(scalarRef=>\$decoded2); #print "ok 2\n"; ####### /reproduce the bug ####### Where else can I report this bug? Not to bugzilla.redhat.com because RedHat does not package HTML::Template, right? What about the perl-porters? The script to reproduce the bug causes this die: HTML::Template->new() : Syntax error in <TMPL_*> tag at /fake/path/for/non/file/template : 1. at /usr/lib/perl5/site_perl/5.8.0/HTML/Template.pm line 2243. It's not just H::T that has trouble with RedHat perl-5.8.0-88: http://www.livejournal.com/users/jwz/257602.html http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=102106 Thanks in advance for any help, Bryan Cribbs and Brandon Bowersox (br...@oj...) |
|
From: Emmanuil B. (Manos) <mb...@ne...> - 2003-09-22 15:23:35
|
Sorry for such a basic question... solved without a PPM, just added a folder HTML in ActivePerl/lib then pasted Template in it. Emmanuil Batsis (Manos) wrote: > Hi folks, > > Clueless-on-perl coder here. > > Can someone please give a helping hand by sending over a binary I can > attach to my ActiveState Perl? > > I'm trying to make JSDoc [1] work for Sarissa [2] but have no clue on > Perl modules and such. Any help or pointers much appreciated. > > [1] http://sourceforge.net/projects/jsdoc > [2] http://sourceforge.net/projects/sarissa/ > -- Manos Batsis _ __ __ __ / |/ /__ / /____ __ _ ___ _____/ /_ / / -_) __(_-</ ' Y _ `/ __/ __/ /_/|_/\__/\__/___/_/_/_|_,_/_/ \__/ http://www.netsmart.gr mbatsis at netsmart dot gr (+30) 210 33 02 608 (+30) 210 33 02 658 http://forte.netsmart.gr/foaf/manos_foaf.rdf |
|
From: Emmanuil B. (Manos) <mb...@ne...> - 2003-09-22 13:56:14
|
Hi folks, Clueless-on-perl coder here. Can someone please give a helping hand by sending over a binary I can attach to my ActiveState Perl? I'm trying to make JSDoc [1] work for Sarissa [2] but have no clue on Perl modules and such. Any help or pointers much appreciated. [1] http://sourceforge.net/projects/jsdoc [2] http://sourceforge.net/projects/sarissa/ -- Manos Batsis _ __ __ __ / |/ /__ / /____ __ _ ___ _____/ /_ / / -_) __(_-</ ' Y _ `/ __/ __/ /_/|_/\__/\__/___/_/_/_|_,_/_/ \__/ http://www.netsmart.gr mbatsis at netsmart dot gr (+30) 210 33 02 608 (+30) 210 33 02 658 http://forte.netsmart.gr/foaf/manos_foaf.rdf |
|
From: Philip S T. <phi...@gm...> - 2003-09-21 14:03:00
|
Is anyone maintaining an RPM of HTML::Template? If not, well, I've built an RPM for RH7.3/perl 5.6.1 if anyone wants it. The spec file can be used to build further rpms. Philip -- I had no shoes and I pitied myself. Then I met a man who had no feet, so I took his shoes. -- Dave Barry |
|
From: Philip S T. <phi...@gm...> - 2003-09-16 03:25:17
|
On Mon, 15 Sep 2003, Thomas Charron wrote:
> Here is whats happening. It seems WHENEVER I pass loop_context_vars =>
> 1 in the new, I get this:
>
> [Mon Sep 15 17:38:18 2003] [error] [client 192.168.0.204] [Mon Sep 15
> 17:38:18 2003] WebApp.pl: Error executing run mode 'usermainpage':
> HTML::Template->output() : fatal error in loop output : Can't use string
> ("1") as a HASH ref while "strict refs" in use at
You may have your own variables named __first__, __last__, __odd__ or
__inner__ which are clashing with HTML::Template's. One of these is
being used as a loop I suppose.
Philip
--
My Bonnie looked into a gas tank,
The height of its contents to see!
She lit a small match to assist her,
Oh, bring back my Bonnie to me.
|
|
From: Karen J. C. <si...@ph...> - 2003-09-15 23:39:36
|
On Mon, 15 Sep 2003, Karen J. Cravens wrote:
KJC>As is usual, I discovered this only *after* posting the question to the
KJC>list...
And after that, I realized things still aren't working quite right.
It's not the loop variables, though. It's the nested loop.
I've got globals turned on. If I've got something like this:
<TMPL_LOOP A>
<TMPL_VAR able>
<TMPL_VAR alpha>
<TMPL_LOOP B>
<TMPL_VAR baker>
<TMPL_VAR bravo>
<TMPL_VAR able>
<TMPL_VAR alpha>
...
(with a parameter being passed an appropriately-nested array),
able shows up in both loops. If I change it to this:
<TMPL_LOOP A>
<TMPL_VAR alpha>
<TMPL_LOOP B>
<TMPL_VAR baker>
<TMPL_VAR bravo>
<TMPL_VAR able>
<TMPL_VAR groupname>
abel won't show up, alpha will.
--
Karen J. Cravens si...@ph...
|
|
From: Karen J. C. <si...@ph...> - 2003-09-15 22:24:45
|
On Sun, 14 Sep 2003, Sam Tregar wrote: ST>Have you tried turning off global_vars? Does that solve the problem ST>with __first__? What version of HTML::Template are you using? Turned out it wasn't the version of HTML::Template, exactly, but the version of Perl. I hadn't tried turning off global_vars, but I was using __FIRST__ (not __first__) and case-sensitivity. I was reading the docs from one version of Perl (with, yes, an older HTML::Template) and executing under a different one (whatever the most current one on CPAN is). As is usual, I discovered this only *after* posting the question to the list... -- Karen J. Cravens si...@ph... |
|
From: Thomas C. <tch...@du...> - 2003-09-15 21:51:55
|
Ok, I've now pulled my hair out..
I'm using HTML::Template for the first time, I've always done it using
my own custom rolled template system from way back.
Here is whats happening. It seems WHENEVER I pass loop_context_vars =3D=
>
1 in the new, I get this:
[Mon Sep 15 17:38:18 2003] [error] [client 192.168.0.204] [Mon Sep 15
17:38:18 2003] WebApp.pl: Error executing run mode 'usermainpage':
HTML::Template->output() : fatal error in loop output : Can't use string
("1") as a HASH ref while "strict refs" in use at
C:/Perl/site/lib/HTML/Template.pm line 2894., referer:
http://hppav/hhomes/WebApp.pl?rm=3Dmenu
[Mon Sep 15 17:38:18 2003] [error] [client 192.168.0.204] [Mon Sep 15
17:38:18 2003] WebApp.pl: at WebApp.pm line 261, referer:
http://hppav/hhomes/WebApp.pl?rm=3Dmenu
my $template =3D HTML::Template->new(filename =3D> 'usermainpage.tmpl=
',
loop_context_vars =3D> 1, die_on_bad_params =3D> 0); is what I use to
create it. Removing the die_on_bad_params option causes everything to
work fine. I know, I'm prolly just running on not enough sleep, but..
Am *I* doing anything wrong here?
|
|
From: Ben A. <Ben...@na...> - 2003-09-15 08:30:03
|
>=20 > I've got a __first__ that isn't acting the way I expect it...=20 > it's always false. I'm wondering if that's happening because=20 > I've got global_vars on and it's the inner loop of a two-loop nest. You are setting loop_context_vars, aren't you? Ben |
|
From: Sam T. <sa...@tr...> - 2003-09-15 03:51:49
|
On Sat, 13 Sep 2003, Karen J. Cravens wrote: > I've got a __first__ that isn't acting the way I expect it... it's always > false. I'm wondering if that's happening because I've got global_vars on > and it's the inner loop of a two-loop nest. > > I'm betting it is, but I'm hoping someone will tell me I'm wrong, because > I'd really like to leave global_vars on, and I'd really like to use > __first__... Have you tried turning off global_vars? Does that solve the problem with __first__? What version of HTML::Template are you using? -sam |
|
From: Karen J. C. <si...@ph...> - 2003-09-13 22:06:16
|
I've got a __first__ that isn't acting the way I expect it... it's always false. I'm wondering if that's happening because I've got global_vars on and it's the inner loop of a two-loop nest. I'm betting it is, but I'm hoping someone will tell me I'm wrong, because I'd really like to leave global_vars on, and I'd really like to use __first__... -- Karen J. Cravens si...@ph... |
|
From: Ron M. <rma...@in...> - 2003-09-03 21:46:01
|
On Wed, Sep 03, 2003 at 04:09:22PM -0500, Karen J. Cravens wrote:
> On Wed, 3 Sep 2003, Ron Mahoney wrote:
>
> RM>On the other hand if you are coding for a mod_perl enabled server that you have
> RM>full control over then I would recommend you take a look at
> RM>Apache::AuthCookieDBI ( a subclass of Apache::AuthCookie ). You can either use
> RM>it directly or as a model for how to code the authentication and authorization
> RM>phases of Apache. Once that's setup and working all you have to do is drop in
> RM>.htaccess files in whatever directory you want protected (or put it in the
> RM>Directory section in your httpd.conf) and say what groups or users are
> RM>authorized to run these scripts.
>
> I'm in the process of setting up a new (well, replacement) server and was
> thinking about playing with Apache::AuthCookieDBI/mod_auth_cookie_mysql,
> but if somebody can answer my question it'll save me some experimentation.
>
> What *I* need is something like Puneet's setup, except that I don't need
> sessions, per se, just the ability to log out (which is just a matter of
> expiring the cookie, in this case). But what I'm not finding in any of
> the documentation is whether it's possible to configure a critter such
> that it doesn't *demand* authentication. That is, if the cookie's there,
> Apache will authenticate and pass it on in the environment, but if it's
> not, it'll still allow access to the file (or in my case, script).
>
> ObHTML::Template: All the scripts being granted access to will use
> HTML::Template, except the wiki, and I'm seriously considering rewriting
> TWiki so that *it* uses H::T too.
>
> --
> Karen J. Cravens si...@ph...
>
>
Yes, I think I get what you're after - ~if~ the user logged in you can get the id
from $ENV{REMOTE_USER} and then get their information to do something like say
"Hello Tom" on the unprotected page or "Please Login" if they have not passed
any credentials (via the cookie or whatever mechanism). Yes you can do this in
Apache::AuthCookie with a call to Apache::AuthCookie::recognize_user as a
PerlFixupHandler and make sure that the cookie path is set to '/' (PerlSetVar
WhatEverPath / in httpd.conf).
--
Ron Mahoney
Ra Security Systems, Inc.
rma...@ra...
908-534-6004 x21
|
|
From: Paulsen, B. <BPa...@le...> - 2003-09-03 21:35:12
|
Yes, I believe that Apache::AuthCookie supports that as well. -----Original Message----- From: Karen J. Cravens [mailto:si...@ph...] Sent: Wednesday, September 03, 2003 5:09 PM To: htm...@li... Subject: Re: [htmltmpl] securing an H::T site with username/password w/session mgt1 On Wed, 3 Sep 2003, Ron Mahoney wrote: RM>On the other hand if you are coding for a mod_perl enabled server RM>that you have full control over then I would recommend you take a RM>look at Apache::AuthCookieDBI ( a subclass of Apache::AuthCookie ). RM>You can either use it directly or as a model for how to code the RM>authentication and authorization phases of Apache. Once that's setup RM>and working all you have to do is drop in .htaccess files in whatever RM>directory you want protected (or put it in the Directory section in RM>your httpd.conf) and say what groups or users are authorized to run RM>these scripts. I'm in the process of setting up a new (well, replacement) server and was thinking about playing with Apache::AuthCookieDBI/mod_auth_cookie_mysql, but if somebody can answer my question it'll save me some experimentation. What *I* need is something like Puneet's setup, except that I don't need sessions, per se, just the ability to log out (which is just a matter of expiring the cookie, in this case). But what I'm not finding in any of the documentation is whether it's possible to configure a critter such that it doesn't *demand* authentication. That is, if the cookie's there, Apache will authenticate and pass it on in the environment, but if it's not, it'll still allow access to the file (or in my case, script). ObHTML::Template: All the scripts being granted access to will use HTML::Template, except the wiki, and I'm seriously considering rewriting TWiki so that *it* uses H::T too. -- Karen J. Cravens si...@ph... ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Html-template-users mailing list Htm...@li... 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. |
|
From: Karen J. C. <si...@ph...> - 2003-09-03 21:09:57
|
On Wed, 3 Sep 2003, Ron Mahoney wrote: RM>On the other hand if you are coding for a mod_perl enabled server that you have RM>full control over then I would recommend you take a look at RM>Apache::AuthCookieDBI ( a subclass of Apache::AuthCookie ). You can either use RM>it directly or as a model for how to code the authentication and authorization RM>phases of Apache. Once that's setup and working all you have to do is drop in RM>.htaccess files in whatever directory you want protected (or put it in the RM>Directory section in your httpd.conf) and say what groups or users are RM>authorized to run these scripts. I'm in the process of setting up a new (well, replacement) server and was thinking about playing with Apache::AuthCookieDBI/mod_auth_cookie_mysql, but if somebody can answer my question it'll save me some experimentation. What *I* need is something like Puneet's setup, except that I don't need sessions, per se, just the ability to log out (which is just a matter of expiring the cookie, in this case). But what I'm not finding in any of the documentation is whether it's possible to configure a critter such that it doesn't *demand* authentication. That is, if the cookie's there, Apache will authenticate and pass it on in the environment, but if it's not, it'll still allow access to the file (or in my case, script). ObHTML::Template: All the scripts being granted access to will use HTML::Template, except the wiki, and I'm seriously considering rewriting TWiki so that *it* uses H::T too. -- Karen J. Cravens si...@ph... |
|
From: Paulsen, B. <BPa...@le...> - 2003-09-03 20:13:06
|
Yeah, what he said :) -----Original Message----- From: mo...@ha... [mailto:mo...@ha...] Sent: Wednesday, September 03, 2003 3:28 PM To: Puneet Kishor Cc: Ragan, Steve; htm...@li... Subject: Re: [htmltmpl] securing an H::T site with username/password w/ses sion mgt1 mod_perl is really the best tool for this. -- Bill Moseley mo...@ha... ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Html-template-users mailing list Htm...@li... 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. |
|
From: Paulsen, B. <BPa...@le...> - 2003-09-03 20:11:44
|
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:pk...@ei...]
Sent: Wednesday, September 03, 2003 4:02 PM
To: htm...@li...
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 Htm...@li...
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.
|
|
From: Ron M. <rma...@in...> - 2003-09-03 20:07:20
|
On Wed, Sep 03, 2003 at 02:03:14PM -0500, Puneet Kishor wrote: > Puneet Kishor wrote: > > oh... and another problem with .htaccess I forgot to mention -- > > once you are in, you are in for everything. So, as I mentioned in my > original query -- "How do I prevent the user from going directly to > mywebsite/foo.tmpl or whatever else? " <<sorry replied off list>> Not true. You are in for the Authorization Realm (AuthName in .htaccess) as long as the credentials are valid and in the valid user or group list. In other words the browser now conveniently presents the userid/password with each request instead of prompting you with its dialog. They are still verified with each request. The problems with Basic Auth are the classic issues of "you cannot log out" and "you get the ugly browser login dialog." 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). On the other hand if you are coding for a mod_perl enabled server that you have full control over then I would recommend you take a look at Apache::AuthCookieDBI ( a subclass of Apache::AuthCookie ). You can either use it directly or as a model for how to code the authentication and authorization phases of Apache. Once that's setup and working all you have to do is drop in .htaccess files in whatever directory you want protected (or put it in the Directory section in your httpd.conf) and say what groups or users are authorized to run these scripts. -- Ron Mahoney Ra Security Systems, Inc. rma...@ra... 908-534-6004 x21 |
|
From: Puneet K. <pk...@ei...> - 2003-09-03 19:59:25
|
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? |
|
From: Keith J. <kja...@ey...> - 2003-09-03 19:37:05
|
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. To keep people from see your .tmpl files simply put them outside the docroot. On our server our standard configuration is to have docroot, cgi-bin, and templates at the same level. In the when I create a template object I point to the template directory to search for the template. HTH. On Wed, 2003-09-03 at 14:23, Puneet Kishor wrote: > Phew! that was mouthful. > > Folks, I am running around in circles trying to comprehend what must be > basics for most of you. > > Having built a fine H::T based website and been singing praises of this > fine module, I want to now put it all behind a username/password login > with session mgt. > > I have gotten my mind suitably confused reading docs on Apache security, > CGI::Session, Apache::Session, and scores of articles on various > websites. Needless to say, I haven't yet figured out the simplest, > easiest way to accomplish the following -- > > on going to my website, the user should be presented with a login form. > On successful login, the user's information should be retrieved from a > database (let's assume MySQL here)... this could be a load of info such > as preferences, various application settings, etc. These pieces of > user-specific information should be stored in a session structure so I > may use it throughout the user's session until the user logs out. On > logging out, the last state should be saved back to the database and the > session should be cleared. > > I am assuming that the script that does the checking whether the user is > logged in or not has to somehow be connected with .htaccess so that it > may run everytime... I don't know how to do that. How do I prevent the > user from going directly to mywebsite/foo.tmpl or whatever else? > > I know this is asking for a basic course in creating a password > protected website -- if someone could provide a link to such an article > (esp. if it deals with H::T-specific issues, if any -- for example, > .tmpl files are not cgi scripts, so how could they be protected, etc.) > that would be great. > > Many thanks. > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Html-template-users mailing list > Htm...@li... > https://lists.sourceforge.net/lists/listinfo/html-template-users -- Keith Jackson <kja...@ey...> |
|
From: Joel <htm...@jo...> - 2003-09-03 19:35:03
|
Hi Puneet,
Although I haven't used any of the *::Session modules, I thought I would give
you a brief idea of how I've done things in the past.
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.
The catch is that EVERYTHING goes through that one script. There are no static
HTML files on disk at all. It works well enough for what we are using it for.
URLs are ugly and look something like:
admin.pl?sec=foo&act=bar&name=this&value=that
(as a note, our template files are kept outside of the docs directory, so
people can't do http://site.com/template-file.tmpl to read our templates. No
one ever said your template has to be in your documentroot.)
But what you are asking is different and may sound terribly complicated at
first: how do you check a login before apache returns a static HTML file.
If you step back, the real question is how would you prevent someone from
successfully requesting foo.html when they aren't logged in? Normally, Apache
gets the request and returns the file. Simple as that. No CGI script will be
run to check someone's login. (I don't know how any of the *::Session modules
work, however.) But there's really more to it than that.
My understanding is that you could use mod_perl to insert a handler into the
Apache process to check someone's login before Apache would be told/allowed to
return the page. It's certainly possible, however it might be outside of your
realm of knowledge. It's only barely within the realm of my knowledge.
There may also be some Apache::* modules that might help with this, but again,
we're talking mod_perl, not old-fashioned CGI scripting.
Does anyone have any other ideas? Did I completely miss the question?
How sad it is. The more you know, the more you realize you don't know. ;) The
learning never ends....
Good luck!
--Joel
>Phew! that was mouthful.
>
>Folks, I am running around in circles trying to comprehend what must be
>basics for most of you.
>
>Having built a fine H::T based website and been singing praises of this
>fine module, I want to now put it all behind a username/password login
>with session mgt.
>
>I have gotten my mind suitably confused reading docs on Apache security,
>CGI::Session, Apache::Session, and scores of articles on various
>websites. Needless to say, I haven't yet figured out the simplest,
>easiest way to accomplish the following --
>
>on going to my website, the user should be presented with a login form.
>On successful login, the user's information should be retrieved from a
>database (let's assume MySQL here)... this could be a load of info such
>as preferences, various application settings, etc. These pieces of
>user-specific information should be stored in a session structure so I
>may use it throughout the user's session until the user logs out. On
>logging out, the last state should be saved back to the database and the
>session should be cleared.
>
>I am assuming that the script that does the checking whether the user is
>logged in or not has to somehow be connected with .htaccess so that it
>may run everytime... I don't know how to do that. How do I prevent the
>user from going directly to mywebsite/foo.tmpl or whatever else?
>
>I know this is asking for a basic course in creating a password
>protected website -- if someone could provide a link to such an article
>(esp. if it deals with H::T-specific issues, if any -- for example,
>..tmpl files are not cgi scripts, so how could they be protected, etc.)
>that would be great.
>
>Many thanks.
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Html-template-users mailing list
>Htm...@li...
>https://lists.sourceforge.net/lists/listinfo/html-template-users
>
|
|
From: <mo...@ha...> - 2003-09-03 19:30:10
|
On Wed, Sep 03, 2003 at 02:08:55PM -0500, Puneet Kishor wrote: > I have read a fair amount of Apache docs and tutorials, as well as docs > for various CPAN modules... the closest "tutorial" for doing what I want > was on CGI::Session::Cookbook, but that calls for the security > subroutine to be called at the top of every script in the directory. I > would like this to be done automagically for every file in the directory > and all the subdirectories, etc. Look at Apache::AuthCookie for use with mod_perl. If working under CGI you will have to have some common code that's run for all requests. SpeedyCGI might also be worth looking at to avoid loading your scripts at each request. > I guess what I am looking for is whether it is possible to call a perl > script from within .htaccess (and whether that is even a correct way of > doing this), and how I can protect my templates (.tmpl) files. I've never used Apache's "Action" directive, but maybe that might be helpful. Perhaps a central script could deal with the session and then look at the rest of the path to determine what code to then load and run. mod_perl is really the best tool for this. -- Bill Moseley mo...@ha... |
17 messages has been excluded from this view by a project administrator.
