Re: coderef as arg to $r-custom_response(...)
From: [EMAIL PROTECTED] (Randal L. Schwartz)
The docs hint that I can use whatever I would put after ErrorDocument
as the arg to custom_response, but also suggest that I can put "a
module" there. Does that mean it's the same style of argument as a
-pushhandler(), where I can also put a coderef?
In Chapter Nine, there are other possibilities. Would you wish to:
set_handlers()
If you would like to change the list of handlers configured for the current
request, you can change it with set_handlers(). This method takes two
arguments, the name of the handler you wish to change, and an array
reference pointing to one or more references to the handler subroutines you
want to run for that phase. If any handlers were previously defined, such as
with a Perl*Handler directive, they are replaced by this call. You can
provide a second argument of undef if you with to remove all handlers for
that phase.
Examples:
$r-set_handlers(PerlAuthenHandler = [\auth_one, \auth_two]);
$r-set_handlers(PerlAuthenHandler = undef);
Just a thought?
Bill Jones * Systems Programmer * http://www.fccj.org/cgi/mail?sneex
(' Running -
//\ Perl, Apache, MySQL, PHP3,
v_/_ Ultra 10, LinuxPPC, BeOS...
Re: coderef as arg to $r-custom_response(...)
"Bill" == Bill Jones [EMAIL PROTECTED] writes:
From: [EMAIL PROTECTED] (Randal L. Schwartz)
The docs hint that I can use whatever I would put after ErrorDocument
as the arg to custom_response, but also suggest that I can put "a
module" there. Does that mean it's the same style of argument as a
- pushhandler(), where I can also put a coderef?
Bill In Chapter Nine, there are other possibilities. Would you wish to:
Bill set_handlers()
No, that's not going to work. If I push a content handler, but then
error out, it'll go to the *error* handler, not the content handler.
And for those following along, after further study in the source, it
looks like custom_response can be only one of three things: a string,
an internal URL (internal redirect) or an external URL (external
redirect on error). Same thing as a "ErrorDocument" directive.
So, I'm punting. When I get an error, I have to redirect to a URL,
which then has to start all over figuring out why they were sent
there. Which is not totally bad, because I have to ask the user some
questions in a form, and I need to reevaluate why they might be there
on the return trip anyway in case the world has changed out from under
me.
I *am* generating the URL dynamically though... check this out so far.
Basically, I want to let an area be visited by my friends, but have
each of them generate a unique user/password without me intervening.
So, I set up a file Friends that looks like:
[EMAIL PROTECTED] programs,pictures
[EMAIL PROTECTED] programs
and then an .htaccess that looks like:
PerlAuthenHandler Stonehenge::RestrictToList
AuthName Friends
AuthType Basic
require programs
and then that triggers the handler, which initially will auth-error
out to the CGI I'm still writing. The CGI will interact to get a
email addr, username, and password, and then email a URL-to-visit as a
confirmation. (A password cannot be mailed to an already visited
user, or to a user not on the list, so we have very little mischief
possible. Someone with access to the mailing list could pre-trigger
the confirmation messages, but that'd be pretty visible.) Prior to
confirmation, the CGI updates the file to:
[EMAIL PROTECTED] programs,pictures billuser 118cdaPNTw2.2-128374kfhasf7s8d
[EMAIL PROTECTED] programs
where 118... is the crypted selected passwd, and 1283... is the secret
in the URL that must be visited (mailed to [EMAIL PROTECTED]). When that
URL of /cgi/confirm?secret=1283... is visited, the file is updated to:
[EMAIL PROTECTED] programs,pictures billuser 118cdaPNTw2.2
[EMAIL PROTECTED] programs
and then the handler will let bill in as billuser, but not doug,
because he's not gone through the process yet. Here's the handler
currently. (And yes, this is for my next WebTechniques column... :)
## PerlAuthenHandler Stonehenge::RestrictToList
package Stonehenge::RestrictToList;
use strict;
use vars qw($VERSION);
$VERSION = (qw$Revision: 1.2 $ )[-1];
## config
my $DIR = "/home/merlyn/Web/RestrictToList";
## end config
use Apache::Constants qw(:common);
use Apache::URI;
use Apache::File;
sub handler {
use Stonehenge::Reload; goto handler if Stonehenge::Reload-reload_me;
my $r = shift;
my $log = $r-log;
my $sent_pw = do {
my ($result,$pw) = $r-get_basic_auth_pw;
return $result unless $result == OK;
$pw;
};
my $sent_user = $r-connection-user;
my $auth_name = $r-auth_name;
my $db_handle = do {
my $name = $auth_name;
$name =~ tr/A-Za-z0-9//cd;
$name = "$DIR/$name";
Apache::File-new("$name") or do {
$r-note_basic_auth_failure;
$r-log_reason("no database for $auth_name ($name)");
return SERVER_ERROR;
};
};
{
my $error_uri = Apache::URI-parse($r, "/cgi/restricttolist");
$error_uri-query(join "", "realm=",
map "%$_", unpack("H*",$auth_name) =~ /(..)/g);
$r-custom_response(AUTH_REQUIRED, $error_uri-unparse);
}
while ($db_handle) {
my ($email, $keys, $user, $pw) = split;
next unless $user and $user eq $sent_user;
if ($pw eq crypt($sent_pw,$pw)) {
$r-push_handlers
(PerlAuthzHandler = sub {
my %keys = map { $_, 1 } split /\W+/, $keys;
ENTRY:
for my $entry (@{$r-requires}) {
## entries are or'ed, locks are and'ed
my $op = $entry-{requirement};
return OK if $op eq 'valid-user';
my @locks = split /\W+/, $op;
for my $lock (@locks) {
next ENTRY unless $keys{$lock};
}
return OK; # the someone we know is OK here
}
$r-note_basic_auth_failure;
Re: coderef as arg to $r-custom_response(...)
On Wed, 09 Feb 2000, Randal L. Schwartz wrote: "Bill" == Bill Jones [EMAIL PROTECTED] writes: From: [EMAIL PROTECTED] (Randal L. Schwartz) The docs hint that I can use whatever I would put after ErrorDocument as the arg to custom_response, but also suggest that I can put "a module" there. Does that mean it's the same style of argument as a - pushhandler(), where I can also put a coderef? Bill In Chapter Nine, there are other possibilities. Would you wish to: Bill set_handlers() No, that's not going to work. If I push a content handler, but then error out, it'll go to the *error* handler, not the content handler. And for those following along, after further study in the source, it looks like custom_response can be only one of three things: a string, an internal URL (internal redirect) or an external URL (external redirect on error). Same thing as a "ErrorDocument" directive. So, I'm punting. When I get an error, I have to redirect to a URL, which then has to start all over figuring out why they were sent there. Which is not totally bad, because I have to ask the user some questions in a form, and I need to reevaluate why they might be there on the return trip anyway in case the world has changed out from under me. Can you do an internal redirect and stuff things in pnotes/notes? -- Matt/ Details: FastNet Software Ltd - XML, Perl, Databases. Tagline: High Performance Web Solutions Web Sites: http://come.to/fastnet http://sergeant.org Available for Consultancy, Contracts and Training.
Re: coderef as arg to $r-custom_response(...)
On Wed, 9 Feb 2000, Matt Sergeant wrote: And for those following along, after further study in the source, it looks like custom_response can be only one of three things: a string, an internal URL (internal redirect) or an external URL (external redirect on error). Same thing as a "ErrorDocument" directive. So, I'm punting. When I get an error, I have to redirect to a URL, which then has to start all over figuring out why they were sent there. Which is not totally bad, because I have to ask the user some questions in a form, and I need to reevaluate why they might be there on the return trip anyway in case the world has changed out from under me. Can you do an internal redirect and stuff things in pnotes/notes? I tried this recently from an AccessHandler, and the results were weird. The Eagle book makes it pretty clear (don't have it handy for a reference) that $r-internal_redirect() should only be called from a Content Handler. -- -- Tom Mornini -- InfoMania Printing and Prepress
Re: coderef as arg to $r-custom_response(...)
"Matt" == Matt Sergeant [EMAIL PROTECTED] writes: So, I'm punting. When I get an error, I have to redirect to a URL, which then has to start all over figuring out why they were sent there. Which is not totally bad, because I have to ask the user some questions in a form, and I need to reevaluate why they might be there on the return trip anyway in case the world has changed out from under me. Matt Can you do an internal redirect and stuff things in pnotes/notes? Like I said, after thinking about it, it matters not. I have to trust the user's form data on the response to the form, so I have to reevaluate all security parameters anyway. If I had secrets to share from the Auth* handler to the error handler, I'd do that. I still find it ugly that I have to waste some URL space when I could have provided the handler as a subroutine though. Everything else seems to permit me to just hook on this coderef when this other thing happens. -- 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!
Re: coderef as arg to $r-custom_response(...)
On Wed, 9 Feb 2000, Matt Sergeant wrote: Can you do an internal redirect and stuff things in pnotes/notes? haven't tried it but dont see why not. you'd just have to use $r-prev-pnotes inside the second request. we actually use err_headers_out in our webmail, but that code was written before pnotes existed, i think.
