24

I want to redirect users, after HTTPS login, to the HTTP pages on the site. Using HTTPS for the whole site is not going to happen.

What I have so far is the following:

  1. User posts the login form to the secure site
    • The secure server validates the credentials
    • The secure server sends a 302 redirect to the client

This works, except on my machine in IE6 the user gets an error message because the default is to warn when exiting a secure page. These errors are a usability killer for me and thus a showstopper. I changed it so that step 3 is

  • Server sends html code with a meta refresh

But this is very slow; even on my local machine it's noticeably slower than doing the 302 redirect.

Is there a better way to accomplish the goal of a hassle-free redirection on standard settings that people use? IE6 represents 20%-25% of our traffic. Also, does anyone have any good info about which browsers will warn and which won't warn for the 302 redirect? I am considering black-listing IE6 so that only it gets the slow meta refresh and everyone else gets the fast 302.

Andrzej Doyle
  • 102,507
  • 33
  • 189
  • 228
Mr. Shiny and New 安宇
  • 13,822
  • 6
  • 44
  • 64
  • If you post a form to a https site, isn't the response therefore coming from a https site, which puts the user on https going forward? – matt b Mar 16 '09 at 19:19
  • @matt: the response comes from the https server, but that response contains instructions to redirect. Certain redirection modes warn, others do not. Warnings are scary and, IMO, pointless (since not all page redirection modes warn). – Mr. Shiny and New 安宇 Mar 16 '09 at 19:23
  • I misunderstood your question. I thought you were using the 302 redirect to redirect from http --> https. – matt b Mar 16 '09 at 19:25
  • -1 for going through the hard work of setting up and using the encrypted connection **one time**, then dumping it like trash. – Gup3rSuR4c Jan 26 '15 at 23:56
  • 2
    @alex thanks for passing judgment on me like that. It really helps solve my technical problem when you punish me for decisions others in my company make that i have no control over. – Mr. Shiny and New 安宇 Jan 27 '15 at 00:05
  • 1
    *"Using HTTPS for the whole site is not going to happen."* - makes it sound like you're the decision maker and that you're very adamant about it. Explain to your company's decision maker(s) that 1) the resources of encrypting the login have already been spent *and then wasted*; 2) encrypt by default and *avoid* your technical issue completely; 3) that you're lulling your users into a false sense of security *and* privacy; 4) ask them if that's how they'd like *their* personal information to travel over the Internet; and 5) get with the times because trust is valuable in this day and age. – Gup3rSuR4c Feb 06 '15 at 16:53
  • @alex I'll just get into my time machine and go back to 2009 and tell my boss that someone from the future tells me that there are no technical barriers at all to doing site-wide SSL, no costs whatsoever, and that securing part of the session is worse than securing none. I'm sure he'll appreciate your nuanced understanding of our application, its architecture, and the network it's deployed on. Also, I bet you never visit any site that uses SSL for important things like login or ecom, and not for other things, and you never did in 2009 either. Seriously get off your high horse. – Mr. Shiny and New 安宇 Feb 06 '15 at 18:45
  • 1
    You need to relax. I realize this was from 2009, but the reason I left my comment was for anyone that visits this question now or in the future can read through the comments and see there's other alternatives. Your question is still is relevant and comes up high in search results, it's how I got here. I wasn't trying to attack you, but I did want to point out the flaw of building up the HTTPS session just to scrap it right after and you trying to solve redirects because of it. I apologize to you if you feel that I have disrespected you. – Gup3rSuR4c Feb 06 '15 at 21:57
  • @Alex Your tone has been condescending and rude since the beginning. You failed to consider that there might be reasons why I, or someone else, might not want/need/be able to be in an SSL connection all the time. Anyway, this question is hardly relevant anymore as it only affected IE6. – Mr. Shiny and New 安宇 Feb 06 '15 at 22:03
  • [This](http://stackoverflow.com/a/34094617/2404470) maybe useful for end users – Zameer Ansari Dec 11 '15 at 09:11

3 Answers3

11

Reviving an old topic , but to make it compelete posting the following so other devs can have a choice of implementation

One way of moving bettween https to http without a warning message is to use client redirect using javascript.

Steps

  1. User enters login details on a https form and click on login button
  2. login button will post back to https form for login validation ( assuming login is correct) will redirect to a holding page which is also under https and displays the message ( please wait while the site redirects you)
  3. This holding page does a javascript redirect to the http page

no browser warning message will be displayed

HTH

George
  • 111
  • 1
  • 2
  • This solution sounds functional so I upvoted it, however it suffers from the same problem as the meta-refresh solution, which is that it involves the user downloading an entire html document, then processing it, (and worse, additionally, executing javascript), before they leave the intermediate page and go to the intended destination. I would only use this method if I had reason to doubt that meta-refresh worked. – Mr. Shiny and New 安宇 Sep 24 '10 at 12:59
  • yes you are right, The full soluion that i deployed was to have a common https to http redirection page with very minimal content. The server process would handle generating the load scipt as well as add a meta tag refresh with a slight time variance. Since the page is very minimalistic it does load very fast but the round trip cannot be avoided. – George Sep 28 '10 at 08:03
  • That was the perfect solution for my problem! I had to submit harmless form content to a non-https form handler. Few lines of JavaScript and the warning is gone. At least for JS-capable users :) – BurninLeo Jun 23 '11 at 10:50
5

I am considering black-listing IE6 so that only it gets the slow meta refresh and everyone else gets the fast 302.

I would do something like that. Also include a plain HTML link in the body for accessibility.

Note that some other browsers do give a similar warning about leaving an HTTPS site, but in their case it is accompanied by a (generally pre-ticked) “don't ask me again” button. So by the time they get to your site they will almost certainly have told that warning to disappear. This doesn't make the warning less pointless, but at least it alleviates the problem.

  1. The secure server sends a 302 redirect to the client

You shouldn't 302 in response to POST. A theoretical browser that took the HTTP RFC seriously might respond to that by re-POSTing the form to the new URL. (Which, ironically, would make IE6's warning about information “being retransmitted to a nonsecure site” less misleading.) Instead use “303 See other”.

bobince
  • 528,062
  • 107
  • 651
  • 834
  • The 302 response is actually sent by the J2EE framework. I just use response.sendRedirect(url). – Mr. Shiny and New 安宇 Mar 17 '09 at 13:07
  • It is unfortunate that sendRedirect doesn't provide access to the other 30x status codes, but you can do it manually: response.setStatus(HttpServletResponse.SC_SEE_OTHER); response.setHeader("Location", "..."); – bobince Mar 18 '09 at 02:32
  • @bobnice: doing it manually would work but in practice I avoid doing that since we also use other side-effects of the sendRedirect method, namely url-rewriting. – Mr. Shiny and New 安宇 Apr 13 '09 at 17:10
2

I don't think there's any other way. That error message is for the user's benefit, and is present in IE 7 and Firefox 3 now as well. The only way that I know of to prevent it is to add your site as trusted within the browser.

Update: Oh, so it's not the mixed content error. I know which one you mean, though I still don't think you can disable the error. Generally, security errors are for the users benefit to protect them from potentially dangerous sites, and as such, cannot be disable by the (potentially unsafe) website itself.

atfergs
  • 1,674
  • 1
  • 11
  • 17