tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: SSL and form-based login
Date Wed, 24 Nov 2004 07:11:11 GMT
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.)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message