Re: Doing Authorization using mod_perl from a programmers perspective
Jon Robison wrote: The most relevant section for you is the Ticket system he describes. (I believe the section header says something about Cookies, but you'll know you have the right one when you see TicketAccess.pm, TicketTools.pm, and TicketMaster.pm. One nice addition is the ability to add encryption to the Ticket, and the fact that the author used an MD5 hash (of an MD5 hash!) in the cookie, so verification of the authenticity of the user is pretty solid so long as you leave in things like ip address, etc. which he uses in the cookie by default. (Although AOL and some proxy systems might cause this to be trouble). AND, he also uses a mysql db for the i have found that using the HTTP_USER_AGENT environment variable instead of ip address solves the problem with proxy servers and the md5 hash. anyone ever tried this as a simple workaround?
Re: Doing Authorization using mod_perl from a programmers perspective
Joe Breeden wrote: How does this work in an environment with two (or more) computers with the exact same configuration, and probably the same HTTP_USER_AGENT behind the same proxy? How do you know that one user isn't using another users session? you don't. the session hijacker still would need to know the real user's username, password, and HTTP_USER_AGENT configuration. my point was that this solves the problem of using the ip address in the md5 hash when the client is behind a proxy server.
Re: Tips tricks needed :)
[EMAIL PROTECTED] wrote: 1. Regarding the switch to postgresql, I think that's a good choice. Just pay attention to postgresql's data types, and try to get your fields types and lengths correct the first time if possible. It doesn't completely support the ALTER TABLE command, so changing column types can be a pain, although it's still possible. The other thing is that SQL syntax might be slightly different in a few cases, though it's been too long since I used MySQL to remember any examples. Postgresql's web site has some tips for switching, I think at http://techdocs.postgresql.org. something i'll add to that - if your new postgresql db will have foreign keys, and you previously didn't have any code written to guarantee your data's integrity in mysql, then you probably won't be able to import all your data without some massaging (unless you're sure your data's integrity is ok). i wholeheartedly second wes' statement that switching to postgresql is a good choice.
Re: [OT] Moving WYPUG
Jonathan M. Hollin wrote:
I now need to install some Perl modules (DBD-MySql, Image-Magick, etc).
Under ActivePerl on WYPUG's current Win2K box, I would simply use the
Perl Package Manager (PPM) to download and install these modules. Is
there an equivalent under Unix? If not, what's the best way to install
modules? In short, what do I need to know?
A step-by-step guide would be great (I'm a 100% Unix newbie), but I
would also be extremely grateful for pointers to the relevant docs,
URI's, etc.
i'll toss in my $0.02 here - if you're running redhat, you can use
makerpm.pl to generate rpm's from your cpan source code. i use this all
the time and have never had a problem.
http://www.perl.com/cs/user/query/q/6?id_topic=61
the version of makerpm.pl you find may not work with rpm version 4.0 or
higher, this will fix that:
572c572
} elsif ($rpm_version =~ /rpm\s+version\s+3\.+/i) {
---
} elsif ($rpm_version =~ /rpm\s+version\s+3|4\.+/i) {
Re: Apache::Registry question
Kirk Rogers wrote: How do i configure the httpd.conf file to maintain two different cgi-bin directories with Apache::Registry? Not sure if I'm asking the question correctly so here's a quick explanation. I have two cgi-bin directories under one Virtual host: this way works for me: VirtualHost 1.2.3.4 ServerAdmin [EMAIL PROTECTED] DocumentRoot /path/to/doc/root ServerName www.whatever.com ServerAlias whatever.com ScriptAlias /cgi-bin/ /path/to/cgi-bin/ Directory /path/to/cgi-bin AllowOverride None Options ExecCGI Order allow,deny Allow from all SetHandlerperl-script PerlHandler Apache::Registry /Directory Directory /path/to/some/other/cgi-bin AllowOverride AuthConfig Options ExecCGI Order allow,deny Allow from all Files somefile.cgi AuthName Restricted Area AuthType Basic AuthUserFile /path/to/users/file require valid-user SetHandlerperl-script PerlHandler Apache::Registry /Files /Directory /VirtualHost
Re: the cookbook review on perl.com
Jon Robison wrote: No it is not. It should read not so great if you need your hands held. i think he was referring to the fact that you spelled grammar incorrectly.
Re: RPM for apache/mod_perl/mod_ssl
Fran Fabrizio wrote: We're currently struggling for an easy way to distribute our apache/mod_perl/mod_ssl-based application to our data center folks who are in a different state and whom we must presume know nothing about apache, mod_perl or mod_ssl and are capable of nothing more complicated than using RPM to install/update a package. As such, does there exist such a thing as an RPM that installs apache with mod_perl AND mod_ssl enabled? I presume this would also have to include openssl. I can only imagine what a pain it would be to create this beast, but if it's been done, I'd like to give it a try. what o/s and version are you running? i have an rpm for apache 1.3.22, mod_perl 1.26, and mod_ssl 2.8.5 that i run on redhat 6.2. i'd be glad to give you the .src (or the .rpm if you also run redhat 6.2) if you would like it. or, i could just give you the .spec if you'd like to build a new rpm with the latest versions.
Re: RPM for apache/mod_perl/mod_ssl
Fran Fabrizio wrote: In the spirit of the teach a man to fish proverb (sorry if that's a random reference), maybe I should really be asking what's involved in making such an rpm? Is it a case of just figuring out which files are installed by openssl/mod_ssl/mod_perl/apache and making a big ole spec file, or is there some configuration magic that needs to happen? If this is straying too far off-topic I'll take the discussion off-list, but I really should learn how to do this properly for myself. it probably is ot, so i'll make this short. a good place to start is http://www.rpm.org/max-rpm/
Re: Sending Mail
Jon Robison wrote: Can MIME::Lite do attachments? yes, it can. install it, then read perldoc MIME::Lite for info on how.
Re: Perl Configured VirtualHost question
On Wed, 30 Oct 2002 at 02:24, [EMAIL PROTECTED] opined:
:Typically my manually configured vhosts look like this :
:
:NameVirtualHost 10.0.0.20:80
:
:VirtualHost 10.0.0.20:80
: ServerName BladeBla.com
: DocRoot
: ...
: ...
:/VirtualHost
:VirtualHost 10.0.0.20:80
:...
:/VirtualHost
:
:This works great for my statically configured hosts. How
:do you accomplish this same VHost scheme wheh configuring
:via perl? Each %VirtualHost key is a single server and I
:am so far unable to assign multiple values ( array ref? )
:to a single key (the IP assigned in NameVirtualHost).
do you have the eagle book? how to do this is documented on page 418.
you are correct, use an array ref, with each value being a hash ref, one
for each virtual host:
my @config = (
{ ServerName = 'one.fish.net',
ServerAdmin = '[EMAIL PROTECTED]',
etc },
{ ServerName = 'red.fish.net',
ServerAdmin = '[EMAIL PROTECTED]',
etc }
);
$VirtualHost{'192.168.2.5'} = \@config;
Re: [OT] use http-equiv to refresh the page
On Tue, 5 Nov 2002 at 22:52, Chris Shiflett opined: [snip] CS:The W3C's stance on refresh is the same for the header as well as the CS:meta tag: they did not originally intend for it to be used to specify a CS:*different* URL as a rudimentary method of redirection. They meant it to CS:be used to refresh the current resource only. However, this rogue CS:practice of redirection is quite common with both the header and the CS:meta tag and is very well supported by browsers. In fact, I am not aware CS:of any Web client that supports refresh but also limits the URL to the CS:current resource only. i was bitten by this assumption recently. case in point: i needed to develop a way to display several images as a slideshow using plain html files. i would glob the images, and in each html file i inserted a meta refresh that would load the next image in the series after a 7 second delay. since the html files were eventually going to be burned to a cd, i had to point to each new file as such: meta http-equiv=refresh content=7;file02.html because i cannot always assume to know the user's cd-rom drive designation. this worked fine in netscape and mozilla, but did not work at all in internet explorer versions previous to 5.5. in older versions of ie, it simply refreshed the current page after the 7 second delay, no matter what was put after the semicolon in the content attribute. so i had to include instructions for the users that if they used internet explorer, they must upgrade to at least version 5.5 for the slideshow to work. of course, i had tested the app on ie 5.5, so i didn't discover this myself until a user contact me and complained the slideshow wasn't working. and you'd be surprised how many old versions of ie are being used out there.
