Re: 'PerlSetVar' error, please help
--- Dead Line [EMAIL PROTECTED] wrote: Hello Everyone, Im on FreeBSD 4.8R Fresh installation, I have apache-fp, installed and running, I installed p5-Apache-ASP-2.51 from /ports collection, installation was ../www/.htaccess: Invalid command 'PerlSetVar', perhaps mis-spelled or defined by a module not included in the server configuration I don't know what's Apache-ASP - never used it. However, the above error message means u've not enabled mod_perl. If your httpd binary is statically built, then httpd -l should show you an entry for mod_perl. Otherwise, make sure you have an AddModule for mod_perl.so in your httpd configuration. Sreeji Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/
Re: mp2: architectural question re authentication handlers
Quoting Carl Brewer [EMAIL PROTECTED]: Forgive me for asking yet another fundamentally basic question. I'm cutting a web app over from PHP to mod_perl 2, and am wondering how 'best' (for which there are many flavours ...) to handle authentication. At present I've knocked up a site that does auth via a form and state tracking with Session.pm. The form checks usernames passwords against a MySQL database, and the state is maintained by Session. This seems quite logical to me, coming from essentially a CGI background, but the discussion of handlers around here makes me believe there's a better way? I would highly recommend the Eagle book if you are looking to move beyond CGI when using mod_perl. I know that you are looking at mod_perl2, and the Eagle book does not cover mod_perl2, but it will give you great insight into how mod_perl and Apache works. And lucky for you, since you are interested in Authentication and Authorization, that chapter happens to be available online. http://modperl.com:9000/book/chapters/ch6.html Also checkout the great documentation available at http://perl.apache.org/ If you want a good example of how to implement Authentication and Authorization in mod_perl, then look on CPAN for the man Apache::Auth* modules. I have used Apache::AuthCookie in many projects and it has relatively good documentation. You will also find tonnes of info on Authentication if you search the mailing list archives. I see threads here discussing the use of handlers, which I don't really understand how they fit into the picture, they seem to my poor understanding to be a hardcoded chunk in httpd.conf, for handling authentation/state. Is there anywhere a dumb beginers guide to how this works? The easiest way to explain it is to just look at Apache's Basic Authentication support at first. The one where the browser pops up a window and you type in your username and password, and Apache authenticates the user for you before it will allow the CGI script to be executed or the html file to be downloaded. You configure that in httpd.conf or in .htaccess files, telling Apache who has access to specific files and directories. This is just your standard access control stuff. Now imagine that you can use that same core functionality in Apache, but write the routines yourself in perl. And instead of the ugly login popup you can instead create an HTML login page. Do they set environment variables or something that a script can then look for that the script can be sure is legit? Yes, they set the HTTP_USER variable to the users login when a user is authenticated. But your script doesn't need to even worry about that, because Apache won't execute the script unless the user is authorized. So if the script is executing, then the user is authenticated... for now I'm continuing with my form based authentication, but is there a 'better' way? And if so, what makes it better? The biggest benefit I find is that you can separate your authentication code from the rest of the code. With an Authentication handler, your CGI script or content handler will never even be executed unless the user has been authenticated. Also, how would you use a CGI based authentication scheme to limit access to a static HTML file, or an image? It can't be done cleanly. But with Authentication handlers, you can hook them to a Location or Directory directive or even a Files directive in the httpd.conf file. So you can protect an entire directory with ease. Cheers, Cees
Re: mp2: architectural question re authentication handlers
Cees Hek wrote: [chomp] Thanks Cees, that's exactly what I needed :) My stuff is all completely generated by scripts where I need access control, but I certainly see the use for controlling static entity access. Carl
Re: [mod_perl] Re: Content compression FAQ
At 04/07/2003 17:29, Slava Bizyayev wrote: I've just updated the content at http://devl4.outlook.net/devdoc/FAQ/compression.html . It's very good Slava. Concise, informative and thorough. There is a small mistake in the section, Q: How hard is it to implement content compression on an existing site? Change no more that installing to no more than installing. Other than that, it looks great. Jonathan M. Hollin Digital-Word Ltd: http://digital-word.com/
Undocumented behaviour in Apache-print()?
Hi,
I've just spent quite a while tracking down a problem with a web page
generated by a mod_perl program in which 8-bit ISO-8859-1 characters
were not being shown properly. The software runs via Apache::Registry,
and works fine under mod_cgi.
It turns out that the problem is due to a difference in behaviour
between Perl's built-in print() function in Perl 5.8.0+ and the
Apache-print() method that mod_perl overrides it with. I've consulted
the documentation on the mod_perl website, and could find no mention of
the difference. If my conclusions below are correct then this
information may well be worth adding.
Under Perl 5.8.0, if a string stored in Perl's internal UTF-8 format is
passed to print() then by default it will be converted to the machine's
native 8-bit character set on output to STDOUT. In my case, this is
exactly as if I had called binmode(STDOUT, ':encoding(iso-8859-1)')
before the print(). (If any characters in the UTF-8 string are not
representable in ISO-8859-1 then a Wide character in print() warning
will be emitted, and the bytes that make up that UTF-8 character will be
output.)
However, mod_perl's Apache-print() method does not perform this
automatic conversion. It simply prints the bytes that make up each
UTF-8 character (i.e. it outputs the UTF-8 string as UTF-8), exactly as
if you had called binmode(STDOUT, ':utf8') before Apache-print(). (No
Wide character in print() warnings are produced for charcaters with
code points 0xFF either.)
The test program below illustrates this difference:
use 5.008;
use strict;
use warnings;
use Encode;
my $cset = 'ISO-8859-1';
#my $cset = 'UTF-8';
print Content-type: text/html; charset=$cset\n\n;
print EOT;
html
head
meta http-equiv=Content-type content=text/html; charset=$cset
/head
body
EOT
# $str is stored in Perl's internal UTF-8 format.
my $str = Encode::decode('iso-8859-1', 'Zurück');
print p$str/p\n;
print EOT;
/body
/html
EOT
Running under mod_cgi (using Perl's built-in print() function) the UTF-8
encoded data in $str is converted to ISO-8859-1 on-the-fly by the
print(), and the end-user will see the intended output when $cset is
ISO-8859-1. (Changing $cset to UTF-8 causes the ü to be replaced with ?
in my web browser because the ü which is output is not a valid UTF-8
character (which the output is labelled as).)
Running under mod_perl (with Perl's built-in print() function now
overridden by the Apache-print() method) the UTF-8 encoded data in $str
is NOT converted to ISO-8859-1 on-the-fly as it is printed, and the
end-user will see the two bytes that make up the UTF-8 representation of
ü when $cset is ISO-8859-1. Changing $cset to UTF-8 in this case
fixes it, because the output stream in this case happens to be valid
UTF-8 all the way through.
There are two solutions to this:
1. To use $cset = 'ISO-8859-1': Explicitly convert the UTF-8 data in
$str to ISO-8859-1 yourself before sending it to print(), rather than
relying on print() to do that for you. This is, in general, not
possible (not all characters in the UTF-8 string may be representable in
ISO-8859-1), but for HTML output we can arrange for Encode::encode to
convert any non-representable charcaters to their HTML character references:
$str = Encode::encode('iso-8859-1', $str, Encode::FB_HTMLCREF);
2. To use $cset = 'UTF-8': Output UTF-8 directly, ensuring that *all*
outgoing data is UTF-8 by adding an appropriate layer on STDOUT:
binmode STDOUT, ':utf8';
The second method here is generally to be preferred, but in the old
software that I was experiencing problems with, I was not able to add
the utf8 layer to STDOUT reliably (the data was being output from a
multitude of print() statements scattered in various places), so I stuck
with the first method. I believed that it should work without the
explicit encoding to ISO-8859-1 because I was unaware that mod_perl's
print() override removed Perl's implicit encoding behaviour. Actually,
the explicit encoding above is better anyway because it also handles
characters that can't be encoded to ISO-8859-1, but nevertheless I think
the difference in mod_perl's print() is still worth mentioning in the
documentation somewhere.
Cheers,
Steve
Re: ProxyPass not getting type of dynamic images?
It is tricky. Try this: my $format = $graph-export_format; $r-content_type(image/$format); binmode STDOUT; print STDOUT $graph-plot([EMAIL PROTECTED])-$format(); return Apache::OK; It works for me. Willy Kirk Bowe [EMAIL PROTECTED]To: [EMAIL PROTECTED] infocc: Subject: ProxyPass not getting type of dynamic images? 07/07/2003 11:55 AM Hi, I'm doing a naive one size fits all ProxyPass thing wherein I've got one server simply sitting between the end users and the real machine. So my only lines are: ProxyPass / http://other.server.with.specified.port.com:8082/ ProxyPassReverse / http://other.server.with.specified.port.com:8082/ ProxyReceiveBufferSize 16384 Most of it works fine but I appear to be losing content types. The backend server generates pretty much everything in mod_perl and Template Toolkit. However I generate PNGs on the fly too, with and without a .png extension in some cases. In particular, the PNGs aren't getting through with a mime type. Guess I need to set it somewhere -- any ideas? It all works fine without the proxy in the middle. Cheers Kirk.
Re: untainting PATH in mod_perl
Sorry, getting out of good ideas..
Surprise, surprise: I found out that my code does not work under
mod_perl 1.23 either! And I found the real solution: one has to add
PerlSetupEnv Off
to the Apache configuration file. Now the untainting mumbo-jumbo in
perl section works.
Warning: this has the consequence of breaking the part of the CGI
environment emulation that deals with environment (e.g. instead of
$ENV{HTTP_USER_AGENT}, you now have to check
Apache-request()-subprocess_env(HTTP_USER_AGENT)). Glancing at its
source code, I don't think CGI.pm will survive that...
BTW, I finally got around to reading mod_perl's source, and it
is now clear to me that the environment, when being copied from
-subprocess_env() into %ENV, gets tainted (around line 704 in
src/modules/perl/mod_perl.c). The whole %ENV gets tainted, not just
the HTTP_USER_AGENT and such from the CGI context, so PATH is tainted
as well. This explains our now common problem - and also guarantees
that there is no easy way out of it if you use CGI.pm yourself :-(.
Hope I'm being helpful at last,
--
Dominique QUATRAVAUX Ingénieur senior
01 44 42 00 08 IDEALX
mod_perl 2.0 and cookies
So Ive decided to dive headlong into 2.0. So far I like it but find the documentation lacking and there seems to be a lot missing. I tried Apache::Cookie with it, no dice. It gave an error to the effect that it didnt know what bootstrap was (I think that was it). Apache::Cookie made inserting cookies in mod_perl 1.0 so easy which in turn made life easier for programming. However I have scoured the documentation on how to insert a cookie into the header and the only thing I could come up with is that you use a filter to do it. Somehow I dont think that this is right and I am completely off. Could someone enlighten me as to how cookies work in MP2? If I can get past this I can figure out the rest on my own and maybe write a little documentation if I can understand it enough to do so. Thank you, Jamie
Re: mod_perl 2.0 and cookies
So I've decided to dive headlong into 2.0. So far I like it but find the documentation lacking and there seems to be a lot missing. I tried Apache::Cookie with it, no dice. It gave an error to the effect that it didn't know what bootstrap was (I think that was it). Apache::Cookie made inserting cookies in mod_perl 1.0 so easy which in turn made life easier for programming. However I have scoured the documentation on how to insert a cookie into the header and the only thing I could come up with is that you use a filter to do it. Somehow I don't think that this is right and I am completely off. Could someone enlighten me as to how cookies work in MP2? If I can get past this I can figure out the rest on my own and maybe write a little documentation if I can understand it enough to do so. From what I've figured out through experiementing, tho I'd find out a lot more by reading source and I'd be a bit more accurate in this... But I think mod_perl 2 is just simply lacking all together. I think the docs are lacking info because the program is lacking hte feature! Course, this only means I havern't figured out how to use the features, if they are there. But, to me, mod_perl x+1 should be backwards compatible with mod_perl x, if it isn't, then it's broken. (in my opinion..) Dennis
Re: mod_perl 2.0 and cookies
On Fri, 11 Jul 2003, Jamie Krasnoo wrote: So I've decided to dive headlong into 2.0. So far I like it but find the documentation lacking and there seems to be a lot missing. I tried Apache::Cookie with it, no dice. It gave an error to the effect that it didn't know what bootstrap was (I think that was it). Apache::Cookie made inserting cookies in mod_perl 1.0 so easy which in turn made life easier for programming. However I have scoured the documentation on how to insert a cookie into the header and the only thing I could come up with is that you use a filter to do it. Somehow I don't think that this is right and I am completely off. Could someone enlighten me as to how cookies work in MP2? If I can get past this I can figure out the rest on my own and maybe write a little documentation if I can understand it enough to do so. It wasn't clear to me - are you using the development version of httpd-apreq-2? The CPAN version of libapreq are for mod_perl 1 - you'll need httpd-apreq-2 (available via cvs) for Apache 2. If you are using Apache::Cookie of httpd-apreq-2, at this point, probably the simplest way to see examples of the basic usage is to go through the tests, under glue/perl/t/. Documentation patches would be welcome - it would be easiest to subscribe to the [EMAIL PROTECTED] mailing list and submit them there. -- best regards, randy kobes
RE: mod_perl 2.0 and cookies
On Fri, 11 Jul 2003, Ross Matt-QMR000 wrote: I would really like to be removed from this list but the un-scribe does not work for me. the problem is the mail address that I used way back when has been aliases to different address. Try sending a message to [EMAIL PROTECTED] for some suggestions. -- best regards, randy kobes
Dynamically banning hosts
Is it possible to dynamically ban IP addresses using mod_perl. Like even the first connection from the specified ip will be rejected. I know that you can do this using httpd.conf but I am wondering how to do the same dynamically while Apache is running. Also how can I cope with denial of service attacks? I know there is no general solution to this, but is there a particular technique to ease the problem. The environment is one host that serves small number of people with a very limited bandwidth. Thanks __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
