I am currently coordinating the implementation of a complete reskin of a client web application. One of the things that has changed is the login flow. The header of the master page now has a place for the user to enter their credentials and log in from any page, whether that page is secured or not. That presented an interesting dilemma. We had previously used a separate login page that would check for a secured connection and redirect to a secured connection if one wasn’t being used. Now, we needed to allow for a secure login from an unsecure page.
Turns out that doing so isn’t too difficult. As long as the login form has an action that is pointing to a secured page, such as ‘https://www.sweetapp.com/login’, the credentials would be encrypted prior to posting the data.
When a secured page is requested, there is some hand-shaking happening behind the scenes between the browser and the server. This hand-shaking takes place before any data is passed around, which allows us to send login credentials from an unsecured page and not have to worry about them flapping in the wind. Pretty sweet, huh? As long as the page you post the data to grabs the credentials from Request.Forms instead of just Request (to keep things limited to POSTs and not GETs), you are good to go.
Of course, there is always a catch. Ours was that we were working with an ASP.NET Form. As you may know, everything on an ASP.NET Form is typically inside of a <form> tag, which is how post-backs happen. Since <form> tags cannot be nested, I needed to put the login form outside of the server-driven form and position it back into place in the design with CSS. Not too difficult, but something to keep in mind when you are faced with this same scenario.
There you have it! A secure, inline login that will make the user experience flow nicer and keep the security your site demands.