From: [EMAIL PROTECTED] Reply-To: "Tomcat Users List" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: SSL and form-based login Date: Wed, 24 Nov 2004 01:11:11 -0600
On Tue, Nov 23, 2004 at 01:20:16PM -0800, footh wrote: > > However, if the original page is http and the login > > form is submitted > > with https then it works fine. That seems like an > > explicit constraint that > > tomcat enforces, but I can't find where in the > > authentication code it does > > that. Of course, encrypting other requests and not > > the login page is a > > pretty stupid thing to do. :) > > You kind of lost me here...sorry if I'm being dense. > > So you are saying the only way to have a link within > an SSL page go to non-SSL is either to hardcode the > entire URL in the link or have all the links flow > through a page that forces a redirect to the requested > URL with non-SSL?
uh.. what you just said is true, but it wasn't the point I was making above. I was talking about the behavior of tomcat with respect to how and when it saves the original url when it needs to display the login form. For a new session, the first request the browser makes to a protected causes that url to be stored in the session, but that value isn't always available to subsequent requests if the protocol is different.
> Now that I think about it, most (if not all) of my > non-SSL links are in include files. So, it is easy > enough to just place the full link in there. What > bugs me is I've seen other sites with relative links > on SSL pages that go to the non-SSL version (even when > you hover over the link and your browser claims it is > going to https). Using full links will be a pain too > for maintaining production and development > environments. Ugh...
as Carl Howells mentioned in a different message, this could be done with a filter. Or you could write a javascript function that runs when the body onload happens that goes and and rewrites the urls of all the links on the page. (or if you want to be evil, leaves the urls alone but sets onclick handlers that redirect the browser directly.)
eric
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
You say some sites have links within their SSL pages that navigate to Non-SSL destinations. This can be accomplished by using the rewrite capabilities of some web servers. In my case I have used Apache's mod_rewrite to enforce those rules in the past.
Let's say I have a page called registration.jsp under $CATALINA_HOME/webapps/myhost that I want to be SSL encrypted. One problem is that the user can bypass encryption by passing the URL http://www.myhost.com/registration.jsp. I need some way to force the user to use https for the registration.jsp page and others like it. Likewise, I want pages that don't require SSL to be rewritten as http://<something>/<something>.jsp. I can create Apache rewriting rules for either case.
For a period of time I used Apache's mod_rewrite. The module compares the URL it receives to a list of wildcards that the admin defines in the rules section of the server's config file. In my case, any URL containing the word "register", would be rewritten as "https://<something>/register.jsp". So even if you had a relative page link like 'href="register.jsp"', mod_rewrite would convert it to the https equiv before the webserver processed it. In a sense this URL rewritting had the same effect as redirection.
Also look into the MVC design archictecture for your applications. That is the Model, View, Controller architecture. Many sites designate one or more JSPs as a controller only page. This controller doesn't display any output. It's only function is to receive requests from the other JSPs on your site and forward them on to their proper destinations utilizing <jsp:forward> tags. In this way all of the discision making can be centralized into one controller. This simplifies the functions of the other JSPs by removing decision making logic from them. So page links, submits, imagemaps, inputs, selects and the like are simply passing requests to the controller JSP.
Consider the following links:
href="control.jsp?operation=login" href="control.jsp?operation=register"
The control.jsp file will receive the request and examine the parameter called "operation". Embedded JSP scriptlettes will decide (usually via if..then..else logic) what to do next. Since operations like logging in and registering need to be secured, the JSP can use the HTTPResponse object to do a redirect to "https://<something>/login.jsp or "https://<something>/register.jsp.
Just because your site uses a controller doesn't mean that the user has to obey the controller though. The user can still use URL manipulation to view any page on your site, thereby bypassing the controller. Thats why I recommend using mod_rewrite in conjunction with MVC. If an attempt is made to bypass your controller logic then the rewrite rules can catch them and rewrite them.
Today, I use a virtual host in Apache to define my secure server. I find this to be a much more secure solution. Apache allows you to specify whether SSL is required or not for a virtual host. In this way your secure server will refuse Non-SSL connections. Because all my secure pages reside on my secure server (which is separate from the main server), then the only way to get to a secure page is through "https://secure.mydomain.com/<somejspfile>.jsp". Links back to my non-secure pages conform to "http://www.mydomain.com/<somejspfile>.jsp". Now how simple is that?
The main server location --> $CATALINA_HOME/webapps/mainserver_app The secure server Location --> $CATALINA_HOME/webapps/secure_app
This works out a lot better. I now have a designated server with its own independent rules for my secure pages. This server has it own <hostname.domain-name.sub-domain> and its own separate ip address. I just love it.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
