RE: Dynamically banning hosts
Hi Mustafa -- > 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. Yes, it is possible with mod_perl. You can create a PerlAccessHandler which allows or denies access for a particular client based on some logic. The Access phased is the appropriate place for such a handler. > 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. I don't know of any particular CPAN module which would detect a DOS attack. There have been a few specialized modules, such as Apache::CodeRed, but I don't think that's what you're looking for. If you can define the nature of the attack, you can write code to defend against it. Mod_perl can definitely allow you to add logic at the right time to implement such a defense. Warmest regards, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
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
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
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
> 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
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. Thank you, Jamie
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
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
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]
info>cc:
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.
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
# $str is stored in Perl's internal UTF-8 format.
my $str = Encode::decode('iso-8859-1', 'Zurück');
print "$str\n";
print <
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: [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/
