RedirectFromLogin Fails

[Mark Olbert]

I have an ASP.NET application that refuses to honor the RedirectFromLogin() method of
FormsAuthentication.

What happens is, when I try to access a restricted page, the login page gets brought up, I enter a
username and password, which are validated, and then the redirect gets called.

Unfortunately, the redirect lands me right back on the login page! And when I check
User.Identity.Name on that "failed redirect", the username is blank, as if it was never set. I have
cookies enabled in my browser, BTW.

I am wondering if there is some IIS configuration that needs to be done to allow formsauthentication
to work. This might explain why the code used to work and now doesn't, since it's running on a
different server.

Here is the code that USED TO work (before I moved development off of my local XP box and onto a
Win2K server on my intranet):

switch( secZone )
{
case SCEF_Browser.WebZone.Administrator:
// administrative rights
FormsAuthentication.RedirectFromLoginPage("user1", false);
break;

// other cases left out; the above one does get triggered when you walk through the debugger
}

// this next demonstrates that the correct redirect URL is in place
string crap = FormsAuthentication.GetRedirectUrl("user1", false);

Here are extracts from my Web.config file:

<configuration>
<system.web>
<!-- snip -->

<!-- AUTHENTICATION
This section sets the authentication policies of the application. Possible modes are
"Windows", "Forms",
"Passport" and "None"
-->
<authentication mode="Forms">
<forms name=".ASPAUTHSCEF" protection="None" loginUrl="ssl/login.aspx"
timeout="30" />
</authentication>
<authorization>
<allow users="?" />
</authorization>

<!-- snip -->

<!-- SESSION STATE SETTINGS
By default ASP .NET uses cookies to identify which requests belong to a particular
session.
If cookies are not available, a session can be tracked by adding a session identifier to
the URL.
To disable cookies, set sessionState cookieless="true".
-->
<sessionState
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;user id=sa;password="
cookieless="false"
timeout="20"
/>
</system.web>
<location path="ssl/members">
<system.web>
<authorization>
<allow users="user1" />
<deny users="*" />
</authorization>
</system.web>
</location>
</configuration>

 

[Steven Cheng[MSFT]]

Hi Mark,


Thanks for using MSDN newsgroup Service. I'm sorry for being late to reply.
From your description, I'd like to confirm my understanding of your issue:

One of your test ASP.NET web application is using the FormAuthentication
Mode. You set one sub folder under protection so as to prevent being
visited via unauthenticated user. And this worked well on XP enviroment,
however, you found it not work when you did the same thing on a W2K
server? Pleasae correct me if anything of my understanding or quite correct.

I've read the code and the web.config setting you provided. The setting is
quite correct for the Form Authentication. So this seems a bit strange.
Currently, I am finding proper resource to assist you and we will update as
soon as posible.
Meanwhile, if you have any new findings or information on this issue,
please also let me know. Thanks.


Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Steven Cheng[MSFT]]

Hi Mark,


I've made a simple test in account of your description on my side. I just
made a simple application which has two main pages one is for login and
another is protected for particular access requirement. The Application's
folder structure is as below:
/AppFolder/
Login.aspx
.....
web.config
secure/
protected.aspx

in the Login.aspx , with such code:

private void btnLogin_Click(object sender, System.EventArgs e)
{
if(txtUsername.Text != null && txtUsername.Text.Length >0)
{
FormsAuthentication.RedirectFromLoginPage(txtUsername.Text,false);
}
}



The web config file's content is :
-------------web.config file------------------------------------
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<compilation
defaultLanguage="c#"
debug="true"
/>


<customErrors
mode="Off"
/>


<authentication mode="Forms">
<forms name=".ASP_NEW_WEB_APP" protection="None"
loginUrl="Login.aspx" timeout="30" />
</authentication>


<authorization>

<allow users="*" />

</authorization>

<trace
enabled="false"
requestLimit="10"
pageOutput="false"
traceMode="SortByTime"
localOnly="true"
/>

<sessionState
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data
source=127.0.0.1;Trusted_Connection=yes"
cookieless="false"
timeout="20"
/>


<globalization
requestEncoding="utf-8"
responseEncoding="utf-8"
/>

</system.web>

<location path="secure/Protected.aspx">
<system.web>
<authorization>
<allow users="steven" />
<deny users="*" />
</authorization>
</system.web>
</location>

</configuration>
------------------------------------------------------------------


Also, I've allow the "Anonymous" access enable for the Virtual Directory in
IIS .

I first create this application on a machine with WINXP and VS.NET2003.
Everything runs ok. After that, I use the "Copy Project" function in the
VS.NET , just select the "Project ---->Copy Project" menu and specify a url
on a remote WIN2K server. After that, the project is fully copied to a
WIN2K server. Then I run the application on the win2k server machine, it
result is the same with that on the win XP one.

As for the different situation we met. Would you please try creating a
simple application(just as the one above) and then use the "Copy Project"
to move it to the certain WIN2K server machine. If the problem remains, I
think the problem may due to something else (maybe the enviroment or..).
Also, you may have a try move the project to some other machines( server or
xp or ...) to see whether this problem remains if you feel it convenient.

In the meantime, if you have any new findings , please also let me know.
Thanks.


Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)