Forms Authentication w/SubFolders

[JTR]

I'm trying to create a structure I can share
authentication from a root application with many
subordinate applications (subfolders).

The web.config file for the root has:

<authorization>
<allow users="*" />
</authorization>

Then, each subordinate application (subfolder) has a
web.config with the following:

<authentication mode="Forms">
<forms name=".BUZZARD"
loginUrl="../login.aspx">
</forms>
</authentication>
<authorization>
<deny users="?" />
</authorization>

When the user access a resource in a subfolder, the login
form is displayed and authenticates the user correctly,
including the creation of an authentication ticket. But,
when the login form attempts to redirect the browser to
the requested secure resource, the login form is
redisplayed. I have tried using
FormsAuthentication.RedirectFromLoginPage() and
Response.Redirect() with the same results.

Any ideas?

JTR.

 

[JTR]

I was able to demonstrate the same as you in terms of ASPX
pages authenticating/redirecting properly as long as they
exist in the root. Unfortunately, not much good for an
application.

I performed more testing/analysis and was able to get an
ASPX page in a nested folder to be
authenticated/redirected properly as long as the nested
folder was not classified as an ASP.NET Application (IIS
Manager) and the corresponding assembly (DLL) was located
in the root folder's BIN folder. I plan to follow this
path and use an application config file (<app>.dll.config)
in the root bin folder to setup alternate codebase paths.

JTR.

 

[Joel Finkel]

JTR,

Does you server have any underscrores ("_") in its name?

-Joel

 

[Scott Scott]

Have you thought about using an ISAPI filter like AuthentiX ?

There is a free version (100 users/2 groups):

http://www.flicks.com/authentix100/

and of course a full version .

http://www.flicks.com/prod.htm#authnx

 

[John Kraft]

I have come into this newsgroup precisely to look for an answer to this. I
am quite amazed to see this very question! Furthermore, I see a posting
made a few days later that reports a similar issue: Sucessful authentication
returns to the login page.

My situation is that in root, aspx pages authenticate fine (the login.aspx
form is in the root, as well). But in sub-directories, while the login.aspx
form is correctly invoked, the redirect returns to the login.aspx page.
This happens regardless of the presense of a web.config file in the
subdirectory, or the contents of it. I have played around with variations
for about 3 hours. I have verified that the cookies is being created and
sent, but for some reason the application in the sub-directory is not hip to
the fact that this cookie exists, and returns to the login.aspx page.

Pretty big problem. Hope there is a simple fix.

Thanks for all suggestions.
-Joel

I was having this problem too. It turned out to not be a problem with
the cookie, but with the encryption/decryption of the cookie. Even
though the cookie was inside the same project, even though a subfolder,
the encryption key is supposed to be the same. It wasn't. I tried
manually setting the encryption key in the webconfig. I even tried
putting another copy of the same web.config into the subdirectory. For
some reason nothing seemed to work. We ended up setting the
protection="All" to protection="None" to get around it. We still have
not corrected the problem, but if you make that change it might indicate
that the problem is not actually with the cookie.

John

 

[Joel Finkel]

Glen,

Unfortunately, even under .NET 1.1 this problem still exists. I am quite
convinced that the FormsAuthentication.Authenticate works correctly and is
returning the proper value. The problem is that
FormsAuthentication.RedirectFromLoginPage is returning to the login page.

I am now also convinced that this problem is not related to improperly named
servers or domains, as I have completely rebuilt my network and completely
uninstalled and reinstalled .NET on the server.

I would like to know if ANYONE has this configured and running correctly!
In other words, can someone who actually has it working tell us how they
have things configured?

Thanks!

Joel Finkel
(e-mail address removed)

 

[Joel Finkel]

Folks,

I have investigated the situation on my configuration a bit more, and have discovered an anomaly. Consider the following structure:

root/admin/secure

login.aspx is in root/admin
secret1.aspx is in root/admin
secret2.aspx is in root/admin/secure

Both secret1.aspx and secret2.aspx are "protected" by login.aspx because there is a Web.config file in root that looks like this:

<configuration>

<location path="admin">
<system.web>

<authorization>
<deny users="?" />
</authorization>

</system.web>
</location>

<system.web>

<identity impersonate="false" />

<authentication mode="Forms">

<forms
name="TESTCOOKIE"
loginUrl="/root/admin/login.aspx"
protection="All"
timeout="30"
slidingExpiration="true"
path="/">

<credentials passwordFormat="MD5" >
<user name="blah" password="0ED5819EAD9C9E11DDF202AE0B2993E4"/>
</credentials>

</forms>
</authentication>

<authorization>
<allow users="*" />
</authorization>

</system.web>

</configuration>

If you insert a call to FormsAuthentication.GetRedirectUrl() in login.aspx and look at the output, you will notice that it returns a slightly different string when login.aspx is called to authenticate secret1.aspx and secret2.aspx. Of course, the URLs are different in that when called from secret2.aspx: it has the suffix, "/secure". The anomaly is that:

for secret1.aspx, it returns: ROOT/admin
for secret2.aspx, it returns: root/admin/secure

This is one of those things that make you go, "Hmmm." If there is THIS anomaly, one wonders what others are to be found.

Joel Finkel
(e-mail address removed)

 

[Joel Finkel]

John,

Your workaround, to set "protection=none" does, indeed work. This provides
very poor security, however, as the cookies are neither encrypted nor
validated to ensure that they have not been tampered with. I suppose one
way to tighten things up is to use SSL for the authentication code
(login.aspx).

-Joel