Forum OpenACS Q&A: How to avoid warning on redirect to non-secure section?

If the /register directory (on 3.2.5) is secured with SSL, anyone using IE who logs in and is redirected to a non-secure section of the site receives an ominous warning:
You are about to be redirected to a connection that is not 

The information you are sending to the current site might 
be retransmitted to a nonsecure site. Do you wish to 

Obviously this is less than ideal. I've tried the obvious solutions, and have been reduced to an ugly kludge, using javascript or a refresh tag in the head of an interim page to redirect. That's really not acceptable, and I would even consider unsecuring the log- in, except I don't want administrative passwords going across in clear text.

Has anyone else figured this out? I wonder if I'm being too paranoid in wanting to secure the log-in and I should just make the tradeoff for convenience?

P.S.  I don't know if it matters, but at the moment I'm using a self-signed certificate with OpenSSL.
This is the case in 4.5 as well.  I battled this yesterday.

Walter, in truth your problem is on the client side.  Not all users get that warning--you can turn it off on the client.  I think my solution was to put an interim page in that said "Thank you, you are now logged in", and issue the redirect from there.  That's your solution, too, right?

Our experience has been that a lot of our users don't notice that they got logged in, and are confused when they are presented with the home page again (when they login from the home page anyway) and I think the extra "thanks you are logged in" page would make them feel better.

Sniff what happens during a login to Hotmail or You can play games with JavaScript.

I consider this a security hole, but there's no way Microsoft is going to fix it.

We chose to keep the warning because it's true. We prepend a disclaimer to

Thanks for the responses.  These are good points.  I do think it makes sense to either have a disclaimer or a results page that tells the user what's going on.  For this particular implementation I'm leaning towards C.R.'s solutions, as I'm trying to be as hospitable as possible.
This is a common enough problem that perhaps we should adopt the confirmation approach ("thanks, you're now logged in") as a standard part of the page flow?

If folks think this is a good idea, lash together a patch and new page and we can add it to the development branch of the tree ...

I can provide the one for 3.x when I've got it working smoothly, unless someone else has it ready to go and wants to submit it.

On a related note, have other people solved the problem of breaking out of secured pages?  When I was trying to resolve that issue I found some code in one of the posts, but it didn't really work for me.

I ended up creating a much more elaborate solution that allows me to more finely tune what gets passed through SSL.  I don't know if my solution creates excessive overhead or if there is a better approach out there, but that also seems like something that would be good to package up.

How about remove the "interim" page idea, and simply https-secure the next page that comes up - after this page, subsequent ones can be plaintext if required
The problem is with the response redirect code.

So instead of using

use the following:

Response.Write ('<meta http-equiv="refresh" content="0;url=">');

Hope it helps,