Tech Off Thread

9 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

https but request.isSecureConnection returns false

Back to Forum: Tech Off
  • User profile image
    webmonkey

    I have an aspx page which is checking Request.IsSecureConnection to ensure it is true, if not it does a redirect to the the secure page at https://www.domain.com/page.aspx.

    The server has an SSL cert installed for the domain, and the browser shows the padlock icon.

    I have created an empty aspx file, that just prints the return value of Request.IsSecureConnection and it is still false, so there is no other content coming from a standard http request.

    Does anyone know why it might always return false?

  • User profile image
    footballism
  • User profile image
    W3bbo
  • User profile image
    webmonkey

    Bump.

    Anyone?

  • User profile image
    stevo_

    webmonkey said:

    Bump.

    Anyone?

    Are you sure its actually secure at the web server? and maybe not being upgraded at an internal proxy? or that you are absoluetely sure its installed right?

  • User profile image
    footballism

    W3bbo said:
    footballism said:
    *snip*

    Hey, you're back. I last saw you in... 2005 was it?

    Yup, I am back for fun. Good to see you here again:)

    Zhou Yong

  • User profile image
    figuerres

    footballism said:
    W3bbo said:
    *snip*

    Yup, I am back for fun. Good to see you here again:)

    Zhou Yong

    Hey!  long time no see (so to speak)

    Big Smile

  • User profile image
    nyasara

    So, this may be a bit old to give you an answer, but here's something I found.

     

    I am helping my wife write a website that uses Network Solutions Shared Hosting (though this also seems to happen with other shared hosting solutions).  What seems to be happening is that the way they have it set up, there is one IP shared among many sites (all the sharing hosts on one server) that points to a proxy device.  This translates all incoming requests to the proper application based on the hostname, but it sends the request to your site with http:// no matter what.  Any SSL is done between the client and the proxy.  So your application code never sees https:// even if that's how the client requested it.  Your code just gets http://whatever.thisisapain.com.  A very quick and dirty solution I cam up with was to put the following in my global.asax.

     

    protected void Application_BeginRequest(Object sender, EventArgs e)
        {
            if (Request.QueryString["secure"] == null && !Request.ServerVariables["SERVER_NAME"].Contains("localhost"))
            {
                if(Request.RawUrl.Contains("?"))
                {
                Response.Redirect("https://" + Request.ServerVariables["SERVER_NAME"]
            + Request.RawUrl + "&secure=true");
                }
                else
                    Response.Redirect("https://" + Request.ServerVariables["SERVER_NAME"]
            + Request.RawUrl + "?secure=true");
            }
        }

     

    Basically, this checks for a querystring parameter called "secure", and if it's not there, redirects to https://REQUEST?secure=true or https://REQUEST&secure-true if the request already had a querystring parameter.  It is not a great solution, because unless you change all of your links and redirects to append the secure parameter, they will get an extra redirect for every new page they go to.  However, the secure parameter is preserved in a postback, so that still works.

     

    There is probably a better solution, and ultimately, the best solution would be if these providers didn't do this, but I can't do anything about that I guess.

  • User profile image
    cheong

    nyasara said:

    So, this may be a bit old to give you an answer, but here's something I found.

     

    I am helping my wife write a website that uses Network Solutions Shared Hosting (though this also seems to happen with other shared hosting solutions).  What seems to be happening is that the way they have it set up, there is one IP shared among many sites (all the sharing hosts on one server) that points to a proxy device.  This translates all incoming requests to the proper application based on the hostname, but it sends the request to your site with http:// no matter what.  Any SSL is done between the client and the proxy.  So your application code never sees https:// even if that's how the client requested it.  Your code just gets http://whatever.thisisapain.com.  A very quick and dirty solution I cam up with was to put the following in my global.asax.

     

    protected void Application_BeginRequest(Object sender, EventArgs e)
        {
            if (Request.QueryString["secure"] == null && !Request.ServerVariables["SERVER_NAME"].Contains("localhost"))
            {
                if(Request.RawUrl.Contains("?"))
                {
                Response.Redirect("https://" + Request.ServerVariables["SERVER_NAME"]
            + Request.RawUrl + "&secure=true");
                }
                else
                    Response.Redirect("https://" + Request.ServerVariables["SERVER_NAME"]
            + Request.RawUrl + "?secure=true");
            }
        }

     

    Basically, this checks for a querystring parameter called "secure", and if it's not there, redirects to https://REQUEST?secure=true or https://REQUEST&secure-true if the request already had a querystring parameter.  It is not a great solution, because unless you change all of your links and redirects to append the secure parameter, they will get an extra redirect for every new page they go to.  However, the secure parameter is preserved in a postback, so that still works.

     

    There is probably a better solution, and ultimately, the best solution would be if these providers didn't do this, but I can't do anything about that I guess.

    I think you can ask them if the proxy server will added any request headers indicating it has been in SSL or not. It's probably configurable setting on zones of the proxy, and possibly already configured that way.

     

    It doesn't hurt to ask.

    Recent Achievement unlocked: Code Avenger Tier 4/6: You see dead program. A lot!
    Last modified

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.