Yes - creating a taglib is much, much better than a compile time include. My only reason of recommendation for a compile time include was because that was the easiest and quickest fix - but also the worst.
There are a few ways to perform authentication. Each has their own merits. - Use a custom tag that will force an abort/redirect of the page - Use a filter - Use the servlet api' security constraints
A custom tag offers the most flexibility since it is easiest it is the easiest way to perform granular access. But this method has the drawback of reinventing the wheel with respect to page protection.
A filter is nice since the pages to be protected don't need to know whether they are being protected or not. This leaves the coding of the page MUCH cleaner and easier to maintain. Filters can also be selectively run on only mappings defined in web.xml. Filters also have the abolity to be run on every request and you can create your own wacky rules too.
The prefered way is via the servlet sepcification. This method relies on the spec and the brain pwoer of a lot of smart people trying to think of how to solve the exact problem you had. But on the bad side, it is also a lot of smart people from different organizations with their own agenda so for some people - this method is completely unworkable to them. But this method is the best since ultimately security is taken out of the hadns of the programmer and placed into the hands of the system administrator or configurator. This method still relies on developer support but offers the most flexibility if you can plan on using this first.
Pertaining to the topic below of using a header.jsp and footer.jsp. We have the same mess, and I emphasize mess. Many of my pages include a header, then do stuff, then a footer. I inherited it and hate it. Luckily the consulting firm that did this to me is long gone.
Since then we have done the following to fix messes like this:
- Get a real content management system. Let it republish all the HTML file when stuff changes. For us, navigation doesn't change very often so mass publishes aren't very painful.
- Custom tags are your friend. For newer parts of my site, I have created a 3 custom tags which handle my header/footer/nav hell. So now my pages look like this:
<foo:html>
<foo:head>
Any extra stuff which needs to appear in head tag goes here.
Otherwise this tag just places the normal stuff that would appear
in the head tag here.
</foo:head>
<foo:body print="true" width="800">
Body of page goes here.
</foo:body>
</foo:html>
It is the job of the head and body tags to pull in the appropriate navs at the right time and plop them on the page. Currently the tags are a mess which involve some printlns, but mainly it has many includes from other assets. If I code the body of my page well - I can easily turn the same page into a printer friendy page or even a mobile device friendly page with these tags. (If I felt masochistic).
But the above also has issues too if your site is content heavy and each content page becomes a JSP. In that case - you should really be publishing your content in an intermediate format and have it transformed dynamically by a single servlet instance so hundreds (or thousands) or JSP's are not instantiated on your server.
-Tim
Geoff Coffey wrote:
You can do a compile time include instead of a run-time include.
Tim:
We wanted to avoid that because we're including quite a lot of stuff, and it is being included on every page. Naively, I felt that duplicating all that header and footer logic and HTML in every generated servlet would be unwise. But I'm very new to this, so I may be off base.
The general setup is that we have the typical standardized header and footer, and some standardized, but conditional, navigation stuff. This is all part of two include files called, aptly, "Header.jsp" and "Footer.jsp". These files are included on nearly every page, so that the page itself only needs to define its unique content. Our header performs the requisite check that the user is authenticated, and attempts to redirect to the login page if not. For some reason it worked fine until recently, perhaps coinciding with our switch to the latest stable tomcat.
It seems like we need our authentication check and redirect (or forward) on the content page itself and not in an include, so Muffi created a taglib to encapsulate this check and that seems to be working. Is this a typical solution? It seems like a frustrating restriction to prevent redirects or forwards in includes. Does anybody know the reason for this limitation? Does anybody have a better way to accomplish what I'm describing?
Thanks for all your help so far!
Geoff
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
