Re: ASP Cookieless Sessions (WAS Re: Apache::ASP)

2000-01-02 Thread Greg Stark


Joshua Chamas <[EMAIL PROTECTED]> writes:

> It reoccured to me just now (back from a sessions methods discussion a long
> time ago) that these query string cookies might show up in the referer logs
> of other sites if you have offsite links on your session id pages. I tried a
> workaround just now where a redirect program would handle offsite links, but
> the HTTP_REFERER is sticky to the last page visited, and I see no workaround
> to this security issue.

Instead of redirecting them offsite present a page saying "you're about to go
offsite" and use a refresh meta tag to send them on their way. If you set the
timeout on the refresh to 0 they won't even see the page and I would expect
the referrer to still be set. You might even be able to use a refresh header
instead of a meta tag and just use a static html page.

-- 
greg



Re: ApacheDBI vs DBI for TicketMaster

2000-01-02 Thread James G Smith

Ed Loehr <[EMAIL PROTECTED]> wrote:
>Edmund Mergl wrote:
>
>> > > On Sun, Jan 02, 2000 at 01:48:58AM -0600, Ed Loehr wrote:
>> > > > My apache children are seg faulting due to some combination of
>> > > > DBI usage and the cookie-based authentication/authorization
>Compiled everything myself.  Oh, and I am also using DBD::Pg 0.92...
>
>Does that suggest anything to anyone?

My experience is with DBD::mysql, but I've seen something like
this before.  One thing to do is turn on as much debugging as you
can to see exactly where it is segfaulting.  For me, the most helpful
is a lot of information in the error_log.  You will need to look
at the DBI/DBD source to see exactly what is needed for debugging,
but it's not too obscure.

With MySQL, I have to make sure enough file descriptors are available
for the connections.  Apache::DBI can help, but I've still had to
up the limit on the database server.  This can cause odd problems
with MySQL at least.

Also, make sure it's not segfaulting when loading something.  I
don't know if DBD::Pg autoloads, or if such a thing could even cause
a segfault the late in the game, but if nothing else turns up,
you might want to check that.
-- 
James Smith <[EMAIL PROTECTED]>, 409-862-3725
Texas A&M CIS Operating Systems Group, Unix



Re: ApacheDBI vs DBI for TicketMaster

2000-01-02 Thread Ed Loehr

Edmund Mergl wrote:

> > > On Sun, Jan 02, 2000 at 01:48:58AM -0600, Ed Loehr wrote:
> > > > My apache children are seg faulting due to some combination of
> > > > DBI usage and the cookie-based authentication/authorization
> > > [...]
> > > > child seg faults.  If I comment out all DBI references in the
> > >
> > > Hm, are you connecting to your database prior to Apache's forking
> >
> > No.  BTW, this is all on apache 1.3.9 with mod_ssl 2.4.9 and mod_perl 1.21 on
> Redhat 6.1 (2.2.12-20smp)...

>
> do you use rpm's or did you compile everything by yourself ?

Compiled everything myself.  Oh, and I am also using DBD::Pg 0.92...

Does that suggest anything to anyone?

Cheers,
Ed Loehr



Re: ApacheDBI vs DBI for TicketMaster

2000-01-02 Thread Edmund Mergl

Ed Loehr wrote:
> 
> Randy Harmon wrote:
> 
> > On Sun, Jan 02, 2000 at 01:48:58AM -0600, Ed Loehr wrote:
> > > My apache children are seg faulting due to some combination of
> > > DBI usage and the cookie-based authentication/authorization
> > [...]
> > > child seg faults.  If I comment out all DBI references in the
> >
> > Hm, are you connecting to your database prior to Apache's forking - i.e., in
> > your startup.pl?  That could cause trouble, especially on older versions of
> > Apache and Apache::DBI.
> 
> No.  I'm only connecting in the child servers.  I verified that via PIDs in the
> log file with debugging prints, and logically as well since the DBI::connect()
> command is only executed during a query reached via a handler...
> 
> BTW, this is all on apache 1.3.9 with mod_ssl 2.4.9 and mod_perl 1.21 on Redhat
> 6.1 (2.2.12-20smp)...
> 
> Anyone else have any suspicions/ideas/leads?


do you use rpm's or did you compile everything by yourself ?

Edmund

-- 
Edmund Mergl
mailto:[EMAIL PROTECTED]
http://www.bawue.de/~mergl



Re: ApacheDBI vs DBI for TicketMaster

2000-01-02 Thread Ed Loehr

Randy Harmon wrote:

> On Sun, Jan 02, 2000 at 01:48:58AM -0600, Ed Loehr wrote:
> > My apache children are seg faulting due to some combination of
> > DBI usage and the cookie-based authentication/authorization
> [...]
> > child seg faults.  If I comment out all DBI references in the
>
> Hm, are you connecting to your database prior to Apache's forking - i.e., in
> your startup.pl?  That could cause trouble, especially on older versions of
> Apache and Apache::DBI.

No.  I'm only connecting in the child servers.  I verified that via PIDs in the
log file with debugging prints, and logically as well since the DBI::connect()
command is only executed during a query reached via a handler...

BTW, this is all on apache 1.3.9 with mod_ssl 2.4.9 and mod_perl 1.21 on Redhat
6.1 (2.2.12-20smp)...

Anyone else have any suspicions/ideas/leads?

Cheers,
Ed Loehr



Re: What's wrong with this?

2000-01-02 Thread Randy Harmon

On Sun, Jan 02, 2000 at 01:13:26PM -0800, Aaron Turner wrote:
> 
> This is driving me nuts.  This code works the first few exectutions, but
> then doesn't after a while.  It's pretty simple, it should print out:
> 
> Name = value1
> Name = value2
> 
> then after a few reloads it prints:
> 
> Name = value1
> Name = value1
> 
> I'm sure it's something stupid, but my brain is apparently fried.

This is a FAQ.  You're declaring a closure by using %variable in that
inside subroutine.  Yes, it's 'my' to the handler, but using it inside the
other subroutine makes it kind of like a persistent copy of the very first
usage of the variable.  So, even if the handler gets a new %variable each
time, the closure never sees it.  That's the behavior you're seeing, per
apache process.

I'd suggest making it $variable = {}, then passing $variable into the
subroutine.  That way you declare a subroutine-local (lexically scoped,
declared with 'my') variable inside change_var(), whose lexical lifetime
begins when the subroutine has the path of execution, and whose lexical
lifetime ends as soon as the subroutine returns.  It's set to refer to the
handler's my $variable, each time the subroutine is called, and the
handler()'s $variable is modified through that reference.  

I've modified the subroutine quoted below.  The changes make it so that no
closure of %variable is created, and change_var() is now able to adjust the
per-invocation %$variable properly.  Unchanged lines are still quoted.

[clip: setup, use ...; lines etc]
> sub handler {
> 
my $variable = {};
> $| = 1;
$variable->{'name'} = "value1";

> my $r = shift;
> $r->content_type('text/html');
> $r->send_http_header;
> 
print "Name = " . $variable->{'name'} . "";
change_var( $variable );
print "Name = " . $variable->{'name'} . "";

> return OK;
> 
> sub change_var {
 my $variable = shift;
 $variable->{'name'} = "value2";
> }
> 
> }
> 1;
> 
> Thanks in adavance.

Yours was a good simple code sample.  Hopefully this addition to the
mailing list archives will help some folks out in the future.

Randy



What's wrong with this?

2000-01-02 Thread Aaron Turner


This is driving me nuts.  This code works the first few exectutions, but
then doesn't after a while.  It's pretty simple, it should print out:

Name = value1
Name = value2

then after a few reloads it prints:

Name = value1
Name = value1

I'm sure it's something stupid, but my brain is apparently fried.



package Apache::local;

use strict;
use Apache::Constants qw(:common);
use CGI;

sub handler {

my %variable = ();
$| = 1;
$variable{'name'} = "value1";
my $r = shift;
$r->content_type('text/html');
$r->send_http_header;

print "Name = " . $variable{'name'} . "";
change_var();
print "Name = " . $variable{'name'} . "";
return OK;

sub change_var {
$variable{'name'} = "value2";
}

}
1;

Thanks in adavance.

--
Aaron Turner, Core Developer   http://vodka.linuxkb.org/~aturner/
Linux Knowledge Base Organization  http://linuxkb.org/
Because world domination requires quality open documentation.
aka: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]



modperl port of man.cgi?

2000-01-02 Thread Aaron Turner


Has anyone bothered to port man.cgi (man page to html converter) from a
CGI to modperl?  It doesn't run properly under Apache::Registry, and even
though I've written about 20 modperl scripts before, I can't for the life
of me get my port to work. 

--
Aaron Turner, Core Developer   http://vodka.linuxkb.org/~aturner/
Linux Knowledge Base Organization  http://linuxkb.org/
Because world domination requires quality open documentation.
aka: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]



Re: ApacheDBI vs DBI for TicketMaster

2000-01-02 Thread Randy Harmon

On Sun, Jan 02, 2000 at 01:48:58AM -0600, Ed Loehr wrote:
> My apache children are seg faulting due to some combination of
> DBI usage and the cookie-based authentication/authorization
[...]
> child seg faults.  If I comment out all DBI references in the

Hm, are you connecting to your database prior to Apache's forking - i.e., in
your startup.pl?  That could cause trouble, especially on older versions of
Apache and Apache::DBI.

> Any clues?

Not much of one.  Hope it helps.

Randy



RE: apache.org problem ?

2000-01-02 Thread Gerald Richter

>
> today, I've seen dev.apache.org replacing perl.apache.org...
>
> is it normal ?  ;-(
>

Brian (Behlendorf) does a lot of changes to apache.org. perl.apache.org is
currently moving to another machine. Seems sonething has gone wrong in this
process.

Gerald


-
Gerald Richterecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post:   Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151
WWW:http://www.ecos.de  Fax:  +49 6133 925152
-



apache.org problem ?

2000-01-02 Thread Emmanuel PIERRE

today, I've seen dev.apache.org replacing perl.apache.org...

is it normal ?  ;-(

--
-= Emmanuel PIERREICQ: 19153556 [EMAIL PROTECTED] =-
http://www.e-nef.com/users/epierrehttp://www.apr-job.com
[EMAIL PROTECTED]   +00 33 6 57 60 42 17 (tatoo txt)
Please visit:  http://www.apr-job.com