----------------------------------------------------------------
BEFORE YOU POST, search the faq at <http://java.apache.org/faq/>
WHEN YOU POST, include all relevant version numbers, log files,
and configuration files. Don't make us guess your problem!!!
----------------------------------------------------------------
Hi,
... I would encourage you to program a very simple extension of the standard
HttpServlet . I would advise against using other people's 'frameworks' for
this purpose (there are many of them around, focussing on different things)
right now, for different reasons :
1. it would be overkill for what you need
2. you would be forced to work yourself into yet another way of thinking,
3. it would divert your attention from learning about servlet programming
basics.
4. it is an interesting exercise, which will let you feel why a large
framework could be useful in the first place - it will help you understand
better what the limitations of servlets are.
Here's my suggestion, feel free to ask more info.
A. Derive your own class from HttpServlet, make it abstract as to force you
to build your actual protected servlets from that class.
Speaks for itself.
Add an additional private boolean instance variable to indicate the status
of authentication for execution of this servlet. Make it default to 'false'.
B. Implement a specific method for recovering the session.
This method checks for an existing session from the request, and if it finds
one, tries to recover the authentication data bound into that session. The
servlet instance authentication variable is set according to the
authentication data found, or set to false. It might be useful for this
method to return the actual session.
This method also scans for any parameters you can use to authenticate the
user. Once a user is authenticated, you no longer need to pass these
variables, just rely on the session data. Point being, use parameters to
initialize the session data. On the client side, you can use a form for
this...
e.g. private HttpSession check(HttpServletRequest request) {...}
C. Implement *private* 'authenticated' variants of the service method and/or
the different HTTP methods
e.g. the classic doGet(..) might find a brother like doAuthenticatedGet(..)
or just go for generic... do it for service(...) and implement an
'authenticatedService(...)'...
D. Override the actual service and/or actual HTTP methods
e.g. Each time, call the check method from the body, and execute
authenticatedService(..) only if the local authenticated is true. You might
even like a notAuthenticatedService(...) where you can customize what to do
in case of failure... or perhaps you don't need it, and you can hardwire
redirection in the actual service(..) body. A simple static
'getRedirectionURL' initialized in the init() body makes it easy to
customize each particular redirection for each servlets you write.... or you
might pass it as an initialisation parameter... plenty of options...
Okay,
let's see how far you can get with this....
e-gret,
Danny Martens
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
