Re: Another SEGV perl 5.8.0-RC2 apache 1.3.26 mod_perl 1.27
> On Sun, 30 Jun 2002 15:30:18 -0700 (PDT), Doug MacEachern <[EMAIL PROTECTED]> >said: >> #0 0x400d8076 in chunk_free (ar_ptr=0x4016ca40, p=0x82fd0a0) at malloc.c:3097 >> #1 0x400d7f5a in __libc_free (mem=0x82fd0a8) at malloc.c:3023 >> #2 0x8169142 in Perl_safesysfree (where=0x82fd0a8) at util.c:151 >> #3 0x8197ea2 in Perl_sv_clear (my_perl=0x82fc9c8, sv=0x86ed0bc) at sv.c:5049 > hmm, looks like double free of SvPVX. if you could in gdb: > (gdb) up 3 > (gdb) print *sv > (gdb) print *(XPV*)sv->sv_any (gdb) up 3 #3 0x8197fa2 in Perl_sv_clear (my_perl=0x82fcaa8, sv=0x86ed170) at sv.c:5049 5049Safefree(SvPVX(sv)); (gdb) print *sv $1 = {sv_any = 0x8638d10, sv_refcnt = 0, sv_flags = 4194307} (gdb) print *(XPV*)sv->sv_any $2 = {xpv_pv = 0x82fd188 "", xpv_cur = 0, xpv_len = 140741932} -- andreas
Re: Optional HTTP Authentication ?
>From: "Jean-Michel Hiver" <[EMAIL PROTECTED]> > > I *CANNOT* use cookies nor URIs for any kind of session tracking. > Otherwise I don't think I would have posted this message to the list in > the first place :-) > > I agree that HTTP Basic authentication is totally and uterly ugly, but I > am going to have to stick with it no matter what... My problem is: > > How do I tell apache to set the $ENV{REMOTE_USER} variable if the > browser sent the credentials, or leave $ENV{REMOTE_USER} undef > otherwise, without sending a 401 back. I didn't think a browser would send authentication unless the server requested it for an authentication domain. How are you going to get some people to send the credentials and some not unless you use different URLs so the server knows when to request them? Note that you don't have to embed session info here, just add some element to the URL that serves as the point where you request credentials and omit it for people that don't log in. Or redirect to a different vhost that always requires authentication but serves the same data. Les Mikesell [EMAIL PROTECTED]
RES: Header Troubles
> -Mensagem original- > De: Brad W. Galiette [mailto:[EMAIL PROTECTED]] > Enviada em: domingo, 30 de junho de 2002 17:59 > Para: [EMAIL PROTECTED] > Assunto: Header Troubles > > > I am current running mod_perl with PerlSendHeader On; in this manner, the Perl applications that I am running > can post the many headers that are required for proper operation, such as "Set-Cookie", "Location", etc. You can do it better with PerlSendHeader OFF. $r->header_out(Location => '/path') > > However, while my scripts are functioning properly, the Apache error log cites a number of locations as being > "bad headers" when I know for certain that they are HTML, and not header data. I have confirmed that all header > blocks are followed "\r\n\r\n" but still no avail. Any ideas on why Apache is confusing something such as "> > " to be a header? :-P Are you running Apache on Win32? Otherwise, print "\n\n" instead. > > Regards, > Brad Galiette Ricardo Basto
Apache 2.0.40 / modperl-2.0 - Under Cygwin environment
Anyone have any success getting mod_perl 2.0 to compile under Cygwin? I have Apache 2.0.40 compiled and working fine, however, when I point mod_perl at the apache prefix directory and go to build the ld2 compiler cannot find the ap/apr libraries needed to finish the link for the dll. I have found that apr and aprutil are not in the linker path and have added them, however, there is no apache library created that the linker is looking for. Any help here would be greatly appreciated. Thanks, Thomas
Re: Another SEGV perl 5.8.0-RC2 apache 1.3.26 mod_perl 1.27
On Sun, 30 Jun 2002, Andreas J. Koenig wrote: > Program received signal SIGSEGV, Segmentation fault. > 0x400d8076 in chunk_free (ar_ptr=0x4016ca40, p=0x82fd0a0) at malloc.c:3097 > 3097malloc.c: No such file or directory. > (gdb) bt > #0 0x400d8076 in chunk_free (ar_ptr=0x4016ca40, p=0x82fd0a0) at malloc.c:3097 > #1 0x400d7f5a in __libc_free (mem=0x82fd0a8) at malloc.c:3023 > #2 0x8169142 in Perl_safesysfree (where=0x82fd0a8) at util.c:151 > #3 0x8197ea2 in Perl_sv_clear (my_perl=0x82fc9c8, sv=0x86ed0bc) at sv.c:5049 hmm, looks like double free of SvPVX. if you could in gdb: (gdb) up 3 (gdb) print *sv (gdb) print *(XPV*)sv->sv_any might give a hint.
Re: Optional HTTP Authentication ?
Hi, Jean-Michel: the "official" way to retrieve the remote user name under Basic Authentication is to call for $r->connect->user(), or $r->user() in mod_perl 2.0, I think. With a ticket authentication, one gets the user name in the same way only AFTER the access control phase, because it is simulated from the ticket, see e.g. my Apache::CookieAccess source at modperl.home.att.net. BTW, for me, Basic Authnetication is not that ugly, it is surpringly stable (than most of other Apache ideas) since day one. Peter Bi - Original Message - From: "Jean-Michel Hiver" <[EMAIL PROTECTED]> To: "Peter Bi" <[EMAIL PROTECTED]> Cc: "Jean-Michel Hiver" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, June 30, 2002 12:20 PM Subject: Re: Optional HTTP Authentication ? > On Sun 30-Jun-2002 at 10:47:26AM -0700, Peter Bi wrote: > > Please check that the idea of this kind of authentication is to encrypt the > > ticket, instead of a plain session ID. If cookie is not available, having > > it on URI is a good idea. (Then one needs to have all links in a relative > > manner; see the Cookbook). Cookie itself does not make a secure session ID > > or a secure ticket. It is the encryption that does. > > I *CANNOT* use cookies nor URIs for any kind of session tracking. > Otherwise I don't think I would have posted this message to the list in > the first place :-) > > I agree that HTTP Basic authentication is totally and uterly ugly, but I > am going to have to stick with it no matter what... My problem is: > > How do I tell apache to set the $ENV{REMOTE_USER} variable if the > browser sent the credentials, or leave $ENV{REMOTE_USER} undef > otherwise, without sending a 401 back. > > Cheers, > -- > IT'S TIME FOR A DIFFERENT KIND OF WEB > > Jean-Michel Hiver - Software Director > [EMAIL PROTECTED] > +44 (0)114 255 8097 > > VISIT HTTP://WWW.MKDOC.COM >
Header Troubles
I am current running mod_perl with PerlSendHeader On; in this manner, the Perl applications that I am running can post the many headers that are required for proper operation, such as "Set-Cookie", "Location", etc. However, while my scripts are functioning properly, the Apache error log cites a number of locations as being "bad headers" when I know for certain that they are HTML, and not header data. I have confirmed that all header blocks are followed "\r\n\r\n" but still no avail. Any ideas on why Apache is confusing something such as ">" to be a header? :-P Regards, Brad Galiette
Re: Optional HTTP Authentication ?
Jean-Michel Hiver <[EMAIL PROTECTED]> writes: > > Why is a user "hacking" their URLs? > > I can answer that. http://www.useit.com/alertbox/990321.html > > > * a domain name that is easy to remember and easy to spell > * short URLs > * easy-to-type URLs > * URLs that visualize the site structure > * URLs that are "hackable" to allow users to move to higher levels of > the information architecture by hacking off the end of the URL > * persistent URLs that don't change > I generly agree with alertbox, and I agree in this instance. > i.e. http://bigmegamarket.com/grocery/fruits/bananas/ is cool, > http://bigmegamarket.com/index.pl?id=231223412&sid=56765454151 is not. Both true. However, if the structure were http://bigmegamarket.com/index.pl/56765454151/grocery/fruits/bananas, say, with the number being the session ID, the URL then is hackable within that (good) definition. > Again it doesn't always make implementation easy :-/ True enough; and my proposal is a bit harder to implement. I'm a big fan of cookies myself, for the thing they were made for, namely session tracking. I share your frustration :-(. -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
Re: [OT] Optional HTTP Authentication ?
> In one of the earlier stages of processing - maybe a FixupHandler or ? a > AuthenHandler might be appropriate - you can do something like this: > > my $a = $r->header_in('Authorization'); > $a =~ s/^Basic (.*)/$1/; > my( $user, $pass ) = split(':', decode_base64( $a ) ); > > if( ) { > $ENV{REMOTE_USER} = $user; > } OK, I got this working using a fixup handler BUT there is a nasty trap. It happens that the environment variables which you set from Perl aren't inherited from sub-processes... which means that this technique is fine if the script that comes after authentication runs under Apache::Registry. Unfortunately, I might need the script to run under mod_cgi... I couldn't find how to tell the apache server to set environmental variables in the mod_perl pocket reference, anyone has got an idea? Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
On Sun 30-Jun-2002 at 10:47:26AM -0700, Peter Bi wrote: > Please check that the idea of this kind of authentication is to encrypt the > ticket, instead of a plain session ID. If cookie is not available, having > it on URI is a good idea. (Then one needs to have all links in a relative > manner; see the Cookbook). Cookie itself does not make a secure session ID > or a secure ticket. It is the encryption that does. I *CANNOT* use cookies nor URIs for any kind of session tracking. Otherwise I don't think I would have posted this message to the list in the first place :-) I agree that HTTP Basic authentication is totally and uterly ugly, but I am going to have to stick with it no matter what... My problem is: How do I tell apache to set the $ENV{REMOTE_USER} variable if the browser sent the credentials, or leave $ENV{REMOTE_USER} undef otherwise, without sending a 401 back. Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: Propogating Errors / E-Toys
F. Xavier Noria wrote: > I remember the article has a comment regarding a gotcha of the Error > module that causes memory leaks, but you didn't go into details there. We've actually discussed this on the list. It has to do with closures. Matt gave a presentation about exception handling which covers it and shows a workaround. You can see it here: http://axkit.org/docs/presentations/tpc2001/ - Perrin
Re: IPC::Open2 under mod_perl in Mac OS X
John Siracusa wrote: > On 6/30/02 2:06 AM, Stas Bekman wrote: > >>John Siracusa wrote: >> >>>(I'm not sure if this is a mod_perl thing of a Mac OS X bug, so I'm posting >>>it to both lists. Redirect follow-ups as appropriate.) >>> >>>open2() doesn't seem to work for me when running under mod_perl in Mac OS X. >> >>It's not a bug in MacOSX, it simply doesn't work with mod_perl. > > > I can't post a direct example now (because I don't have access to the > machine from here), but I'm pretty sure I do have an example of open2() > working under mod_perl in Linux--in a perl that is not compiled with sfio. > That's why I thought it was a Mac OS X bug. > > The mod_perl guide talks about the output from system(), exec(), and open(F, > "| ...") not being sent to the browser, but it doesn't mention open2(). In > the case of open2(), the input and output is supposed to be tied to > filehandles that I supply, not connected to mod_perl's (tied?) STDOUT that > eventually goes to the browser. > > So could you clarify why open2() is not expected to work under mod_perl, and > why it seems to work for me in Linux? (I'll post the working Linux example > once I can confirm it on Monday.) I should have said that your example doesn't work on linux with mod_perl with sfio-enabled perl, since I've tried it and it didn't work. That's why I've assumed that it's not MacOSX problem. I really didn't have a chance to investigate why it doesn't work. I've just tried other alternatives which worked so I've posted them, since I thought that it was important to you to have a working solution. Feel free to debug the whole thing and post the details of what exactly doesn't work and if possible how to fix that. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Optional HTTP Authentication ?
Please check that the idea of this kind of authentication is to encrypt the ticket, instead of a plain session ID. If cookie is not available, having it on URI is a good idea. (Then one needs to have all links in a relative manner; see the Cookbook). Cookie itself does not make a secure session ID or a secure ticket. It is the encryption that does. Peter Bi - Original Message - From: "Jean-Michel Hiver" <[EMAIL PROTECTED]> To: "Randal L. Schwartz" <[EMAIL PROTECTED]> Cc: "Jean-Michel Hiver" <[EMAIL PROTECTED]>; "Andrew Moore" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, June 30, 2002 10:07 AM Subject: Re: Optional HTTP Authentication ? > > What? The EU is going to make cookies *illegal*? I highly doubt > > this. > > Sorry, I am neither the lawyer nor the client, so I can't tell you... > I know it's really stupid, but I am going to have to deal without > cookies. > > > Jean-Michel> * For usability reasons encoding session IDs on URIs would be really > > Jean-Michel> bad... users needs to be able to 'hack' the URIs without f***ing their > > Jean-Michel> sessions! > > > > Why is a user "hacking" their URLs? > > I can answer that. http://www.useit.com/alertbox/990321.html > > > * a domain name that is easy to remember and easy to spell > * short URLs > * easy-to-type URLs > * URLs that visualize the site structure > * URLs that are "hackable" to allow users to move to higher levels of > the information architecture by hacking off the end of the URL > * persistent URLs that don't change > > > i.e. http://bigmegamarket.com/grocery/fruits/bananas/ is cool, > http://bigmegamarket.com/index.pl?id=231223412&sid=56765454151 is not. > > Again it doesn't always make implementation easy :-/ > > > Jean-Michel> Therefore I have to use HTTP authentication... > > > > Even though the user/password is transmitted *in the clear* on > > *every single hit*, because you can't just use a session identifier? > > This is so very wrong from a security perspective. > > I have to agree with you on that. Cookies are probably far better than > HTTP authentication. But I cannot use cookies. Period. I wish I could, > because this was what I did in the first place and it was working fine! > > Cheers, > -- > IT'S TIME FOR A DIFFERENT KIND OF WEB > > Jean-Michel Hiver - Software Director > [EMAIL PROTECTED] > +44 (0)114 255 8097 > > VISIT HTTP://WWW.MKDOC.COM
Re: Propogating Errors / E-Toys
On Sun, 30 Jun 2002 12:58:08 -0400 Perrin Harkins <[EMAIL PROTECTED]> wrote: : Well, naturally the answer is "it depends." Most database errors can't : be gracefully recovered from, so we would let them propagate up. If it : was possible for a database error to be caused by user input (say, a : duplicate login name) that would need to be caught and handled. It : would also be caught if any special cleanup of non-database resources : was needed. Excellent message, thank you for sharing those experiences once again! I remember the article has a comment regarding a gotcha of the Error module that causes memory leaks, but you didn't go into details there. I took note of that and am using eval instead of the try/catch syntax since I do not understand what the problem is and cannot program avoiding it for sure... I would appreciate very much if you could give further details (maybe a pointer somewhere) on what origines the leak and which was your style writing try/catch blocks once aware of the problem. Thanks, and best regards from template Barcelona, -- fxn
Re: IPC::Open2 under mod_perl in Mac OS X
On 6/30/02 2:06 AM, Stas Bekman wrote: > John Siracusa wrote: >> (I'm not sure if this is a mod_perl thing of a Mac OS X bug, so I'm posting >> it to both lists. Redirect follow-ups as appropriate.) >> >> open2() doesn't seem to work for me when running under mod_perl in Mac OS X. > > It's not a bug in MacOSX, it simply doesn't work with mod_perl. I can't post a direct example now (because I don't have access to the machine from here), but I'm pretty sure I do have an example of open2() working under mod_perl in Linux--in a perl that is not compiled with sfio. That's why I thought it was a Mac OS X bug. The mod_perl guide talks about the output from system(), exec(), and open(F, "| ...") not being sent to the browser, but it doesn't mention open2(). In the case of open2(), the input and output is supposed to be tied to filehandles that I supply, not connected to mod_perl's (tied?) STDOUT that eventually goes to the browser. So could you clarify why open2() is not expected to work under mod_perl, and why it seems to work for me in Linux? (I'll post the working Linux example once I can confirm it on Monday.) -John
Re: .cgi with ModPerl
> "ebay" == ebay writes: ebay> I am setting up a server so that all my scripts have .cgi extentions. ebay> It would be nice if I could just add some directives in the httpd.conf ebay> that will have all my virtual hosts use modPerl for any files with ebay> either a .pl or a .cgi extention. The reason I prefer this method is ebay> that I have a couple scripts that I load in my httpdocs directory (the ebay> site home page is a script) So this is what I did: ebay> Commented out: AddHandler cgi-script .cgi ebay> Added the following: ebay> ebay> ebay> SetHandler perl-script ebay> PerlHandler Apache::PerlRun ebay> Options +ExecCGI ebay> allow from all ebay> PerlSendHeader On ebay> ebay> try FilesMatch instead and see if that works ebay> What I found is that when I only had this code only outside of the ebay> VirtualHost configurations, my test script indicated .pl was running in ebay> modPerl but .cgi wasn't. I only could get .cgi to run in mod_Perl by ebay> copying this code inside of each of the VirtualHost configurations. ebay> Obviously I'm not an Apache config expert but one thing that also struck ebay> me strange is that while this code clearly indicates how to handle .pl ebay> and .cgi file extentions, prior to adding this, I could not find ebay> anywhere in httpd.conf where it maps .cgi files in this same way. The ebay> only code I could find is AddHandler cgi-script .cgi but shouldn't there ebay> be some additional corresponding code like PerlHandler Appache::Mod_CGI, ebay> Options +ExecCGI, etc.?? Also, how does appache know which module to ebay> use for ScriptAlias directories? I left the ScriptAlias directives in ebay> for the cgi-bin director and didn't change them to just Alias directives ebay> and it works fine but I guess that means a filematch directive overrides ebay> a ScriptAlias directive? ebay> A bit confused. Anyway, is the above method for achieving what I want ebay> an acceptable and secure/safe way to handle it? ebay> Thanks -- XEmacs Advocate | I've seen things you people wouldnt believe. FreeBSD Devote | Attack ships on fire of the shores of orion ... Perl Hacker | All those moments will be lost in time, Apache God | like tears in the rain. Time to die.. roy batty - bladerunner
Re: Optional HTTP Authentication ?
> What? The EU is going to make cookies *illegal*? I highly doubt > this. Sorry, I am neither the lawyer nor the client, so I can't tell you... I know it's really stupid, but I am going to have to deal without cookies. > Jean-Michel> * For usability reasons encoding session IDs on URIs would be really > Jean-Michel> bad... users needs to be able to 'hack' the URIs without f***ing their > Jean-Michel> sessions! > > Why is a user "hacking" their URLs? I can answer that. http://www.useit.com/alertbox/990321.html * a domain name that is easy to remember and easy to spell * short URLs * easy-to-type URLs * URLs that visualize the site structure * URLs that are "hackable" to allow users to move to higher levels of the information architecture by hacking off the end of the URL * persistent URLs that don't change i.e. http://bigmegamarket.com/grocery/fruits/bananas/ is cool, http://bigmegamarket.com/index.pl?id=231223412&sid=56765454151 is not. Again it doesn't always make implementation easy :-/ > Jean-Michel> Therefore I have to use HTTP authentication... > > Even though the user/password is transmitted *in the clear* on > *every single hit*, because you can't just use a session identifier? > This is so very wrong from a security perspective. I have to agree with you on that. Cookies are probably far better than HTTP authentication. But I cannot use cookies. Period. I wish I could, because this was what I did in the first place and it was working fine! Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: Propogating Errors / E-Toys
Richard Clarke wrote: > Using Perrin's article on E-Toys is perhaps a good place to start. In the > Model object which performs various DB procedures, what actions were taken > if for some reason the connection to the database failed or if an SQL error > happened? Was the whole "execute()" block put in an eval procedure and then > a generic error page produced; Or were either per procedure evals or > Exception objects used to propogate specific errors up to the control object > so that it could display errors in the current page/view? Well, naturally the answer is "it depends." Most database errors can't be gracefully recovered from, so we would let them propagate up. If it was possible for a database error to be caused by user input (say, a duplicate login name) that would need to be caught and handled. It would also be caught if any special cleanup of non-database resources was needed. Errors that propagate up are caught by an eval wrapping the whole handler method which issues a rollback to the database, logs the error, and prints either a pretty error page or a stack trace depending on the current debug settings. Here's an excerpt from the documentation I wrote for our exception base class. This uses the try/catch syntax from Error.pm. =head1 HANDLING DBI ERRORS Since DBI errors are the most common source of exceptions in our application, I'm giving them special treatment here. Because we are planning to use the RaiseError option of DBI, you can expect DBI to die whenever it hits a problem, as opposed to returning an undef value that you have to check for. This means that most of the time you don't need to do anything special for handling DBI errors. They will propagate up and be caught at the top level. DBI exceptions will be propagated as instances of the Error::Simple class. You can catch your own exceptions without catching the DBI exceptions by catching specific classes other than Error::Simple. try { # lookup password in Oracle my $sth = $dbh->prepare_cached($sql_query); $sth->execute($bind_value); if (!$sth->rows) { # should have matched something throw ESF::Error::User::BogusPassword -text $password; } $ary_ref = $sth->fetchrow_arrayref; # ... etc. ... } catch ESF::Error::User::BogusPassword with { # handle this error }; # <-- don't forget! It's okay to use transactions, and to put in your C<$dbh->commit> statement at the end assuming everything will work. If DBI throws an exception that propagates to the top without being caught, we will automatically issue a C<$dbh->rollback> command. Sometimes, you may want to catch a specific DBI error. Be careful when doing this, because you need to know the error number or text of the error message in order to trap the right exception. DBI's raise error setting will cause it to fill the text attribute of the Error::Simple objects it throws with the message given by Oracle, so if you want to trap errors of type ORA-172, you can do this: try { my $sth = $dbh->prepare_cached($sql_query); $sth->execute($bind_value); } catch Error::Simple with { my $err = shift; if ($err->text() =~ m/ORA-172/) { # handle the error here } else { # let this error propagate $err->throw(); } }; # <-- don't forget! - Perrin
Propogating Errors / E-Toys
List, Without wanting to fire up a huge thread about MVC seperation etc etc. I just wondered if someone would share their expertise on the following question. Using Perrin's article on E-Toys is perhaps a good place to start. In the Model object which performs various DB procedures, what actions were taken if for some reason the connection to the database failed or if an SQL error happened? Was the whole "execute()" block put in an eval procedure and then a generic error page produced; Or were either per procedure evals or Exception objects used to propogate specific errors up to the control object so that it could display errors in the current page/view? Richard
Re: Optional HTTP Authentication ?
> "Jean-Michel" == Jean-Michel Hiver <[EMAIL PROTECTED]> writes: Jean-Michel> * For political reasons and compliance with future european legislation Jean-Michel> I cannot use cookies, What? The EU is going to make cookies *illegal*? I highly doubt this. Jean-Michel> * For usability reasons encoding session IDs on URIs would be really Jean-Michel> bad... users needs to be able to 'hack' the URIs without f***ing their Jean-Michel> sessions! Why is a user "hacking" their URLs? Jean-Michel> Therefore I have to use HTTP authentication... Even though the user/password is transmitted *in the clear* on *every single hit*, because you can't just use a session identifier? This is so very wrong from a security perspective. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Another SEGV perl 5.8.0-RC2 apache 1.3.26 mod_perl 1.27
> On Sat, 29 Jun 2002 16:48:57 -0700 (PDT), Doug MacEachern <[EMAIL PROTECTED]> >said: > On Mon, 24 Jun 2002, Andreas J. Koenig wrote: >> This stack trace is all I have. I cannot reproduce this SEGV at will, >> so it will be difficult to obtain additional information. All I can do >> is let the webserver run in -X mode and wait. I have no hints (yet) >> what kind of request triggers it. > ... >> #6 0x820baa2 in PerlIO_cleanup (my_perl=0x82fc9c8) at perlio.c:2124 >> #7 0x810d298 in perl_destruct (my_perl=0x82fc9c8) at perl.c:490 >> #8 0x8099039 in perl_shutdown (s=0x82f140c, p=0x88f9c24) at mod_perl.c:294 >> #9 0x809b373 in perl_child_exit (s=0x82f140c, p=0x88f9c24) at mod_perl.c:958 >> #10 0x809afce in perl_child_exit_cleanup (data=0x88f9db4) at mod_perl.c:926 > looks like a leaked PerlIO* from Request.xs, as this is happening when the > child is killed by apache (e.g. MaxRequestsPerChild reached). > patch below may cure, seems like a better approach in any case. > it is ugly here because the FILE was opened by an apache api function > which will close it when the request pool is cleared, so we must dup. Thanks Doug, another great step forward! I can confirm that setting MaxRequestPerChild to 0 is an excellent way to avert the SEGV. But unfortunately your patch doesn't cure completely. This is the latest stack trace I got after I applied your patch. It was triggered by a static file request that did not call a mod_perl handler. MaxRequestPerChild was set to 3. Program received signal SIGSEGV, Segmentation fault. 0x400d8076 in chunk_free (ar_ptr=0x4016ca40, p=0x82fd0a0) at malloc.c:3097 3097malloc.c: No such file or directory. (gdb) bt #0 0x400d8076 in chunk_free (ar_ptr=0x4016ca40, p=0x82fd0a0) at malloc.c:3097 #1 0x400d7f5a in __libc_free (mem=0x82fd0a8) at malloc.c:3023 #2 0x8169142 in Perl_safesysfree (where=0x82fd0a8) at util.c:151 #3 0x8197ea2 in Perl_sv_clear (my_perl=0x82fc9c8, sv=0x86ed0bc) at sv.c:5049 #4 0x819831d in Perl_sv_free (my_perl=0x82fc9c8, sv=0x86ed0bc) at sv.c:5192 #5 0x818d4d8 in do_clean_all (my_perl=0x82fc9c8, sv=0x86ed0bc) at sv.c:400 #6 0x818d147 in S_visit (my_perl=0x82fc9c8, f=0x818d47c ) at sv.c:292 #7 0x818d4fe in Perl_sv_clean_all (my_perl=0x82fc9c8) at sv.c:418 #8 0x810ddd5 in perl_destruct (my_perl=0x82fc9c8) at perl.c:771 #9 0x8099039 in perl_shutdown (s=0x82f140c, p=0x8903d6c) at mod_perl.c:294 #10 0x809b373 in perl_child_exit (s=0x82f140c, p=0x8903d6c) at mod_perl.c:958 #11 0x809afce in perl_child_exit_cleanup (data=0x8903efc) at mod_perl.c:926 #12 0x80ddc8e in run_cleanups () #13 0x80dc4bd in ap_clear_pool () #14 0x80dc531 in ap_destroy_pool () #15 0x80e945b in clean_child_exit () #16 0x80ec707 in child_main () #17 0x80eccb0 in make_child () #18 0x80ece09 in startup_children () #19 0x80ed466 in standalone_main () #20 0x80edc33 in main () #21 0x4009698b in __libc_start_main (main=0x80ed8dc , argc=4, argv=0xbcc4, init=0x807a6f8 <_init>, fini=0x828da5c <_fini>, rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbcbc) at ../sysdeps/generic/libc-start.c:92 -- andreas
Re: Trouble making mod_perl
Got it up and running. On Sunday 30 June 2002 13:17, Per Einar Ellefsen wrote: > At 13:06 30.06.2002, Eric wrote: > >Greetings! > > > >I've downloaded mod-perl-1.99_02 and am having trouble getting it to make. > > What Apache version are you using? 1.99_02 is pretty old, you should get > 1.99_04 to work with the latest Apache.
Re: Trouble making mod_perl
Per, Apache 2.0.39. I'll hunt for 1.99_04 and try that. On Sunday 30 June 2002 13:17, Per Einar Ellefsen wrote: > At 13:06 30.06.2002, Eric wrote: > >Greetings! > > > >I've downloaded mod-perl-1.99_02 and am having trouble getting it to make. > > What Apache version are you using? 1.99_02 is pretty old, you should get > 1.99_04 to work with the latest Apache.
Re: Trouble making mod_perl
At 13:06 30.06.2002, Eric wrote: >Greetings! > >I've downloaded mod-perl-1.99_02 and am having trouble getting it to make. What Apache version are you using? 1.99_02 is pretty old, you should get 1.99_04 to work with the latest Apache. -- Per Einar Ellefsen [EMAIL PROTECTED]
Trouble making mod_perl
Greetings! I've downloaded mod-perl-1.99_02 and am having trouble getting it to make. perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2 works fine. My problem is with make && make test. I get the following: cc -I/home/eric/Downloads/Apache/mod_perl-1.99_02/src/modules/perl -I/home/eric/Downloads/Apache/mod_perl-1.99_02/xs -I/usr/local/apache2/include -fno-strict-aliasing -I/usr/lib/perl5/5.6.1/i586-linux/CORE -DMOD_PERL -O2 -pipe -fPIC \ -c modperl_bucket.c && mv modperl_bucket.o modperl_bucket.lo modperl_bucket.c:52: incompatible types in initialization modperl_bucket.c:52: initializer element is not constant modperl_bucket.c:52: (near initialization for `modperl_bucket_sv_type.is_metadata') modperl_bucket.c:53: warning: initialization from incompatible pointer type modperl_bucket.c:54: warning: initialization from incompatible pointer type modperl_bucket.c:55: warning: initialization from incompatible pointer type modperl_bucket.c:56: warning: initialization from incompatible pointer type make[1]: *** [modperl_bucket.lo] Error 1 make[1]: Leaving directory `/home/eric/Downloads/Apache/mod_perl-1.99_02/src/modules/perl' make: *** [modperl_lib] Error 2 Any ideas what I'm doing wrong? Or, can someone point me to a source where I can make this work? Any help would be greatly appreciated. Thanks!
Re: param trouble
> basically the whole thing is starting to bite its own tail and i would be very > happy if anybody could give me any pointers as to why CGI won't read my data > from the PerlInitHandler or after Apache::Request read them. I seem to remember a post where someone had trouble because he was trying to access POSTed data twice... problem was that once the POSTed data was read, that was it. Maybe it's something similar? Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
> It seems that Apache::AuthCookie allows a way to make areas > to which one can authenticate if s/he wants. I suppose that > then in those areas you can tell if the user is logged in > and affect the pages if so. Indeed the best option would be to be using one of the Apache::Session module and use the provided hash to store the login information. I have read the whole portion of the eagle book dedicated to authentication / authorization before posting my crack-smoked question to the list ;-) Unfortunatly: * For political reasons and compliance with future european legislation I cannot use cookies, * For usability reasons encoding session IDs on URIs would be really bad... users needs to be able to 'hack' the URIs without f***ing their sessions! Therefore I have to use HTTP authentication... Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: [OT] Optional HTTP Authentication ?
> Oh, I don't know, I think the poster was asking about how to produce this > effect with mod_perl. He wants to know *whether* a login was provided, even > on a *non-protected* page. That would let you say (while serving any old > page): > > if( $ENV{REMOTE_USER} eq 'admin' ) { > $r->print('Yo, you can do extra kewl stuff here.'); > } Yes, that is quite the case. > In one of the earlier stages of processing - maybe a FixupHandler or ? a > AuthenHandler might be appropriate - you can do something like this: > > my $a = $r->header_in('Authorization'); > $a =~ s/^Basic (.*)/$1/; > my( $user, $pass ) = split(':', decode_base64( $a ) ); > > if( ) { > $ENV{REMOTE_USER} = $user; > } > > So, now you can tell later during the request with a username/password was > offered (and you know it was a valid login/pass combo). That's very interesting! I don't think I can use an auth handler because then I would have to password protect the whole site (which I don't want to). I want to have just ONE page which is password protected (i.e. /login.html). The page would just be a redirect, but once the user entered his credentials then the browser should send them on the whole site and then I could do the following: /foo/properties.html IF authenticated IF authorized => trigger /foo/properties.html ELSE => send custom error page ELSE redirect to /login.html?from= Anyway I'm going to try that fixup handler thingie and I'll tell you how it goes :-) Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
RE: Image manipulation recommendation?
I couldn't get the requisites for the gd.pm and related modules to work on Windows. Although these things apparently have worked great for years on UNIX, they may have problems on Windows 2000 servers. I had to go to a purchased Java product that is accessible via a servlet to get graphs generated. -- For clarification, and to encourage others to at least try GD and or Image::Magick under Windoze, BOTH packages work as advertised with that operating system. I have both running quite happily on my development machine (Windows 2000). I did encounter some problems installing both, but these disappeared when I used the PPM's (ActiveState / TheoryX5) as opposed to trying to compile manually. You must understand that both packages are complex, you need patience and persistence - but it's worth it in the end. Jonathan M. Hollin WYPUG - http://wypug.p.org/
Re: [OT] Optional HTTP Authentication ?
> This seems a little off topic. I think this is an architecture question, not > a mod perl question. Well, a bit of both I guess. > Basically, you want all you protected files to be located in /protected or > some other directory... No that is not possible. I am running a web application, there are no such things as 'files' (everything is done using PATH_INFO), only locations. Users can create as many locations as they want (i.e. /foo/bar/) and administrate them using URIs such as /foo/bar/properties.html, /foo/bar/contents.html, etc. There are some locations which do not need to be protected, i.e. /foo/bar/ /foo/bar/print.html /foo/bar/dc.xml /foo/bar/rss100.rdf But some others need to, like: /foo/bar/properties.html /foo/bar/contents.html /foo/bar/move.html etc. I want to use HTTP authentication for that, but of course I cannot password protect the whole site, because public users would not be so happy! Any ideas? -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: Need Porting Sanity Check
Hi there, Sorry there's a lot to digest all at once in your message, but here's one tip: On Sat, 29 Jun 2002, Jeff wrote: > - Use 'open my $fh, $filename or die $!; wherever I open files Use Symbol::gensym if you can, it makes dealing with files much less accident prone. 73, Ged.