469,140 Members | 1,204 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,140 developers. It's quick & easy.

Can you find out which web.config contained your setting?

I have a custom web.config section similar to the following:

<CustomAuthSettings attr1="" attr2="">
<Locations RedirectUrl="Invalid.aspx">
<add Path="test.aspx" Roles="1,2,3" Permissions="4,5,6" />
</Locations>
</CustomAuthSettings>

Everything seems to work just fine. When I have config files in nested
folders, Attr1 and Attr2 of the CustomAuthSettings section correctly
show the values of the "closest" config file. In addition, all
locations exist in my collection from ALL config files up the folder
tree. This seems like the behavior I want. However, I have no clue
from which web.config file the location came from. I need to know this
information because I want to correctly figure out the resolved path
of each location's path attribute.

Is it possible to ascertain this information? I've been snooping
around the ConfigurationElement class with no luck.

Thanks!

Jason
Jul 22 '08 #1
5 1997
tree. This seems like the behavior I want. However, I have no clue
from which web.config file the location came from. I need to know this
information because I want to correctly figure out the resolved path
of each location's path attribute.
Simple Answer: No.

The ConfigurationManager gives the unified result.
--
Happy Hacking,
Gaurav Vaish
http://blogs.mastergaurav.com
http://eduzine.edujini-labs.com
---------------------------
Jul 23 '08 #2
That sucks. My application has defined roles and permissions. I use
ASP.Net authentication to lock out folders and files by roles using
the <authorizationsection. My problem is that I'd like to extend the
security so I could also lock out folders and pages by permissions. I
figured I'd still use the <authorizationsection for role-based
security, but if I wanted to grant access to users based on a
permission (permissions are groups into roles), I could use my own
config section. I would modify my Master page to read the config to
see if the page or folder was being restricted by permissions. I'd
then check my user's profile to see if they indeed had that
permission. I had this in mind:

<CustomAuthSettings>
<Locations RedirectUrl="AccessDenied.aspx">
<add Path="Page1.aspx" Permissions="Perm1, Perm2" />
<add Path="Page2.aspx" Permissions="Perm1" />
</Locations>
</CustomAuthSettings>

Of course, I could write code in each individual page to check for a
specific set of permissions, but having it in the web.config along
with the <authenticationsection made better sense for
maintainability. I can still get this to work, but only at a single
folder level.

The ElementInformation.Source property is NOT null if the <location>
existed in the web.config from the same directory. This sort of gets
me where I want to be. But it would be ideal to be able to set
security up the folder tree (e.g., path="subfolder/default.aspx").

Any other ideas?

Jason
Jul 23 '08 #3
re:
!I can still get this to work, but only at a single folder level.

Couldn't you try adding a setting to the AppSettings section,
of each web.config you have, which contains the name of the directory it's in ?

i.e. :

<appSettings>
<add key="directory" value="directory_name" />
</appSettings>

Then, it's easy to query the current web.config, or any web.config above it in the application's directory tree,
for the data you want, coupled with the directory's name (presumably so you can can modify it, right ?).

Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
"daokfella" <jj******@hotmail.comwrote in message
news:53**********************************@79g2000h sk.googlegroups.com...
That sucks. My application has defined roles and permissions. I use
ASP.Net authentication to lock out folders and files by roles using
the <authorizationsection. My problem is that I'd like to extend the
security so I could also lock out folders and pages by permissions. I
figured I'd still use the <authorizationsection for role-based
security, but if I wanted to grant access to users based on a
permission (permissions are groups into roles), I could use my own
config section. I would modify my Master page to read the config to
see if the page or folder was being restricted by permissions. I'd
then check my user's profile to see if they indeed had that
permission. I had this in mind:

<CustomAuthSettings>
<Locations RedirectUrl="AccessDenied.aspx">
<add Path="Page1.aspx" Permissions="Perm1, Perm2" />
<add Path="Page2.aspx" Permissions="Perm1" />
</Locations>
</CustomAuthSettings>

Of course, I could write code in each individual page to check for a
specific set of permissions, but having it in the web.config along
with the <authenticationsection made better sense for
maintainability. I can still get this to work, but only at a single
folder level.

The ElementInformation.Source property is NOT null if the <location>
existed in the web.config from the same directory. This sort of gets
me where I want to be. But it would be ideal to be able to set
security up the folder tree (e.g., path="subfolder/default.aspx").

Any other ideas?

Jason

Jul 23 '08 #4
Not sure what is the first problem you are trying to solve but it might
worth to check how this is done for
http://msdn.microsoft.com/en-us/library/6hbkh9s7.aspx.

Using the same mechanism would allow to define things for a particular path
file tiehr using multiple web config files or by using a single config file
with a location tag. You don"t care were it comes physcially. you just care
about the location parent element...

--
Patrice

"daokfella" <jj******@hotmail.coma écrit dans le message de groupe de
discussion :
53**********************************...oglegroups.com...
That sucks. My application has defined roles and permissions. I use
ASP.Net authentication to lock out folders and files by roles using
the <authorizationsection. My problem is that I'd like to extend the
security so I could also lock out folders and pages by permissions. I
figured I'd still use the <authorizationsection for role-based
security, but if I wanted to grant access to users based on a
permission (permissions are groups into roles), I could use my own
config section. I would modify my Master page to read the config to
see if the page or folder was being restricted by permissions. I'd
then check my user's profile to see if they indeed had that
permission. I had this in mind:

<CustomAuthSettings>
<Locations RedirectUrl="AccessDenied.aspx">
<add Path="Page1.aspx" Permissions="Perm1, Perm2" />
<add Path="Page2.aspx" Permissions="Perm1" />
</Locations>
</CustomAuthSettings>

Of course, I could write code in each individual page to check for a
specific set of permissions, but having it in the web.config along
with the <authenticationsection made better sense for
maintainability. I can still get this to work, but only at a single
folder level.

The ElementInformation.Source property is NOT null if the <location>
existed in the web.config from the same directory. This sort of gets
me where I want to be. But it would be ideal to be able to set
security up the folder tree (e.g., path="subfolder/default.aspx").

Any other ideas?

Jason

Jul 23 '08 #5
Patrice,

I think this is just what I need. I'll just reconfigure my custom
settings section to something like this:

<CustomAuthSettings RedirectUrl="AccessDenied.aspx"
Permissions="Perm1,Perm2" />

and place it in a <locationsection. Thanks.

Jason
Jul 24 '08 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by David | last post: by
2 posts views Thread by Max Metral | last post: by
12 posts views Thread by Ben | last post: by
10 posts views Thread by salty | last post: by
13 posts views Thread by Jonny Bergdahl | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
1 post views Thread by Mortomer39 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.