cvs commit: modperl-2.0/lib/Apache compat.pm
stas2002/06/30 21:54:09
Modified:lib/Apache compat.pm
Log:
make sure that the call is made as Apache-module($name) (2 arguments)
and not Apache::module($name)
Revision ChangesPath
1.62 +1 -0 modperl-2.0/lib/Apache/compat.pm
Index: compat.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
retrieving revision 1.61
retrieving revision 1.62
diff -u -r1.61 -r1.62
--- compat.pm 4 Jun 2002 12:40:53 - 1.61
+++ compat.pm 1 Jul 2002 04:54:09 - 1.62
-92,6 +92,7
sub module {
require Apache::Module;
+die 'Usage: Apache-module($name)' if _ != 2;
return Apache::Module::loaded($_[1]);
}
cvs commit: modperl-2.0/t/response/TestAPI module.pm
stas2002/06/30 22:15:28
Modified:src/modules/perl modperl_util.c
t/response/TestAPI module.pm
Log:
modperl_perl_module_loaded should return FALSE when the argument is
+ add a sub-test to cover this case
Revision ChangesPath
1.48 +1 -1 modperl-2.0/src/modules/perl/modperl_util.c
Index: modperl_util.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_util.c,v
retrieving revision 1.47
retrieving revision 1.48
diff -u -r1.47 -r1.48
--- modperl_util.c21 Jun 2002 00:44:24 - 1.47
+++ modperl_util.c1 Jul 2002 05:15:28 - 1.48
-602,7 +602,7
MP_INLINE int modperl_perl_module_loaded(pTHX_ const char *name)
{
-return gv_stashpv(name, FALSE) ? 1 : 0;
+return (*name gv_stashpv(name, FALSE)) ? 1 : 0;
}
/* same as Symbol::gensym() */
1.8 +4 -1 modperl-2.0/t/response/TestAPI/module.pm
Index: module.pm
===
RCS file: /home/cvs/modperl-2.0/t/response/TestAPI/module.pm,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- module.pm 19 May 2002 19:10:45 - 1.7
+++ module.pm 1 Jul 2002 05:15:28 - 1.8
-18,7 +18,7
my $cfg = Apache::Test::config();
-plan $r, tests = 13;
+plan $r, tests = 14;
my $top_module = Apache::Module-top_module;
-91,6 +91,9
#bogus
ok t_cmp(0, Apache::Module::loaded('Apache__Module_foo.foo'),
Apache::Module::loaded('Apache__Module_foo.foo'));
+
+ok t_cmp(0, Apache::Module::loaded(''),
+ Apache::Module::loaded(''));
Apache::OK;
}
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.
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: 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 ?
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 a href=/admin/extra kewl stuff/a 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( check the username/password as you wish ) {
$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=uri
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: 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: 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
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: 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]
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
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: 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 do_clean_all) 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 main, 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: 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] URL: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!
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: 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
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 cite * 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 /cite i.e. http://bigmegamarket.com/grocery/fruits/bananas/ is cool, http://bigmegamarket.com/index.pl?id=231223412sid=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: .cgi with ModPerl
ebay == ebay Jeff 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 IfModule mod_perl.c ebay Files ~ (\.pl|\.cgi) ebay SetHandler perl-script ebay PerlHandler Apache::PerlRun ebay Options +ExecCGI ebay allow from all ebay PerlSendHeader On ebay /Files ebay /IfModule 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: 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: 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: 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 cite * 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 /cite i.e. http://bigmegamarket.com/grocery/fruits/bananas/ is cool, http://bigmegamarket.com/index.pl?id=231223412sid=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: 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: 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: 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: [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( check the username/password as you wish ) {
$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 ?
Jean-Michel Hiver [EMAIL PROTECTED] writes: Why is a user hacking their URLs? I can answer that. http://www.useit.com/alertbox/990321.html cite * 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 /cite 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=231223412sid=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
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 arefollowed "\r\n\r\n" but still no avail. Any ideas on why Apache is confusing something such as "BRBR" to be a header? :-P Regards, Brad Galiette
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
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.
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
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 BRBR to be a header? :-P Are you running Apache on Win32? Otherwise, print \n\n instead. Regards, Brad Galiette Ricardo Basto
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]
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
