Forms Authentication

[zblock]

I have a subdirectory I'm protecting with Forms Authentication. When I browse to a page in that directory - say http://localhost/MySite/MembersOnly/ProtectedPage.aspx - it behaves as expected. However, if I instead browse to http://localhost/MySite/ProtectedPage.aspx, the page is served without having first been authenticated and without the page existing in that directory... I imagine I've setup my object config wrong?

My objects are setup like:


<objects xmlns="http://www.springframework.net">


<object id="masterPage" type="~/Master.aspx" />
<object id="basePage" abstract="true">
<property name="Master">
<ref object="masterPage" />
</property>
<property name="ImagesRoot" value="images" />
</object>

<object type="~/about.aspx" parent="basePage">
</object>

<object type="~/membersonly/newsletter.aspx" parent="basePage">
</object>
</objects>


Thanks.

-- John

[Aleks Seovic]

Hi John,

Spring.NET uses page name as object ID, so it finds the page regardless of the URL. This is very useful in certain scenarios, but in your case that's not what you want because ASP.NET security doesn't kick in.

Solution in your case (and recommended way of doing it anyway) is to use child context for your secure pages. Simply remove protected page definition from the root context config file and add a new Web.config to the /membersonly subdirectory with the following content:


<configuration>

<spring>

<context type="Spring.Context.Support.WebApplicationContext, Spring.Web">
<resource uri="config://spring/objects" />
</context>

<objects xmlns="http://www.springframework.net">

<object type="newsletter.aspx" parent="basePage"/>

</objects>

</spring>

</configuration>



You can check documentation for more details on hierarchical contexts and the benefits of setting things up this way.

Regards,

Aleks

[zblock]

Thanks Aleks. One quick follow up to make sure I'm setting up the hierarchy right...

I've moved my master page definition to an xml file that I reference as a resource within each web.config's context section. It works, but I want to make sure it's proper...

BTW, you guys do a great job with this forum!

Thanks.

-- John

[Aleks Seovic]

Hi John,

No need for that, definitions in the child context can reference any definitions from one of the context higher in the hierarchy, so your members only pages can simply reference definitions from the root context, such as master page or, in the example I provided earlier, basePage.

Also, all your services, DAOs, etc. will typically be configured in the root context so pages from any of the child contexts can use them.

The best way to look at the child context is as a way to encapsulate specific component, while still allowing it to use common, shared functionality. Objects in child context can see all objects in the parent context(s), but the opposite is not true. You can also override parent definition by creating child definition with the same name.

HTH,

Aleks