Re: Remembering Authentication
There's no way to use basic authentication (the stuff inside HTTP) from web pages... you can't tell a browser "use this form to ask your user for passwords". If you want to manage authentication in web pages, you have to build the whole authentication/session management system yourself. Since you don't want to use cookies, you will have to preserve state on the server side and redirect the client to all sorts of ugly URLs with unique IDs embedded inside. Or you could embed the username and password in the URLs, which would probably be dangerous from the security perspective and would probably make users cringe, but would let their browser send that information at each request. BUT if your only objection to basic authentication is the "unfriendly" login box provided by their browser, you should probably accept that the web is not a medium whereby you should expect or try to mold the complete user interface. The popup box that says "Enter password for Bob's Secure Area" might not have your logos and banner ads, but the user will understand what it means. On some browsers they will even be able to do useful things like save that password for future sessions. Sure, you could program this whole thing yourself, but unless you really need a more sophisticated user structure this way really isn't that bad. Remember: "less is more." shimon. On Tue, Oct 17, 2000 at 02:20:22PM -0500, Ian Frawley wrote: > Hi all > > Is it possible to authenticate a user without having to use the unfriendly > login box provided by browsers, without using cookies? > > I have managed to authenticate a user once through some text fields on a > HTML page but unfortunately this does not make the browser remember the > user's authentication information. On subsequent requests to the same > secure area apache requires that the user enters their credentials again. > > Is there a way around this? If so any help would be appreciated. > > Thanks > > Ian
Apache::ASP cookieless sessions question
Hi, Throughout my web pages I provide a link for the user to login, which goes to a username/password check which then forwards the user back to the original page where he clicked "login". The login link is implemented with: login And of course /user/login (an ASP script) will eventually $Response->Redirect() the client to the original URL. The only problem is that if a client's browser has cookies disabled, the ?session-id=blah doesn't get encoded into their URL (thanks to SessionQueryParse) when they first type it the URL. So if they type "www.foo" and click login, it just takes them back to "www.foo" without preserving the session-id, and it looks like they haven't logged in at all (and indeed they are running under a different session-id). If they load "www.foo" and click on a link which I typed in as "www.foo" they stay in the same session because the link becomes "www.foo?session=blah". Then logging in works fine. So, is there a way I can make the Apache::ASP handler (or some other component of Apache) redirect cookieless clients to scripts whose URIs contain a session id? The other related problem is that when a client that allows cookies visits a page for the first time, all their link URLs have session-ids parsed into them unnecessarily. This is the method that I have in mind that I think would resolve these issues. A hit to a web page with session tracking does this: Hit to "www.foo/bar". If client delivers session-id cookie, deliver plain page for cookied clients. If query string contains session-id, deliver a page with session-ids parsed into links for cookieless clients. If client delivers no cookie and session-id is not in URL, set cookie and redirect to self-URL with session-id parsed in. Even this isn't perfect though, since the URI will sometimes unnecessarily contain the session-id value for cookied browsers. This will still contaminate the return_url for my login procedure, but at least the link and image URLs from the first page won't be uglified. The perfect solution would be to redirect the client to the self-URL without the session-id in their query string when *both* a cookie is sent and a session-id is in the query string. Combined with the method above, this would result in a cookied browser doing: 1. user types "www.foo", server receives no cookie 2. server sends cookie and forwards to "www.foo?session-id=blah" 3. server receives cookie and forwards to "www.foo" 4. server delivers plain "www.foo" And a cookieless browser: 1. user types "www.foo", server receives no cookie 2. server sends cookie and forwards to "www.foo?session-id=blah" 3. server receives no cookie and delivers request for "www.foo" with session-ids parsed into all links Basically, the stable cases (sending cookies OR sending ids in query-string) are fine, it's just the cases of neither or both being sent that need to be fixed. So... can I make these sorts of things happen? Should I care? Is there a way I can find out whether the user's browser is cookied for session-id from within the ASP script? Thanks, shimon. p.s. Apache::ASP is great! I love it! What a timesaver and so easy to work with!
can I close the client connection but keep a script running?
I'd like to be able to tell apache to close off its connection with the client but leave the script running. An example use would be for the client to start a time-consuming job on the web server, and let it run without subjecting them to a spinning wait icon for 10 minutes. Also, and perhaps more importantly, I'd like to be able to run the script knowing that it won't be interrupted if the client presses their STOP button. Is there a way to do this from mod_perl and/or Apache::ASP? This feature is implemented in AOLserver API with the "ns_conn close" command. thanks, shimon.
Re: test fails with "[warn] [notice] child_init for process..."
I had similar symptoms this summer while trying to build a mod_perl-enabled apache 1.3.12 on an HP-UX 10.20 box (this was with perl 5.6.0 and mod_perl probably 1.2.4). I don't think anything useful showed up in error_log, but I serendipitously found later that the test httpd *worked* when I ran the test as a non-root user. This leads me to believe that the problem results because of some environment settings, but I am not sure. Also, while this test failed when run as root, I do believe the httpd executable itself (which was subject to tests by a non-root user) worked. So I was content enough to install it. shimon. On Thu, Oct 05, 2000 at 05:39:20PM -0400, Phil Freed wrote: > I've seen this problem reported a half-dozen or so times on this list, but > I cannot seem to find a resolution. I've been trying to install mod_perl , > but "make test" fails consistently. > > I'm using perl v5.6.0 , Solaris 5.7 , apache_1.3.12. > > There are two general classes of failures that I've seen. If I run > perl Makefile.PL \ >EVERYTHING=1 \ >DO_HTTPD=1 \ >USE_APACI=1 \ >APACHE_SRC=/devel/src/apache_1.3.12/src > > I get the following from "make test": > > /devel/src/keep/apache_1.3.12/src/httpd -f `pwd`/t/conf/httpd.conf -X -d > `pwd`/t & > httpd listening on port 8529 > will write error_log to: t/logs/error_log > letting apache warm up...done > /usr/local/bin/perl t/TEST 1 > still waiting for server to warm up... not ok > server failed to start! (please examine t/logs/error_log) at t/TEST line 95. > make: *** [run_tests] Error 9 > > > # cat t/logs/error* > [notice] Destruction->DESTROY called for $global_object > [Thu Oct 5 17:14:39 2000] [warn] [notice] child_init for process 21363, > report any problems to [no address given] > > A 'ps' shows that process 21363 is running, but (no surprise here) it won't > respond to a telnet to port 8259. > > === > > If I add PREP_HTTPD=1 to the initial make line, I get > > /devel/src/keep/apache_1.3.12/src/httpd -f `pwd`/t/conf/httpd.conf -X -d > `pwd`/t & > httpd listening on port 8529 > /bin/sh: /devel/src/keep/apache_1.3.12/src/httpd: not found > will write error_log to: t/logs/error_log > letting apache warm up...done > /usr/local/bin/perl t/TEST 0 > still waiting for server to warm up...not ok > server failed to start! (please examine t/logs/error_log) at t/TEST line 95. > make: *** [run_tests] Error 146 > > > This time there is no httpd process, and nothing in the logfile. > > === > > I assume these two errors are unrelated. I'd like to use the latter, and > manually configure my apache server -- but I'll take whatever I can > get. What am I missing? >
CGI.pm reporting undefined subroutine and script mysteriously failing
I've been working on a Perl module, package CARS::Web, which provides
various important functionality for web development for my group. It
inherits from the CGI module in order to absorb its functionality. (All
functions I added have a standard prefix and my new object data sits in its
own sub-hash, so I don't think there are conflicts.) However, when testing
it aggressively under mod_perl, I sometimes get failure with the following
error message:
Undefined subroutine CARS::Web::select
There is indeed no such subroutine; for a CARS::Web object $w, a user calls
$w->select({-name=>'something'}, 'HTML option tags') to generate a ... block. I do "use CGI '-any'" in the script, so the idea
is that after failing to find a 'select' method in CARS::Web or its
superclass (CGI) Perl looks at AUTOLOAD methods. CARS::Web doesn't have
one, so it goes to CGI.pm's AUTOLOAD method. Normally this method would
look at the requested method ('select'), say "I don't know any methods like
that", and die with the error message above. (Detour: The CGI module uses
this technique as an optimization: it compiles methods as they are requested
in order to reduce startup time.) But since I've used CGI's '-any' pragma,
it is supposed to say "I haven't seen this, but I'll pretend I have and let
it work like any other method." Normally, this happens fine: it properly
synthesizes a method CARS::Web::select which spits out the proper HTML code.
But sometimes, especially during heavy load (simulated by scripts), it
doesn't work right. My browser receives the following (this is according to
netscape or IE view source; the headers *are* sent to the browser):
HTTP/1.1 200 OK
Date: Wed, 23 Aug 2000 18:14:13 GMT
Server: Apache/1.3.12 (Unix) mod_perl/1.24
Connection: close
Content-Type: text/html; charset=iso-8859-1
200 OK
OK
The server encountered an internal error or
misconfiguration and was unable to complete
your request.
Please contact the server administrator,
[EMAIL PROTECTED] and inform them of the time the error occurred,
and anything you might have done that may have
caused the error.
More information about this error may be available
in the server error log.
And the error message "Undefined subroutine CARS::Web::select" is logged in
the error_log. This message is generated inside of CGI.pm's AUTOLOAD
subroutine (It doesn't print a line number but I've looked at the code and
that's the only place such a message is formatted).
The headers are present regardless of the setting of PerlSendHeaders On or
Off.
I can't figure out why this is happening: I am using only scripts and
libraries that I wrote in compliance with all the mod_perl documentation.
Furthermore, this error only shows up sometimes: I am not sure whether it
simply sticks around in an httpd child (this would be *very* bad) or if it's
just intermittent anywhere. Has anyone had a similar error message using
CGI '-any' or when inheriting from CGI? Any mod_perl or CGI.pm wizards care
to propose a hypothesis for why this happens? I need my library to be as
reliable as possible (it will be used heavily) so any suggestions are highly
appreciated.
Thanks,
Shimon Rura
RE: Producing an error page
Jay, although others have recommended you look at the mod_perl guide and
CGI::Carp, I don't think these are exactly what you're looking for. The
errors you are getting are generated because of 'use strict;' and occur at
compile time; CGI::Carp is capable of redirecting errors to the browser (if
you type "use CGI::Carp 'fatalsToBrowser'"). Hence your script doesn't get
to run at all, and it doesn't produce anything on standard output. Your web
server redirects this STDOUT to the web browser and redirects STDERR to its
error log. Also, you never print a valid content-type header on STDOUT so
your web server can't grok it anyway. What you need to do is send your
ERRORS to STDOUT instead of STDERR and precede their output with
"Content-Type: text/plain\n\n". I am not totally sure this is possible
(it's a very odd thing to do) but you might try inserting this at the top of
your script (BEFORE 'use strict;'):
BEGIN { print "Content-Type: text/plain\n\n"; *STDERR = *STDOUT }
This is a BEGIN block which is evaluated at compile time.
I'll give this a try, and you can too. But I wouldn't be surprised if this
just resulted in weirder behavior. Chances are what you want to do isn't
really the best thing for your situation, perhaps you could describe your
reason for wanting this behavior. Good luck!
shimon.
p.s. This wasn't really a mod_perl related question, perhaps this wasn't the
best forum to ask it.
Jay Strauss said:
>
> Hi,
>
> I'm asking this again, due to lack of response (but I can't
> believe no one out
> there knows how to do this).
>
> How do I produce an error page (in HTML), when I call the script
> from a browser,
> that looks just like the error screen I get when I run a script
> at the command
> line?
>
> That is, if I run the following script from the command line:
>
> ---
> #!/usr/bin/perl -w
>
> use strict;
> use diagnostics;
>
> ($first, $second) = @ARGV;
>
> exit;
> ---
>
> I'll get a whole bunch of messages telling me I "use strict" and I have
> variables that I didn't define with "my".
>
> But, if I call it from my browser, I just get back a "Internal
> Server Error"
> page. Instead I want all the diagnostics messages.
>
> Thanks
> Jay
>
> Jay Strauss
> [EMAIL PROTECTED]
> (h) 773.935.5326
> (c) 312.617.0264
RE: DB persistence
It seems to be starting a new connection each time. If you want connection pooling, you should use the Apache::DBI module, which will transparently pool DBI connections for you. Shimon Rura > -Original Message- > From: Pramod Sokke [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, August 16, 2000 2:00 PM > To: [EMAIL PROTECTED] > Subject: DB persistence > > > Hi all, > > I think I misled everybody with my previous question on this topic. To put > it in simple words: > Apache 1.3.12/mod_perl 1.24/Solaris 2.7 > I'm establishing db connection at server startup and the logs indicate > that's done. But in my subsequent calls to 'connect' in my scripts, I see > the same message "Establishing connection to PURCHASEDB:purchasedb" in my > webserver error log. Does this mean it's ignoring the already available db > handle and making fresh connections? > In other words, how do I make sure whether the original handle is used or > if a fresh connection is established? > Any help is greatly appreciated. > > Thanks, > Pramod >
script-specific environment variables?
Hi,
I'm working on updating some disgusting hack CGI scripts to use mod_perl and
DBI. The database backend is Informix, but the web structure is designed to
allow accessing different database configurations from different virtual
hosts. For example, http://dev:9040/ might be integrated with the main
working database, while http://dev:9041/ works with a testing or training
database. This separation is crucial in development and client use.
Unfortunately, Informix and one of our own libraries depends on environment
variables to distinguish this connection information (there is probably a
workaround for DBD::Informix but our library is bad painful legacy code with
awful and immutable API). Therefore, I need to set environment variables,
but the settings need to be somehow localized for each script.
The obvious solution is to put a bunch of assignments to $ENV{'blah'} at the
top of each script. This strikes me as rather ugly though, and forces our
developers to type more.
PerlSetEnv is almost a solution; its failing is that is doesn't fake scope
for environment variables (not that it should). If I could put PerlSetEnv
directives inside of or tags for Apache, and that
forced scoping upon them, that would be perfect.
Perhaps there is some way I can actually use reasonable Perl scoping to set
a variable in the scope of a Virtual Host? If so, then I could just specify
a hash of environment variables called %myEnv in each or
section, and the web scripts could just call a single function
like envImport(%myEnv) at the top. That would be great, as all
virtualHost-specific configuration would exist in Apache configuration
files.
The only other alternative I can think of is to store these settings in a
file and call a function to parse the local configuration file for each
script request. This seems to add a lot of overhead though. Files suck.
Any solutions from the mod_perl gurus out there?
Thanks,
Shimon Rura
CARS Information Systems, Cincinnati, OH
