[sslExt] Switching from HTTPS to HTTP and avoiding the "You are about to be redirected to a connection."

[Robert Taylor <rt...@mulework.com>]

I'm using Struts1.1rc1 and sslExtRC1-2. BTW, thanks to
Steve for this package.

There is one caveat however...

If you submit a request to the server via HTTPS
and that request is redirected to HTTP before returning
to the client (server side code does a Response.sendRedirect() switching
the protocol from HTTPS to HTTP), then IE and NS7.x  display a pop-up
security alert.

I have found a work around to be to redirect to a page with
embedded logic to determine where to send the user and then
use the <meta HTTP-EQUIV="refresh" content="0; url=<%=destination%>"> to
redirect the user to the appropriate destination.

I don't currently see how the sslExt addresses this issue.

If it does, can someone please let me know how.


robert

-----Original Message-----
From: Robert Taylor [mailto:rtaylor@mulework.com]
Sent: Monday, March 31, 2003 2:17 PM
To: struts-user@jakarta.apache.org
Subject: [sslEXt] You are about to be redirected to a connection which
is not secure....


I am using Struts1.1rc1 with the sslExtRC1-2. My current requirements don't
allow me to have all requests go through the Struts Action servlet. (please
don't lecture me on the benefits of all requests going through the
controller...you're preachin' to the chior)

I have a situation where I need to provide a login form through out my site
on pages that are directly accessed via HTTP, although the action attribute
for the login form element on those pages is HTTPS (providing secure data
transport). Validation error or not, the user is always returned to the page
from which they signed in.

For MSIE and Netscape 7.02 this causes a "security" alert to pop-up.

MSIE:
"You are about to be redirected to a connection which
 is not secure. The information you are sending to the
 current site might be retransmitted to a nonsecure site.
 Do you wish to continue?"

Netscape 7.02:
"You have requested an encrypted page that contains some
 unencrypted information. Information that you see or enter
 on this page could easily be read by a third party."


I have found a work around to be to redirect to a page with
embedded logic to determine where to send the user and then
use the <meta HTTP-EQUIV="refresh" content="0; url=<%=destination%>"> to
redirect
the user to the appropriate destination.

This seems like such a hack and I was wondering if there is a cleaner
solution.


robert

BTW, I have searched the mailing list archives and Google and have yet to
find a cleaner (any) solution.


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


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