I have been tasked with implementing a secure account login system for a website's content management system. I have built a solution around an access masterpage that handles all account access functions. Here is the Page_Load
Protected Sub Page_Load() Handles Me.Load
If Not Request.IsSecureConnection Then
Response.Redirect(Request.Url.ToString.Replace("http://", "https://"))
End If
UpdateSecurity()
End Sub
And the definition of UpdateSecurity()
Private Sub UpdateSecurity()
PageContentPanel.Visible = Session("access")
PleaseLogInPanel.Visible = Not Session("access")
End Sub
As you can probably infer from the snippet, having "access" set in the Session makes an asp:Panel containing the content of whatever child page the user requested visible, otherwise, the PageContentPanel is hidden, and the PleaseLogInPanel with a username and password prompt is made visible. In the handler for the login button (also on the login Panel), the posted credentials are verified and if correct, Session values are added.
I was wondering if this implementation is fundamentally sound or not. Page requests from not logged in users still execute (I think), but the results are hidden inside an invisible asp:Panel. I'm not familiar enough with the ASP.NET security model to know if this poses risks or not from wayward POSTs. If a child page utilizes this masterpage, what access do not logged in users have to resources on the page?
1 Answer 1
What you are doing right now is not fundamentally correct. This link http://learn.iis.net/page.aspx/170/developing-a-module-using-net/ explains developing a custom authentication module.
Also you should read about page life cycle while working asp webforms. http://msdn.microsoft.com/en-us/library/ms178472.aspx
-
\$\begingroup\$ why is what I'm doing not fundamentally correct? Where is the hole? \$\endgroup\$twsaef– twsaef2011年12月05日 00:40:07 +00:00Commented Dec 5, 2011 at 0:40