Secure custom login control ASP.NET

Problem: I want to create a custom log in control that posts securely to HTTPS without affecting other submit buttons on the page.

If I had been writing this in ASP.NET MVC or any other language for that matter, I would just create a new form tag with an form action="https://...". Now I'm stuck in a ASP.NET web forms site. That means that I can only have one forms tag in the entire page, thus ripping me off on that easy solution.

What have I tried?

1. I've changed the pages entire form during pre render so that the action posts to a HTTPS dress. But as I stated before, this will make all other buttons on the page also submit via SSL. I don't want that.

2. I've done practically the same thing using JavaScript. The nice thing about this is that I can bind the fiddeling of the action attribute to a specific button. The drawback is that If the user disables JavaScript or doesn't have support the user name and password will be submitted in clear text.

3. A composite approach. I could use AJAX to load a page containing the control that uses JavaScript to change the post. That way the control won't even be rendered if the user doesn't have JavaScript and instead render a button that sends the user to a log in page.

The last alterna开发者_运维知识库tive is the best choice in my situation but it gets complicated without going into details.

So my question is, Is there any other way of achieving a secure loginin control in ASP.NET without the use of JavaScript?

I've been searching my finger off for a solution to this problem without finding anything so if any one can crack this nut, kudos!

Can't you just move your control, with it's own form, outside of the <form runat="server"> section?

<form method="post" action="https://www.example.com/securepage.aspx">
    <ui:securelogincontrol id="SecureLogin" runat="server" />
</form>

<form runat="server">
    <!-- all the stuff that requires a webform -->
</form>

The usual approach is to have a dedicated login page with only the <asp:Login> control contained on it to submit the form. Do you have a different set up to this?

If you have a dedicated login page then you can set the page to require SSL in web.config

<authentication mode="Forms">
    <forms loginUrl="~/login.aspx" slidingExpiration="false" timeout="500" requireSSL="true"/>
</authentication>

You can also authenticate client-side using the ASP.NET AJAX authentication services

There is no other solution that I have come across - this is one of the major issues with the web forms approach and a big plus for MVC. Web forms require you to have a dedicated sign in page that utilises HTTPS.

The second approach you outline is the easiest one to go with - as long as you are happy to allow users without JavaScript to log in over HTTP. You could have a link below your login saying something like "Secure login" that is hidden by JavaScript to give them the option.

Hi all just wanted to get back to you with the approach that I ended up using.

The requirements that we had where these:

1. The login should be secured, SSL
2. It should support non javascript senarios
3. The login control should be able to be placed anywhere in the sites flow.
4. Only pages that needed Https should use https (thus moving back and forward between protocols)

So with the fact that we already had a website that relied on the webforms model with one single form tag, and the fact that Contentplaceholders rely on a form tag with runat="server" and our site is fully constructed with MasterPage's and ContentPlaceholder's, the only thing that supported this was to use the I-Frame solution.

This poses some other challenges regarding page reloading, javascript (because almost evryone uses javascript anyway), http to https and https to http postings.

As required, we didn't want all pages to post to https, only those who would send sensitive information over the wire. To handle this we added a per page property stating if it should do a secure post. When this flag is checked, we do a check to see wether the user already comes from a secure page or not. By doing this we can change the forms post action to reflect the required security settings.

To solve the Javascript issue, calling to and from different protocols (it's seen as an XSS exploit to call javascript in different domains) we do double postbacks to the page with some added parameters int the querystring.

Well hope this tips can help you too.