Something like this in a module would probobly work in an HttpModule, or probobly even the handler:

bool authorized = UrlAuthorizationModule.CheckUrlAccessForPrincipal("~/Admin/", context.User, "GET");
authorized &=
UrlAuthorizationModule.CheckUrlAccessForPrincipal("~/Admin/", context.User, "POST");
authorized &=
UrlAuthorizationModule.CheckUrlAccessForPrincipal("~/Admin/", context.User, "PUT");
if(!authorized)
   
FormsAuthentication.RedirectToLoginPage();I'm not at home so I cant put it into a working module or the main IHttpHandlerFactory that would take the blog settings into account for subfolders and such.


From: "Phil Haack" <haacked@gmail.com>
Sent: Thursday, September 20, 2007 2:53 PM
To: subtext-devs@lists.sourceforge.net
Subject: Re: [Subtext-devs] Securing the admin section...


Not yet, because then we lose the redirect to login logic. Right now, all the admin classes inherit from AdminPage which enforces security.


I'd like a centralized approach to handling it. I'm leaning towards an HttpModule that will ensure that requests to the admin page are authenticated.

 

I *do* think we should put the PrincipalPermission attribute on any method that has potential for abuse, such as methods that write to the file system like the one that caused this issue. We want to have security in depth.

 

From: subtext-devs-bounces@lists.sourceforge.net [mailto:subtext-devs-bounces@lists.sourceforge.net] On Behalf Of Wyatt Barnett
Sent: Thursday, September 20, 2007 11:28 AM
To: subtext-devs@lists.sourceforge.net
Subject: Re: [Subtext-devs] Securing the admin section...

 

Not quite the "ASP.NET way", but would it be possible to just decorate the admin codebehind classes with properly specified PrincipalPermission attributes? That will backstop things pretty hard . . .

 

 

Wyatt W. Barnett

Lead Application Developer

National Cable & Telecommunications Association

25 Massachusetts Ave N.W. - Suite 100

Washington, DC 20001

202-222-2403 (v)

202-222-2401 (f)

202-250-4837 (m)

wwb@ncta.com


From: subtext-devs-bounces@lists.sourceforge.net [mailto:subtext-devs-bounces@lists.sourceforge.net] On Behalf Of Phil Haack
Sent: Thursday, September 20, 2007 2:14 PM
To: subtext-devs@lists.sourceforge.net
Subject: Re: [Subtext-devs] Securing the admin section...

 

That's just it, we *do* have a second web.config in the Admin dir. But because of the url rewriting, it doesn't work if you have a subfolder specified.

 

Ex. http://haacked.com/admin/ is secured by the web.config in the admin dir.

 

But if I specified a subfolder for my blog:

 

http://haacked.com/test/admin/ would not be secured by the web.config in the admin dir. "Test" does not correspond to a folder. And you can't use wild cards in the path attribute of the <location /> element. L


To get it to work, we'd have to create a <location path="subfolder/."> For every blog in the installation with a subfolder.

 

Perhaps rolling our own FileAuthorizationModule is an option, but I'd like to avoid that if there's something simpler I'm missing.

 

From: subtext-devs-bounces@lists.sourceforge.net [mailto:subtext-devs-bounces@lists.sourceforge.net] On Behalf Of Travis Illig
Sent: Thursday, September 20, 2007 10:23 AM
To: subtext-devs@lists.sourceforge.net
Subject: Re: [Subtext-devs] Securing the admin section...

 

...or couldn't you throw a second web.config in the admin folder and restrict permissions from there?  It wouldn't be centrally configured, but the URL rewriting wouldn't affect it.

 

-T

 

On 9/20/07, Travis Illig <tillig@paraesthesia.com> wrote:

You actually can't do the web.config-from-database thing.  I've been fighting a similar issue in trying to solve how to deploy an application with as little filesystem impact as possible.  Unfortunately, there are a few things you can't virtualize and the web.config is one of them.  The best you can do is break sections out into separate files, but those files also have to be in the filesystem.

 

(You also can't virtualize App_Code, App_Themes, and Global.asax.)

 

That said, if you're trying to govern whether a user can get to a specific path based on some programmatic logic, you might want to look at System.Web.Security.FileAuthorizationModule, which I believe is what is used to determine whether a user has access to a specific file/path.  You can't derive and override, but you could potentially "roll your own" and have that read from a database.
 

-T
 

On 9/20/07, Phil Haack < haacked@gmail.com> wrote:

Hi All,

 

If a blog specifies a "subfolder" this causes a problem in the way we secure the admin section.

 

For example:

 

NO SUBFOLDER: http://blog-domain/admin/

Vs

SUBFOLDER: http://blog-domain/subfolder/admin/

 

In the second case, the "subfolder" doesn't actually exist. This URL is created by URL rewriting. Because of that, the settings in the web.config in the physical Admin directory does not apply.

 

Ideally, we would be able to control the settings in the web.config. Otherwise we need to remove that file because it's causing confusing and handle the security via code. Perhaps via an HttpModule to be on the safe side.

 

The alternative solution is to restructure our admin urls so that "Admin" is always at the root. For example:

 

Instead of: http://blog-domain/subfolder/admin/

Your admin would be:

 

http://blog-domain/ admin/subfolder/

 

I'm not particularly a fan of this approach, but it would mean that the web.config within the Admin directory would work as expected.

 

Anyone know of a way to have a Web.config section read from the database?

 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Subtext-devs mailing list
Subtext-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/subtext-devs




--
Travis Illig
http://www.paraesthesia.com




--
Travis Illig
http://www.paraesthesia.com