I believe I have done something similar to what you are after. If I understan
correctly you have some other logging on precedure which we need not worry
about save that it makes available a 'logged on' boolean.
At whatever point in time this is established place it in the session object.
Then at the top of every page extract and test this flag. If true continue page
execution, else redirect to logon page.
Complication: You mention that it is a perl script that determines the logged
on state. Whilst I know nothing about perl, could you wrap the script execution
with a java class? If so you can place the java object complete with accessor
method in the session and test that. Alternatively let the perl set up the
cookie and state as currently then write a java class to check it and return
the state, and store this class in the session.
Any way you look at it , once you have the state (or an object with accessor
method) stored in the session object , you can determine whether you want to
display the requested page or redirect.
hope this helps, tim
David Bullock wrote:
> Hi Guru's and API veterans/designers,
>
> Suppose I want to do some form-based-ogin authentication of my own (for the
> scenario noted below, if anyone's interested).
>
> I need to map a servlet to '/' that performs conditional processing, and
> then
> [??? calls a HttpSession.RequestDispatcher.forward() ] to dispatch the user
> to
> their requested URI.
>
> But the servlet will be called recursively, since anything I dispatch to
> will
> invoke the servlet at '/' again....and call-stacks overflow or memory runs
> aground.
>
> How could I get around this in a way that still makes it useful as an
> authentication mechanism?
>
> Thanks,
> David.
>
> Note on scenario for doing custom form-based-login:
>
> I wish to authenticate a user based on conditions which are external to the
> application context (ie. file that matches cookies assigned from another
> application to their logged-in/logged-out status) with the cookie supplied
> with
> the HttpRequest. ie. Request gets directed to '/', servlet at '/' checks
> cookies of request, tests if the cookie is in a 'currently logged on' file
> maintained by the perl application, and if yes, return the requested
> content,
> or if no, shows the login form'. This is to integrate with a legacy
> CGI/Perl
> system which currently controls cookies for us.
>
> Better solutions than mapping '/' would include:
> 1. to be allowed to specify a subclass of the Session object that the
> web-application used instead of the default. [probably a bit difficult]
> 2. Or to be allowed to specify a pluggable authentication routine(s) that
> informed the servlet container's form-based-login mechanism (such a scheme
> would have to pass on the HttpRequest object, at the very least). [would be
> a
> very nice feature. I realise that some containers implement Realms for
> security, but in this case, the credentials include a component of the
> request
> itself, which I don't believe is catered for in the usual Realm model
>
> --
> David Bullock
> Project Manager - Strategic Applications
> [EMAIL PROTECTED]
>
> "It's no use saying 'We are doing our best.' You
> have got to succeed in doing what's necessary."
> ...Winston Churchill
>
> LISAcorp
> http://www.lisa.com.au/
>
> Adelaide Sydney
> -------------------- ------------------------
> 38 Greenhill Rd Level 3, 228 Pitt Street
> Wayville S.A. 5034 Sydney NSW 2000
>
> PH +61 8 8272 1555 PH +61 2 9283 0877
> FAX +61 8 8271 1199 FAX +61 2 9283 0866
> -------------------- ------------------------
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
--
Tim Stephenson
-----------------------------------------------------------
e: [EMAIL PROTECTED] or [EMAIL PROTECTED]
m: +44 7775 66 00 58
v: +44 1628 597279
-----------------------------------------------------------
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
