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:
a href="/user/login?return_url=%=$Server-URLEncode($ENV{REQUEST_URI})%"
login
/a
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?
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
