Hi Ravi --
Unless your pages are very simple, it's not a good idea to code them into
your servlets. However, there are several possible ways to secure access to
them:
Option 1: Implement your servlet as a "mini server" that reads a requested
page from disk and serves it up. You might call it as
http://my.domain.com/secure/page2.html
<http://my.domain.com/secure/page2.html> where your web server maps /secure
onto RavisSecureServlet. RavisSecureServlet would get the "extra path
information" ("page2.html") and use that string to open/read a file from the
disk.
Pros:
Since all of the requests go through your servlet, you can require a
login.
If some elements of your page change, you can put "markers" in the pages
on disk and have your servlet perform a search-and-replace on the fly. (See,
for example, FreeMarker or WebMacro.)
Your pages can be changed at any time by editing the standard HTML files
on disk.
Cons:
You're writing a web server. If you use relative links to the images in
your page (e.g. ./images/picture1.gif), your servlet will be asked to serve
those up as well. This complicates your code.
You're writing a web server. You won't be able to take advantage of the
buffering, security tools, etc. of your regular web server. You wind up
re-implementing things you already have.
You're writing a web server. Doing your own file I/O in Java is likely
to be slower than the file I/O implemented in your (well-tuned) web server.
Option 2: Many web servers maintain a list of "authorized connections", or
allow you to add an "access control" module to the server. (For example,
Apache lets you plug in your own access control mechanism.) I could imagine
a system where the user's logging in puts a token into a "database" (or
other data storage area shared between the servlet and the web server.) The
server's access control mechanism could consult this database and either 1)
grant access to a page, or 2) redirect the user to the login page.
Pros:
You do what you know (the access control) and the server does what it
knows (serving pages).
Cons:
You're tied to one kind of web server.
You have to write and test some code that integrates into the server,
which could be messy.
At the moment, my projects use Option 1, but I'm considering Option 2 as I
move into a higher-volume environment.
...Richard
-----Original Message-----
From: Gopalankutty, Ravi Kumar (CTS) [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 03, 2000 10:17 PM
To: [EMAIL PROTECTED]
Subject: [SERVLET-INTEREST] Serving secure pages...
Importance: High
Hi list,
I have written a servlet (with help from Jason Hunter's Servlet Programming
book of course :) that does a validation of the user once he logins in (say
from page1.html). Now my question is whether all subsequent pages are to be
coded into the servlet code itself (using out.println("<html>.....</html>")
or can I have them as html pages (say a.html,b.html etc...) and then use the
redirection property from the servlet.
If it's the second case (i.e., redirection) then the user can always see the
url of the page and then at a later login bypass the login mechanism.
Thanks * Regards
Ravi Kumar Gopalankutty
Cognizant Technology Solutions,
Ph: 044-2354281 Extn:4423
e-mail: [EMAIL PROTECTED]
_______________________________________________________________
___________________________________________________________________________
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
