David Baird wrote:
On 9/12/05, Dave Howorth <[EMAIL PROTECTED]> wrote:
David Baird wrote:
On 9/12/05, Peter Speltz <[EMAIL PROTECTED]> wrote:
Another case, say you wanted images to display only if a user was over
18 . How, from the authenticate sub, would you skip Maypole
processing yet tell Apache to not return the image? . Return ERROR?
If you set the template, the model phase won't be run, and your
alternate template will replace the image. Your 'template' would need
to be an image as well, because the browser asked for something in an
'img' tag.
Ermm? What stops the model being processed is $applicable != OK (which
is as a result of is_applicable() and which also sets the template).
Setting the template doesn't stop process() being called on the model
class, but the first thing process() does is check if a template has
been set already, and if so, it just returns.
You're quite right. Yet another place in Maypole where you can't
actually follow the logic by reading the code in one place :( I wonder
why that test is in model->process while the rest of it is in handler_guts?
In the static data case we're discussing though, it's likely
is_applicable already failed, so model->process doesn't get called.
Unless you've built some kind of wacky pseudo-table-based model
subclass, or you're storing your images in the database etc etc.
Or, your authenticate() could return an AUTH_REQUIRED or FORBIDDEN
error and the code will be returned to the browser. (You'll need to
import these constants from somewhere).
How does this work? Maypole clearly isn't expecting anything but OK or
DECLINED (which is the same numerical value as ERROR) because of these
lines in Maypole.pm:
if ( $r->debug and $status != OK and $status != DECLINED ) {
$r->view_object->error( $r,
"Got unexpected status $status from calling authentication" );
Yes, but note there's no return call there. So the view object will
generate some output, and then we drop back to the next statement
in handler_guts(), which is
Sorry, that wasn't my point. If you don't have debug turned on, the view
object won't get called there. My point was just that the guard
condition only allowed for OK and DECLINED (what is DECLINED, BTW, since
it's numerically equal to ERROR?)
return $status unless $status == OK;
So your non-Maypole return code is preserved, at least for custom
authentication. Note that if debug is turned off, the stanza you quote
is skipped entirely, and the status returned from call_authenticate is
returned immediately.
Exactly! So you get a 500.
And whenever I make authenticate return anything other than OK, the
browser displays 500 - server error. Is this a CGI::Maypole problem or
do you see the same with mod_perl?
Hmm, from a quick scan of my code, I don't return AUTH_REQUIRED, I
just redirect to the login page and return OK. I'll play around with
that.
Cheers, Dave
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.21/96 - Release Date: 10/09/05
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Maypole-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maypole-users
