RE: Forking another process in Apache?
We've had a fair amount of success handing long processing jobs off to
daemons (written with Net:Daemon, in most cases passing across args using
Net::Telnet), using pages with reloading redirects to check the daemon
status in a table.
Avoids much work in httpd, and allows user to hang up web connection and
return later to continue viewing status.
- Chris
-Original Message-
From: Mike P. Mikhailov [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, 22 January 2002 6:04 PM
To: eCap
Cc: [EMAIL PROTECTED]
Subject: Re: Forking another process in Apache?
Hello eCap,
Monday, January 21, 2002, 10:45:37 PM, you wrote:
e A newbie question here...
e I have a requirement to spin off a SQL loader process after a
web page (a
e form which is qualified and accepted) has been submitted. Does it make
e sense, or more importantly, is it dangerous to apply a fork
at the end of
e a module such as this:
e sub handler {
e # do some qualification stuff here and accept the form submission...
e if ($pid = fork) {
e # parent
e # ...whatever i need to accomplish to deliver return html code
e return OK
e } elsif {
e # child
e exec($sql_loader);
e } else {
e # ...whatever i ned to do to recover errors
e return DECLINED
e }
e }
e Are there any dangers in doing something like this? Or is there a more
e efficient way to accomplish the same thing?
e Thanks for the advice,
e Kirk
I'm recently implement exactly such loader. From the client HTTP
request I'm starting loader with double fork approach. I'm loading
posssible large enough (about 100 - 150 MB) data from DBF flat files
into Oracle in single transaction (I'm must provide consistency).
Loader process takes about 40-50 min to complete and consumes many
resources (CPU and RAM). But it works !
--
WBR, Mike P. Mikhailov
mailto:[EMAIL PROTECTED]
Pessimests are right more often, but optimists are happy more often
Re: disable mod_perl for certain virtual hosts/folders
[EMAIL PROTECTED] wrote: On my Apache mod_perl is generally enabled with the following statement: Directory /data/apache Files ~ \.pl$ SetHandler perl-script PerlHandler Apache::Registry Options +ExecCGI /Files /Directory you might have better luck with something like Directory /data/apache AddHandler .pl perl-script PerlHandler Apache::Registry Options +ExecCGI /Directory which should work. --Geoff
Re: disable mod_perl for certain virtual hosts/folders
On Tue, Jan 22, 2002 at 08:31:02AM -0500, Geoffrey Young wrote: [EMAIL PROTECTED] wrote: On my Apache mod_perl is generally enabled with the following statement: Directory /data/apache Files ~ \.pl$ SetHandler perl-script PerlHandler Apache::Registry Options +ExecCGI /Files /Directory you might have better luck with something like Directory /data/apache AddHandler .pl perl-script PerlHandler Apache::Registry Options +ExecCGI /Directory thnx, but: This part doesnt make the problem. mod_perl works like a charm. Problem is how to deactivate it for a certain location ? thnx, peter
Re: disable mod_perl for certain virtual hosts/folders
Directory /data/apache AddHandler .pl perl-script PerlHandler Apache::Registry Options +ExecCGI /Directory thnx, but: This part doesnt make the problem. mod_perl works like a charm. Problem is how to deactivate it for a certain location ? well, only .pl files will be handled by Apache::Registry under this config - /data/apache/foo.html ought to be handled by core. unless you have a global SetHandler perl-script somewhere, mod_perl should not handle the content-generation phase without being further specified. --Geoff
Re: disable mod_perl for certain virtual hosts/folders
On Tue, Jan 22, 2002 at 08:53:39AM -0500, Geoffrey Young wrote: Directory /data/apache AddHandler .pl perl-script PerlHandler Apache::Registry Options +ExecCGI /Directory thnx, but: This part doesnt make the problem. mod_perl works like a charm. Problem is how to deactivate it for a certain location ? well, only .pl files will be handled by Apache::Registry under this config - /data/apache/foo.html ought to be handled by core. unless you have a global SetHandler perl-script somewhere, mod_perl should not handle the content-generation phase without being further specified. but this is what my config does: Directory /data/apache Files ~ \.pl$ SetHandler perl-script PerlHandler Apache::Registry Options +ExecCGI /Files /Directory only pl-files are affected. Unfortunately I have some pl-files that must not run under mod_perl (even not under PerlRun cause they are really dirty) and I wonder if there is no way to set the orginal cgi-handler (that does not use mod_perl) for a certain location/virtual host. I thought this default-handler is cgi-script, but SetHandler cgi-script in a virtual host does not do the trick. The only way I've found by now is not to enable mod_perl globally, but put the above config in each virtual-host section but the one that contains the mad pl-files. While this is what I do now, I really wonder I one cant disable mod_perl .. thnx, peter
Re: disable mod_perl for certain virtual hosts/folders
Hi! On Tue, Jan 22, 2002 at 03:02:58PM +0100, [EMAIL PROTECTED] wrote: only pl-files are affected. Unfortunately I have some pl-files that must not run under mod_perl (even not under PerlRun cause they are really dirty) and I wonder if there is no way to set the orginal cgi-handler (that does not use mod_perl) for a certain location/virtual host. I thought this default-handler is cgi-script, but SetHandler cgi-script in a virtual host does not do the trick. What about Location /plain-cgi/ SetHandler cgi-script Options ExecCGI allow from all /Location -- D_OMM + http://domm.zsi.at -+ O_xyderkes | neu: Arbeitsplatz | M_echanen | http://domm.zsi.at/d/d162.html | M_asteuei ++
mod_perl 1.26 and Mozilla/Netscape again ?
Hello, while working on a small CGI program that should run under mod_perl for performance reasons, I get this: [Tue Jan 22 16:48:31 2002] [info] [client 192.168.1.5] (2)No such file or directory: client stopped connection before rwrite completed [Tue Jan 22 16:48:31 2002] [debug] Apache.c(364): (2)No such file or directory: mod_perl: rwrite returned -1 (fd=-1, B_EOUT=8) Searching the archives only yields some fuzzy remarks about a possible Netscape bug and an assorted patch for mod_perl 1.17, but that's some time ago now. I've seen this problem now on Mozilla 0.9.7, Netscape 4.77 and Opera 5.2 (all under Linux). (I definitely didn't hit the stop button). Is this a problem of the server, the client, or both? I was able to work around the problem for all three clients (couldn't test IE yet) by constructing the whole page in memory in one variable and then pushing it out in one go. The only problem with this approach is that this particular page can get quite big (~ 2MB). The script itself is a simple Apache::Registry script that should as well work under regular CGI, and running it from the command line works just fine. What should I do? I've seen the problem both under Linux (Debian woody) and OpenBSD 3.0 -stable using Apache 1.3.22 and mod_perl 1.26. TIA! Best, --Toni++
Re: Solaris + Apache + mod_perl = TROUBLE
Thanks for the trouble time though. -- Philip M. Gollucci (p6m7g8) [EMAIL PROTECTED] 301.314.3118 Science, Discovery, the Universe (UMCP) Webmaster Webship Teacher URL: http://www.sdu.umd.edu EJPress.com Database/PERL Programmer System Admin URL : http://www.ejournalpress.com Resume : http://www.p6m7g8.com/resume.txt On Mon, 21 Jan 2002, John D Groenveld wrote: I have system (Solaris 2.6) which I do NOT have root on... (now I know why that doesn't happen often) No problem. Make sure root has applied the latest recommended patch set for 2.6. At anyrate, I need to install perl5.6.1 ... I'll pay anyone able to do without using a binary release (on this particular solaris system (yes its that bad), Apache Apache-1.3.22 from source, and mod_perl1.26 You should be able to build perl 5.6.1 from source and install it in your own directory. ./Configure -Dprefix=/virtual/www/sdu/perl -Dcc=gcc -Duseshrplib -Uusemymalloc -Ubincompat5005 John [EMAIL PROTECTED]
Re: Solaris + Apache + mod_perl = TROUBLE
Actually I tried that exact configure line one of the millions I tried it for perl, and it got to make, where I got millions of undefined PL_* errors. I can't control what patches they have or have not applied... Is there anyway I can check myself ? I'm more of a BSD/FreeBSD expert. -- Philip M. Gollucci (p6m7g8) [EMAIL PROTECTED] 301.314.3118 Science, Discovery, the Universe (UMCP) Webmaster Webship Teacher URL: http://www.sdu.umd.edu EJPress.com Database/PERL Programmer System Admin URL : http://www.ejournalpress.com Resume : http://www.p6m7g8.com/resume.txt On Mon, 21 Jan 2002, John D Groenveld wrote: I have system (Solaris 2.6) which I do NOT have root on... (now I know why that doesn't happen often) No problem. Make sure root has applied the latest recommended patch set for 2.6. At anyrate, I need to install perl5.6.1 ... I'll pay anyone able to do without using a binary release (on this particular solaris system (yes its that bad), Apache Apache-1.3.22 from source, and mod_perl1.26 You should be able to build perl 5.6.1 from source and install it in your own directory. ./Configure -Dprefix=/virtual/www/sdu/perl -Dcc=gcc -Duseshrplib -Uusemymalloc -Ubincompat5005 John [EMAIL PROTECTED]
Cross-site Scripting prevention with Apache::TaintRequest
Hi, I thought it might be interesting to start a thread on cross-site scripting attacks, since it seems that many people are not aware of the risks involved. Has anyone noticed attacks on their applications? Do you religiously check all input you get from form-submissions? What techniques do you use to insure that your application is not vulnerable? One technique that I've used is 'Tainting' input data (with PerlTaintCheck) and using a subclass of the Apache module to insure that tainted data is html-escaped. As part of the CPANification of the code in the mod_perl Developer's cookbook, I present Apache::TaintRequest, a module that helps prevent cross-site scripting attacks by automatically html-escaping 'tainted' text sent to a web browser.. Get it at http://www.modperlcookbook.org/code.html I'd be interested in hearing how others have dealt with the problem, suggestions on how this module could be used further are most welcome. -- Paul Lindner[EMAIL PROTECTED] | | | | | | | | | | mod_perl Developer's Cookbook http://www.modperlcookbook.org Human Rights Declaration http://www.unhchr.ch/udhr/index.htm
Re: Cross-site Scripting prevention with Apache::TaintRequest
What techniques do you use to insure that your application is not vulnerable? Usually I write application so that they do some processing, package up a chunk of data, and hand it to a template. With this structure, all you need to do is HTML-escape the data structure before handing it off, or use a templating tool that defaults to HTML-escaping all printed variables. If you're doing this, nothing the user sends in will pose a CSS threat. - Perrin
Re: Cross-site Scripting prevention with Apache::TaintRequest
On Tuesday 22 January 2002 18:48, Perrin Harkins wrote: What techniques do you use to insure that your application is not vulnerable? Usually I write application so that they do some processing, package up a chunk of data, and hand it to a template. With this structure, all you need to do is HTML-escape the data structure before handing it off, or use a templating tool that defaults to HTML-escaping all printed variables. If you're doing this, nothing the user sends in will pose a CSS threat. Yes and no. XSS attacks are possible on old browsers, when the charset is not set (something which is often the case with modperl apps) and when the HTML-escaping bit does not match what certain browsers accept as markup. See http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-03/msg00750.html for a discussion of this. I think CGI.pm is safe now, and most modern browsers appear to have fixed that behaviour, but quite a few still remain in circulation and I'm not sure that all templating systems are handling the escaping properly. -- ___ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- Critic, n.: A person who boasts himself hard to please because nobody tries to please him.
Re: Cross-site Scripting prevention with Apache::TaintRequest
On Tue, Jan 22, 2002 at 09:25:15AM -0800, Paul Lindner wrote:
Hi,
I thought it might be interesting to start a thread on cross-site
scripting attacks, since it seems that many people are not aware of
the risks involved. Has anyone noticed attacks on their applications?
Do you religiously check all input you get from form-submissions?
What techniques do you use to insure that your application is not
vulnerable?
I've been pondering a lot about this lately, since I find creating
form validation routines very repetitive. So what I've come up with
so far is (not yet finished):
my $fields = {
id = ['\d+', \validation_sub ],
text = ['(?:\w\s)+']
};
And I feed this along with the request or cgi object to a function
that checks each key for first the simple regexp to see if it's worth
trying the real validation function.
My little system for doing this isn't
All the variables that are passed through form fields into other pages
goes through HTML::Entities' encode_entites function right before it's
inserted in a template.
--
Thomas Eibner http://thomas.eibner.dk/ DnsZone http://dnszone.org/
mod_pointer http://stderr.net/mod_pointer
Re: Cross-site Scripting prevention with Apache::TaintRequest
On Tue, 22 Jan 2002 19:01:48 +0100
Thomas Eibner [EMAIL PROTECTED] wrote:
my $fields = {
id = ['\d+', \validation_sub ],
text = ['(?:\w\s)+']
};
And I feed this along with the request or cgi object to a function
that checks each key for first the simple regexp to see if it's worth
trying the real validation function.
see also CGI::Untaint by Tony Bowden, on CPAN.
--
Tatsuhiko Miyagawa [EMAIL PROTECTED]
Re: Cross-site Scripting prevention with Apache::TaintRequest
On Tue, 22 Jan 2002 09:25:15 -0800 Paul Lindner [EMAIL PROTECTED] wrote: As part of the CPANification of the code in the mod_perl Developer's cookbook, I present Apache::TaintRequest, a module that helps prevent cross-site scripting attacks by automatically html-escaping 'tainted' text sent to a web browser.. Get it at http://www.modperlcookbook.org/code.html Techniques I use depends on HTML::Template's TMPL_VAR escape=HTML stuff. But your idea to detect output from Untainted data for protection against CSS, is very neat. Nice. -- Tatsuhiko Miyagawa [EMAIL PROTECTED]
Re: Cross-site Scripting prevention with Apache::TaintRequest
Yes and no. XSS attacks are possible on old browsers, when the charset is not set (something which is often the case with modperl apps) and when the HTML-escaping bit does not match what certain browsers accept as markup. Of course I set the charset, but I didn't know that might not be enough. Does anyone know if Apache::Util::escape_html() and HTML::Entities::encode() are safe? - Perrin
Re: Cross-site Scripting prevention with Apache::TaintRequest
On Tuesday 22 January 2002 19:04, Perrin Harkins wrote: Of course I set the charset, but I didn't know that might not be enough. Does anyone know if Apache::Util::escape_html() and HTML::Entities::encode() are safe? A quick look (I could be wrong) at HTML::Entities seems to imply that it should be safe, as it uses numeric encoding for characters that it doesn't recognize. I don't know about Apache::Util. -- ___ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- I don't suffer from insanity. I enjoy every minute of it.
Re: Cross-site Scripting prevention with Apache::TaintRequest
On Tue, Jan 22, 2002 at 07:11:28PM +0100, Robin Berjon wrote: On Tuesday 22 January 2002 19:04, Perrin Harkins wrote: Of course I set the charset, but I didn't know that might not be enough. Does anyone know if Apache::Util::escape_html() and HTML::Entities::encode() are safe? A quick look (I could be wrong) at HTML::Entities seems to imply that it should be safe, as it uses numeric encoding for characters that it doesn't recognize. I don't know about Apache::Util. BTW, if you don't html-escape and just search for tags you should make sure to HTML::Entities::decode() the text before processing it. I've seen cases where people disguised scripting code with numeric entities.. jav...;script etc... -- Paul Lindner[EMAIL PROTECTED] | | | | | | | | | | mod_perl Developer's Cookbook http://www.modperlcookbook.org Human Rights Declaration http://www.unhchr.ch/udhr/index.htm
RE: Solaris + Apache + mod_perl = TROUBLE
Try showrev -p for a list of installed patches. -Original Message- From: Philip M. Gollucci [mailto:[EMAIL PROTECTED]] Subject: Re: Solaris + Apache + mod_perl = TROUBLE I can't control what patches they have or have not applied... Is there anyway I can check myself ? I'm more of a BSD/FreeBSD expert.
RE: Forking another process in Apache?
Chris Hutchinson writes: Avoids much work in httpd, and allows user to hang up web connection and return later to continue viewing status. We used to do this, but found it more complex (more protocols and server types) than simply letting Apache/mod_perl handle the job. I guess this depends on the frequency of long requests, but in our case the mix is handle nicely with a single common server using http as the only protocol. The idea is that all the work is handled by the middle tier. This includes processing incoming mail messages, long running jobs, and credit card processing. There's a lot of common code between all these tasks, so memory is shared efficiently. One trick for long running jobs started by an http request is to reply to the user as normal and do the long part in a PerlCleanupHandler. This avoids a fork of a large process, which keeps the memory usage relatively constant. This simplifies resource allocation. Just another way to do it. Rob
RE: Solaris + Apache + mod_perl = TROUBLE
I apologize, I'm afraid I was lost in my brevity :). showrev -p will return a list of installed Solaris system patches. Try showrev -p for a list of installed patches. -Original Message- From: Philip M. Gollucci [mailto:[EMAIL PROTECTED]] Subject: Re: Solaris + Apache + mod_perl = TROUBLE I can't control what patches they have or have not applied... Is there anyway I can check myself ? I'm more of a BSD/FreeBSD expert.
