Hi Kevin,
I've done pretty much what you are asking for in our WebLeaf framework,
so I'll add my own comments intermixed ;).
------------------------------
Date: Mon, 12 Jun 2000 10:24:06 -0700
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
Subject: Re: JSP mapping to my own servlet?
>Kevin Duffey wrote:
>
>> Hi,
>>
>> I was wondering, following the Struts framework, Model 2, etc..since
>> servlets merely map the JSP extension to their own incarnation of
>> JSPServlet, is it possible to map all JSP pages to my ControllerServlet
>(or
>> for that matter, the controller servlet of the Struts framework), so
>that I
>> could place security abilities and other things (making sure pages they
try
>> to access are allowed..if they are logged in or not, etc)? If so, is
>there a
>> lot involed in such a task?
That actually depends on what you want to do in the controller servlet.
We do have customizable-flexible-dynamic authentication and
application-wide event handling. As the security part is somehow
sophisticated (error messages specify "wrong password, user doesn't
exist..", concurrent access is controlled...) then it has not been a
one-day task. On the other hand, we are quite happy with the result and
we have been using it since then.
>>I know I could just remap the servers JSP
>> mapping, but I am wondering if it makes more sense to just comment out
their
>> mapping, and put the JSP mapping into my web.xml for my application..or
can
>> I leave the servers there, but map it anyways..and my web.xml mapping
would
>> override the servers?
>>
>Mapping the JSP extension to your controller servlet means that you have
>to do
>everything the JSP servlet would have done (compile the page if the source
>is
>newer, execute the corresponding servlet, and so on). This is not for the
>faint of
>heart :-).
Craig is right, of course ;). What I did before getting into the Model2
world was to create a base JSP class that implemented the security
routines and then force the JSP generated class to extend this base
secured class using the "extends" JSP directive. It worked even though I
had some problems with some engines tha t were not compliant to the spec
so the extends directive didn't work. Then I got into the Model 2
arquitecture and used JSP just as a view so I implemented the security
in the controller and I was much happier.
Then I moved to Model 3 and I don't use JSP so I was reassured that
implementing this in the controller and not in the JSPs was the right
choice.
>If you are building your app for a servlet container that implements the
>version
>2.2 spec (and in particular the security constraints stuff), my answer
>would be
>"you are trying to work to hard." Just let the servlet container's
>security
>constraints deal with authentication and access checking.
If the specification was flexible and complete enough I would agree
with Craig in this point. That was the reason that "forced" me to
create my own. On the other hand, I agree that if your security scheme
is not complicated and you just want to use standard things, then you
might try to go for the JSDK2.2 approach which is "simpler". However,
take into account that your user-role mapping will be container
specific, and that you will have to specify the roles required for your
URLs in a static xml file, so you cannot specify a different required
role depending on a parameter...
>In an environment where you want to (or must) do your own checking, it is
>not hard
>to contemplate building a little custom tag of your own that checks the
>user's
>session for a particular attribute key, and forward to your login page if
>it's
>missing (either because the user tried to jump into the middle of your
>application,
>or because the old session timed out). Role checking would make this
>custom tag
>only slightly more complicated -- something like:
> <mytags:checkLogin role="manager"/>
>at the top of each page that needed "manager" role could also do the
>access control
>checking for you, by looking at the properties of your user login object.
>Writing
>your own custom tags is a pretty simple exercize -- especially since you
>can use
>Struts for examples!
>Doing this in a generic way (say, in Struts) would not be too tough for
>the simple
>login check (just use servlet context attributes to define the attribute
>key to
>look for, and the name of the login page to forward to). Doing the role
>check
>generically would be somewhat tougher, because there is no generic way to
>say "what
>roles does the current user have" unless you are using the servlet
>container's
>authentication support, where you can call request.isUserInRole() to
>answer this
>question.
Or unless you implement a similar call in your security environment,
which I did. ;)
>>
>> Furthermore, what I would really like to do, since my entire site is
solid
>> JSP now (other than a few static html pages) because I include the same
>> header and footer on every page (using JSP include directives), I merely
>> want all JSP pages to go on to the JSP Servlet..but I just want one
central
>> location for security reasons..so any JSP request allows my one servlet
to
>> make sure the page being accessed is allowed by the person accessing it.
What I do is that when I want to protect a JSP page, I just configure an
"operation" in the controller servlet that simply forwards the request
to the JSP page and then I implement security upon the operation. I
already have a predefined action class that does
that(JSPForwardOperation) so I just have to configure the XML
appropriately. Much simpler than the taglib approach. And if you got
paranoid you could even protect your JSPs from being accesed directly by
disallowing any other hosts to access /whatever/*.jsp but your local
host.
>That is exactly what the security constraints in the 2.2 spec are about --
>making
>it the container's responsibility to check this stuff, instead of the
>application's
>problem.
Right again, but not the specification is not enough yet, IMHO, to allow
you to do that in all the cases.
>In the mean time, just code a custom tag that does the checks you want,
>and include
>it at the top of every JSP page, and you're done.
>> Thanks for any info.
>Craig McClanahan
------------------------------
Just as proof that the spec is not enough, check the containers that are
updated to JSDK2.2 and you'll see that almost all of them have a
container-specific way of authenticating the users and/or a
container-specific way of mapping users to roles. Even Tomcat has its
own. So that's the reason why I implemented my own scheme: because I
didn't want to go back to container-specific applications again!
Just my 2c
Dan
-------------------------------------------
Daniel Lopez Janariz ([EMAIL PROTECTED])
Web Services
Computer Center
Balearic Islands University
-------------------------------------------
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
