Re: protecting internal redirects
Both very good points! I stand corrected. Michael Peters wrote: On 03/18/2010 06:05 PM, Michael A. Capone wrote: This would be the most secure way. Saying it's the *most* secure way is a little stretch. It's *another* secure way. Also, keeping a large Perl/CGI process alive just to serve a static file is a waste. In fact, if you can think of a mod_rewrite rule to automatically look for the cached file first and send that before even getting to the CGI script would be your best bet for performance.
Re: protecting internal redirects
On 03/18/2010 06:05 PM, Michael A. Capone wrote: This would be the most secure way. Saying it's the *most* secure way is a little stretch. It's *another* secure way. Also, keeping a large Perl/CGI process alive just to serve a static file is a waste. In fact, if you can think of a mod_rewrite rule to automatically look for the cached file first and send that before even getting to the CGI script would be your best bet for performance. -- Michael Peters
Re: protecting internal redirects
Rather than doing the URL redirect, why not just keep the cached results
in a private directory, and let the CGI open them and serve them up
directly? This would be the most secure way.
So, you could do something like this:
print "Content-type: text/html\n\n"; # or whatever the appropriate
content-type is
$cached_file_name = FigureOutRequest(); # find out if the result is
already cached in a file
if ($cached_file_name != "")
{
open CACHEFILE, "/path/to/$cached_file_name";
print STDOUT ; # send output to browser
close CACHEFILE;
}
else
{
$generated_result = DoAllTheWork();
$new_cache_file = "appropriate_name.txt";# save the generated
result into the cache...
open CACHEOUT, "> /path/to/$new_cache_file";
print CACHEOUT $generated_result;
close CACHEOUT;
print STDOUT $generated_result; # ... and then send it
back to the browser.
}
Would that get the job done?
E R wrote:
Hi all,
This is not exactly a mod_perl question - in fact I hope there is a
solution which does not use mod_perl.
I have a CGI script which generates a lot of output. Because it takes
a lot of time to the output, the results are cached in case the same
request is made again.
To serve the file the CGI script issues an internal redirect to a url
which points to the cached results.
My question is: can the url which points to the cached results be
protected so that it cannot be directly accessed by external clients?
For example:
1. user makes a request
2. CGI script handles request. It computes a file name for the
results, generates the results and places the result in that file.
3. The CGI script then emits an internal redirect to a url which will
map to the file name determined in step 2.
4. Apache will process the internal redirect and serve the contents of
the file to the client.
I want to prevent the clients from accessing the file directly by
figuring out what the url is in step 3.
I know that clients will not see the internal redirect, but I also
want to prevent them from guessing it.
Is there an Apache configuration I can use to accomplish this, or do I
need to use mod_perl?
Thanks,
ER
Re: protecting internal redirects
On 03/18/2010 04:59 PM, E R wrote: My question is: can the url which points to the cached results be protected so that it cannot be directly accessed by external clients? You should be able to do something like this for that block (so you might have to put that URL inside of a separate block) assuming the IP of your machine is 1.2.3.4 Order Deny,Allow Deny from all Allow from 1.2.3.4 -- Michael Peters Plus Three, LP
protecting internal redirects
Hi all, This is not exactly a mod_perl question - in fact I hope there is a solution which does not use mod_perl. I have a CGI script which generates a lot of output. Because it takes a lot of time to the output, the results are cached in case the same request is made again. To serve the file the CGI script issues an internal redirect to a url which points to the cached results. My question is: can the url which points to the cached results be protected so that it cannot be directly accessed by external clients? For example: 1. user makes a request 2. CGI script handles request. It computes a file name for the results, generates the results and places the result in that file. 3. The CGI script then emits an internal redirect to a url which will map to the file name determined in step 2. 4. Apache will process the internal redirect and serve the contents of the file to the client. I want to prevent the clients from accessing the file directly by figuring out what the url is in step 3. I know that clients will not see the internal redirect, but I also want to prevent them from guessing it. Is there an Apache configuration I can use to accomplish this, or do I need to use mod_perl? Thanks, ER
Re: mod_perl memory
Thanks, that did the job. I'm currently testing for side effects but it all
looks good so far.
On Mar 18, 2010, at 4:09 AM, Torsten Förtsch wrote:
> On Thursday 18 March 2010 11:54:53 Mårten Svantesson wrote:
>> I have never worked directly with the APR API but in the example above
>> couldn't you prevent the request pool from growing by explicitly reusing
>> the bucket brigade?
>>
>> Something like (not tested):
>>
>> sub {
>> my ($r)=...@_;
>>
>> my $ba=$r->connection->bucket_alloc;
>> my $bb2=APR::Brigade->new($r->pool, $ba);
>> until( -e '/tmp/stop' ) {
>> $bb2->insert_tail(APR::Bucket->new($ba, ("x"x70)."\n"));
>> $bb2->insert_tail(APR::Bucket::flush_create $ba);
>> $r->output_filters->pass_brigade($bb2);
>> $bb2->cleanup();
>> }
>>
>> $bb2->insert_tail(APR::Bucket::eos_create $ba);
>> $r->output_filters->pass_brigade($bb2);
>>
>> return Apache2::Const::OK;
>> }
>>
> Thanks for pointing to the obvious. This doesn't grow either.
>
> Torsten Förtsch
>
> --
> Need professional modperl support? Hire me! (http://foertsch.name)
>
> Like fantasy? http://kabatinte.net
Re: mod_perl memory
On Thursday 18 March 2010 11:54:53 Mårten Svantesson wrote:
> I have never worked directly with the APR API but in the example above
> couldn't you prevent the request pool from growing by explicitly reusing
> the bucket brigade?
>
> Something like (not tested):
>
> sub {
>my ($r)=...@_;
>
>my $ba=$r->connection->bucket_alloc;
>my $bb2=APR::Brigade->new($r->pool, $ba);
>until( -e '/tmp/stop' ) {
> $bb2->insert_tail(APR::Bucket->new($ba, ("x"x70)."\n"));
> $bb2->insert_tail(APR::Bucket::flush_create $ba);
> $r->output_filters->pass_brigade($bb2);
> $bb2->cleanup();
>}
>
>$bb2->insert_tail(APR::Bucket::eos_create $ba);
>$r->output_filters->pass_brigade($bb2);
>
>return Apache2::Const::OK;
> }
>
Thanks for pointing to the obvious. This doesn't grow either.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
Re: mod_perl memory
Torsten Förtsch skrev:
On Thursday 18 March 2010 04:13:04 Pavel Georgiev wrote:
How would that logic (adding subpools and using them) be applied to my
simplified example:
for (;;) {
$request->print("--$this->{boundary}\n");
$request->print("Content-type: text/html; charset=utf-8;\n\n");
$request->print("$data\n\n");
$request->rflush;
}
Do I need to add an output filter?
No, this one does not grow here.
sub {
my ($r)=...@_;
my $ba=$r->connection->bucket_alloc;
until( -e '/tmp/stop' ) {
my $pool=$r->pool->new;
my $bb2=APR::Brigade->new($pool, $ba);
$bb2->insert_tail(APR::Bucket->new($ba, ("x"x70)."\n"));
$bb2->insert_tail(APR::Bucket::flush_create $ba);
$r->output_filters->pass_brigade($bb2);
$pool->destroy;
}
my $bb2=APR::Brigade->new($r->pool, $ba);
$bb2->insert_tail(APR::Bucket::eos_create $ba);
$r->output_filters->pass_brigade($bb2);
return Apache2::Const::OK;
}
Torsten Förtsch
I have never worked directly with the APR API but in the example above couldn't you prevent the request pool from growing by explicitly reusing the
bucket brigade?
Something like (not tested):
sub {
my ($r)=...@_;
my $ba=$r->connection->bucket_alloc;
my $bb2=APR::Brigade->new($r->pool, $ba);
until( -e '/tmp/stop' ) {
$bb2->insert_tail(APR::Bucket->new($ba, ("x"x70)."\n"));
$bb2->insert_tail(APR::Bucket::flush_create $ba);
$r->output_filters->pass_brigade($bb2);
$bb2->cleanup();
}
$bb2->insert_tail(APR::Bucket::eos_create $ba);
$r->output_filters->pass_brigade($bb2);
return Apache2::Const::OK;
}
--
Mårten Svantesson
Senior Developer
Travelocity Nordic
+46 (0)8 505 787 23
Re: mod_perl memory
On Thursday 18 March 2010 10:16:07 Torsten Förtsch wrote:
> No, this one does not grow here.
>
> sub {
> ...
forgot to mention that the function is supposed to be a PerlResponseHandler.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
Re: mod_perl memory
On Thursday 18 March 2010 04:13:04 Pavel Georgiev wrote:
> How would that logic (adding subpools and using them) be applied to my
> simplified example:
>
> for (;;) {
>$request->print("--$this->{boundary}\n");
>$request->print("Content-type: text/html; charset=utf-8;\n\n");
>$request->print("$data\n\n");
>$request->rflush;
> }
>
> Do I need to add an output filter?
>
No, this one does not grow here.
sub {
my ($r)=...@_;
my $ba=$r->connection->bucket_alloc;
until( -e '/tmp/stop' ) {
my $pool=$r->pool->new;
my $bb2=APR::Brigade->new($pool, $ba);
$bb2->insert_tail(APR::Bucket->new($ba, ("x"x70)."\n"));
$bb2->insert_tail(APR::Bucket::flush_create $ba);
$r->output_filters->pass_brigade($bb2);
$pool->destroy;
}
my $bb2=APR::Brigade->new($r->pool, $ba);
$bb2->insert_tail(APR::Bucket::eos_create $ba);
$r->output_filters->pass_brigade($bb2);
return Apache2::Const::OK;
}
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
