tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From footh <fo...@yahoo.com>
Subject Re: SSL and form-based login
Date Wed, 24 Nov 2004 20:18:49 GMT
Great.  Thank you both for your help.

I will do a bunch of research on Apache and try to get
my site similarly configured.

It definitely seems a lot easier than the options I
was considering.

Regards,

JF

--- Charles Daniel <daniel_charles@hotmail.com> wrote:

> 
> 
> >From: erh@swapsimple.com
> >Reply-To: "Tomcat Users List"
> <tomcat-user@jakarta.apache.org>
> >To: tomcat-user@jakarta.apache.org
> >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:
> tomcat-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail:
> tomcat-user-help@jakarta.apache.org
> >
> 
> 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 
> 
=== message truncated ===



		
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message