Hi antony,
antonyliu2002@yahoo.com schrieb:
> 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/archive/2006/02/24/ASP.NET-2.0-Membership_2C00_-R
oles_2C00_-Forms-Authentication_2C00_-and-Security-Resources-.aspx
Hope this helps,
Roland
antonyliu2002@yahoo.com - 30 Jun 2007 06:01 GMT
> Hi antony,
>
[quoted text clipped - 33 lines]
>
> 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 - 30 Jun 2007 08:51 GMT
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