Forms authentication, user login status is not maintained

[antonyliu2002]

I am testing ASP.NET 2.0 Forms athentication with user credentials in
SQL Server 2005. I don't want to put user credentials in web.config,
so the credentials section is commented out. The following is the
relevant part in my web.config.

<authentication mode="Forms">
<forms name=".MyWebAppAuth"
path="/"
loginUrl="Default.aspx"
protection="All"
timeout="30">

<!-- I will get username
and password from SQL Server.
<credentials>
<user name="myusername" password="mypassword"/>
</credentials>
-->
</forms>
</authentication>

<!-- keep out anonymous users -->
<authorization>
<deny users="?"/>
</authorization>

My login page is Default.aspx as you see from above. The code-behind
of Default.aspx, i.e., Default.aspx.cs, calls a stored procedure in
SQL Server 2005, which takes the user name and password as its
parameters. It returns 1 if the username/password pair is found,
otherwise, it returns 0.

In Default.aspx.cs, I say:

if (validateUser(name, password) == 1)
{
Response.Redirect("UserProfile.aspx");
}
else
{
// authentication failed. show a message
lblMessage.Text = "Invalid username/password."
}

validateUser is simply a method I implement to validate the user. I
know the login process itself works OK. In other words, validateUser
method does return 1 if the username/password pair is found in the
database, and it does return 0 if the username/password pair is not
found.

But, the user is kicked back to Default.aspx immediately after he is
redirected to UserProfile.aspx.

This must have to do with the section in web.config, which says:

<!-- keep out anonymous users -->
<authorization>
<deny users="?"/>
</authorization>

Because if I comment out this section, the user can be successfully
redirected to UserProfile.aspx and stays on that page nicely.

So, apparently, my user login satus is not maintained in the
application.

I cannot google out topics on maintaining user login status. Please
give me a hint. Thanks a lot.

 

[Roland Dick]

Hi antony,

My login page is Default.aspx as you see from above. The code-behind
of Default.aspx, i.e., Default.aspx.cs, calls a stored procedure in
SQL Server 2005, which takes the user name and password as its
parameters. It returns 1 if the username/password pair is found,
otherwise, it returns 0.

Just a thought here - it seems like you are not using the membership
provider for the logon process (you call your own stored procedure) and
rely on the integrated authorization mechansims for access control.
What I think happens is that you call the stored proc, but authorization
manager does not know that a user signed on. Therefore, the provider
redirects you to the login page.

My advice is to either use the membership provider that's included with
asp.net (downside: your database has to have the tables required which
aspnet_regsql can set up for you).
Or, if you want to keep the custom stored proc etc., create your own
membership provider.
Or, as a third option, don't rely on the authorization manager (the part
with deny ="?") but have your own routine, i.e. set a session variable
after succesful login, and check for that session variable in the
page_load of each page (and if it isn't there, redirect to your login
page manually).

Bottom line: You have to use an asp.net membership provider to use the
authorization features.

Scott Guthrie has a collection of good links on this and other
security-related matters on
http://weblogs.asp.net/scottgu/arch...entication_2C00_-and-Security-Resources-.aspx

Hope this helps,

Roland

 

[antonyliu2002]

Hi antony,



Just a thought here - it seems like you are not using the membership
provider for the logon process (you call your own stored procedure) and
rely on the integrated authorization mechansims for access control.
What I think happens is that you call the stored proc, but authorization
manager does not know that a user signed on. Therefore, the provider
redirects you to the login page.

My advice is to either use the membership provider that's included with
asp.net (downside: your database has to have the tables required which
aspnet_regsql can set up for you).
Or, if you want to keep the custom stored proc etc., create your own
membership provider.
Or, as a third option, don't rely on the authorization manager (the part
with deny ="?") but have your own routine, i.e. set a session variable
after succesful login, and check for that session variable in the
page_load of each page (and if it isn't there, redirect to your login
page manually).

Bottom line: You have to use an asp.net membership provider to use the
authorization features.

Scott Guthrie has a collection of good links on this and other
security-related matters onhttp://weblogs.asp.net/scottgu/archive/2006/02/24/ASP.NET-2.0-Members...

Hope this helps,

Roland

Hi, Roland, I think you are right. I also had vaguely thought that
not using the asp.net membership provider might be causing this
problem. I just wasn't sure. But after I read your reply, I think it
must be the case.

I know your 3rd option pretty well. I have done that before with
classic ASP (btw, I think that's the classic authentication strategy
with classic ASP). But, it is sorta cumbersome to have to validate
the user on each single page.

I will rewrite a classic ASP web application in ASP.NET, and we
already have the user name/password in SQL Server, plus many other
fields. But, I will see if I can manage to integrate the asp.net
membership provider with my current user info table. If not
successful, I may have to implement my own membership provider. I
have never done this, but I am very interested in looking into it.

 

[Roland Dick]

Hi Anthony,

glad I could be of help.
On a side note, as you wrote it is a lot of work to check whether the
user is logged in via a session variable in each page_load. However, you
can do that in one single page and derive every other page from that
(i.e. extend the Page class). This way, you would have to do this only
once. But you still have to remember to change the base class of your
pages though.

Anyway, I think it is the "cleaner" way to stick with the membership
providers from asp.net.

Good luck,

Roland