This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I am working on a database backed website. The database used is Oracle. At front end, its JSP and Servlets along with JDBC to establish database connection. Can someone direct me as to how I can implement security issues? For e.g. there's an administrator login/logout option. After logout, one can easily hit the "Back" button on the browser to work on the previous pages. These pages are accessible through the "History" option in the browser too. What is the way for me to "Expire" the web page appropriately? I'd appreciate any feedback. Thanks, Saket
The first thing to do is to add a few HTTP headers in an attempt to force browsers and proxies not to cache your pages. Something like: Pragma: No-Cache Cache-Control: no-cache Expires: 0 Last-Modified: Fri, 10 Jan 2031 23:59:59 GMT Beware that, although this looks like complete overkill, some browser/proxy combos still seem to ignore it (especially some stuff from a certain company in Redmond). To make browser history essentially unusable on some browsers, simply ensure that the pages are created using POST requests (i.e. form submissions). The browser won't redisplay, but wants to re-post the request. Your remaining problem is then just to refuse the request. The easiest way by far to do this is to leverage container security: declare security roles and protected pages in your deployment descriptor, done. The only downside is that there is no standardised API to make containers use a source of authentication information that you already might have (XML file, database table, directory, whatever). Conversely, there also is no standard API to add, delete or modify users in whatever security realm implementation your container uses. All containers worth the name have some kind of API, but they're all different and non-portable. Alternatively, if you are using a Servlet 2.2 container, you will be able to set up a servlet filter which will filter requests to protected areas of the webapp and take appropriate action if the user isn't logged in or not authorised. This basically mimics the action of container-based security but allows you to do your own thing in a container-independent way. Assuming you did the right thing and implemented your business logic in session EJBs, plain old Java business objects or the like, you could conceivably check credentials there. The disadvantage is that it'd get scattered a bit and problems would be flagged up only fairly late. Finally, if you are using a Model II architecture, you will be routing all requests through a front controller. That gives you a single access point where you can implement security checks. This is probably the least desirable option though. - Peter [ March 12, 2003: Message edited by: Peter den Haan ]
Joined: Dec 19, 2002
Hi Peter, Thanks for the detailed and precise reply. I appreciate your prompt feedback. Sincerely, Saket