Ok,

Now PLEASE correct me if I am wrong, but what is the point in providing a feature, when microsoft does not have a tool to remotely manage profile/membership/role features that are in asp.net 2.0

I am pretty frustrated after finding that there is NO remote configuration tool for these features, so now that I have put my website up on my webhost, there is no way for me to create roles, add/delete users manually, without going into the sql tables myself (which is a major pain btw)

Originally I opted for the membership/role management because I figured, hey...microsoft already has something in place to do this, so I don't have to worry about a registration system for my site, this shaves weeks off my development. Now I come to find that I am probably going to have to end up going back and doing my own membership system, because this membership/roles features are USELESS without a remote configuration tool.

Now, I know what someone will say when they respond to this, "Oh, but you have to think about the security issues, if you had a remote tool someone could get in and mess everything up". This is just ignorance. So you can PASSWORD PROTECT it. Just like every other control panel and database login out there.

Once again, maybe I have completely missed the ball here, so SOMEONE! please prove me wrong here, i beg you...it will save me another month development time on my already late website launch.

sigh....

sean

Using the login related components included with ASP.NET, you can easily and quickly whip up pages that will allow you to register a new user, allow users to change passwords, etc.  AS to the decision to allow the administrative tool to work only on the machine the Web site is running on, I am sure it is a security risk that MS decided not to deal with...

I appreciate your comments, but again, now I have to go through and make ADDITIONAL registration pages that I shouldnt have to create. To manage the information that should already be in place.

I can understand that they provide classes to easily manipulate this data, but the fact that MS brags that this feature is complete and does everything you need it to is just misleading at best.

I guess I'm going to bite the bullet and go back through and develop my own user registration/login/role management system. which is quite disappointing because now I have to go back through and add a feature that I would have thought was already in place.

Thanks Microsoft!

 

Did you try Google?

http://weblogs.asp.net/scottgu/archive/2006/01/09/434925.aspx

http://www.qualitydata.com/default.aspx

I actually saw the quality data site and considered purchasing that product, but again...I shouldnt have to be purchasing tools that should already be included in features that microsoft is providing.

Sorry, I dont mean to be trolling here, but it's just aggravating to go and spend money on something that I shouldnt have to purchase. Even though it is only $60, I am so discouraged, I am going to develop my own registration system from scratch so I don't even have to use any of microsoft's tools to manage my membership user base.

In addition, after browsing google and other forums, it seems that quite a number of people are having ALOT of problems with the membership/profile/role provider tools that are supplied by microsoft in production websites, so rather then flirt with disaster, I feel more comfortable developing my own system so IF it does break, I at least know where the problem is because it is my code, rather than post on here or google begging for help while my website is going down in flames.

Thanks for your postings.

P.S.
If any "ASP.NET Team" users browse this thread, PLEASE make a note that it is absolutley amazing to me that such a large number of people are having problems with these tools, ESPECIALLY remote management like I am stating here, and try to make it a point to include that feature in the next release. PLEASE!! it will make alot of peoples lives SO much easier. If your going to provide these tools, please provide them from beginning to end, and not half way in between.

I totally agree!  I've spent an entire month just building the same functionality from scratch and it wasn't quick and it wasn't easy and it's still not complete, thus the reason I'm trolling through this forum.  Also, I would like to point this out:  I tried to go to the framework version in my Windows directory and pilfer the code for this functionality.  Guess what?  It's out of date.  It was apparently written for Framework 1.1.  The help files read like sterio instructions, the SDK code is crappy and a Google search will show that people all over are having problems with it.

The problem I'm having?  I want to be able to restrict access to individual pages?  What advice do I get?  Move crap into subfolders and secure the folders.  So now my file structure is being dictated to me as well.  No, thank you...I refuse.  It looks like I'll be using redirects as in ASP.  What have I gained?  Nothing.

I like the concepts behind ASP.NET but it's implementation sucks and it's clearly meant to make third party code and component providers rich by providing out-of-the-box solutions that should be in .NET to begin with.

>I want to be able to restrict access to individual pages?

There are three ways to do this:

1) If you have a lot of related pages, such as an administration tool, it's easier to put all the pages in a subfolder and protect the subfolder.

2) If you want finer control over pages in the same folder, you can protect individual pages in the web.config.  You can set access by role or user ID, or both.  This example allows only logged-in users to access test.aspx:

<LOCATION path="test.aspx">
<SYSTEM.WEB>
<AUTHORIZATION>
<ALLOW users="*" />
</AUTHORIZATION>
</SYSTEM.WEB>
</LOCATION> 

Put these sections in your web.config just before the final </configuration> tag.

3a) You can use the User.IsInRole on each individual page, which would be bulky, but effective.

3b) You could create a base page, which inherits from system.web.page, and add your own authorization routine in the page_onload.  Then have every page in your site inherit the base page (rather than system.web.page) and your authorization will be applied to every page.

For an example, look at http://www.asp.net/QuickStart/aspnet/doc/security/membership.aspx#progauth.

I haven't heard from many people having problems with the Membership/Roles implementations.  There are now tens of thousands of sites deployed using them, and I'd definitely recommend going that approach.

This page has a ton of information regarding ASP.NET 2.0 security resources: http://weblogs.asp.net/scottgu/archive/2006/02/24/438953.aspx

Here is a free sample that you can download that implements a remote security management tool for the ASP.NET Membership/Roles system: http://peterkellner.net/archives/2006/01/09/24  The source is fully available, so you can take it and integrate it however you want into your site.

Hope this helps,

Scott

Okay let me address your points constructively...

1) Easier or not, securing a folder is not what I want.  I like to organize things by topic so placing the all code related to security in a single folder and allowing access to only some pages makes more sense to me than having multiple folders.  Also see point #2.

2) I have reviewed the SDK code in depth.  I looked at the specifc example entitled "Authorizing Access to a Page with Role Manager."  The exact description of what I'd like to accomplish.  Have a good look at the code if you would.  It secures a folder not a page...clearly a misleading example.  Otherwise the SDK has no example of securing a page that I can see.  The root web.config will not secure pages in a sub folder.  I tried it and also tried setting up a web.config file in the subfolder (which is also undesirable because I don't want to maintain multiple web.config files for each folder I want secured).

3) Yes, and I can and have done something similar in ASP.  I check a session token and redirect to a login page if they don't have access.  So what have I gained with ASP.NET if I have to use the same approach?  Nothing that I can see.

So I've still not found an easy way to secure access to singular pages.

Web.config files support the concept of <location> directives that allow you to scope settings to specific files (or folders).  So if you want to secure a specific file or set the authorization rules for just one URL, you can use a location directive like this to-do so:

<location path="securepage.aspx">

    <system.web>

           <authorization>

                 <allow roles="subscribers"/>

                 <deny users="*"/>

           </authorization>

    </system.web>

</location>

The above config applies only to the securepage.aspx file, and basically indicates that users within the "subscribers" role have access to it - and everyone not in that role is denied access.

Let me know if this makes sense and solves what you are trying to-do,

Scott

I believe you've missed the point entirely.  I have an admin tool built...now.  I spent weeks building it.  I had to figure out to use aspnet_sqlreg.exe to create the schema in my existing database because Visual Studio otherwise assumed that I would settle for using SQL Server Express.  It also decided what my application name would be in web.config, which I had to figure out how to change.  I had to figure out how to use and configure all of the login controls.  I had to take side trips to learn how to use the GridView and how to write skin files so the pages wouldn't be as  hideous as the ones in the SDK.

I examined the admin tool code in the framework folder and discovered that they're out of date (the code is still using DataGrids rather than the new GridViews).  I have also had the built-in admin tool mangle my web.config file half a dozen times.  I've read blogs, forums, and culled code from various sources including the SDK.  I've Installed and uninstalled four .NET forums as well as Dotnetnuke.  I bought two books that were both rip offs.  I've read junk for previous versions (i.e. Whidby, 2003, etc.) that no longer apply as well.  I've done plenty of  searching...the point is I shouldn't have to.

I learned a lot.  I have most of it done.  The irony?  I still can't secure pages in a subfolder after all these weeks of effort.  I haven't spent any time on the actual application code I'd rather have spent the time writing.  And, as with most programmers security is probably my least favorite topic.  You remember the Microsoft web adds with the guy going to the fridge late at night?  Well Visual Studio didn't save me any time and I'm still at it. 

The root web.config file will not accept this directive, however:

<location path="~\security\securepage.aspx">
    <system.web>
           <authorization>
                 <allow roles="subscribers"/>
                 <deny users="*"/>
           </authorization>
    </system.web>
</location>

Your example will only work if securepage.aspx file in in the root with the web.config file, right?  So it doesn't solve the problem.  I suspect that I'll have to add a page_load to every single page in my site that redirects if the user doesn't have the proper role for that page.  In ASP I would create a security include that does that and have the include at the top of every page.  I imagine I'll have to do something simlar.

I'm also trying to figure out how to hide menu items based on role too.  Have not found an example of that either.

You can absolutely specify a location directive to a file in a sub-directory.  Your syntax above is wrong, it should instead be:

<location path="security/securepage.aspx">
    <system.web>
           <authorization>
                 <allow roles="subscribers"/>
                 <deny users="*"/>
           </authorization>
    </system.web>
</location>

Note that you should use forward-slash instead of backslash, and no "~".

This article: http://aspnet.4guysfromrolla.com/demos/printPage.aspx?path=/articles/122805-1.aspx describes how to implement "security trimming" -- which allows you to show/hide nodes within a menu based on the security role of the user.

Hope this helps,

Scott

Thanks, Scott!!  I have it working for the subfolder at long last!  Okay the last feature I would like to implement is the ability to modify the page permissions remotely rather than having to sit in front of Visual Studio to edit the file.  Is that possible?

Thanks for the Rolla link.  I'll look it over and start a new topic if I have questions.

Thanks Again!
AWizardInDallas

ASP.NET 2.0 provides support for a managing and setting configuration settings using the System.Configuration namespace.  These quickstart tutorials discuss how to access and change values:

http://www.asp.net/QuickStart/aspnet/doc/management/default.aspx

You could use this to programmatically change settings.

Note that saving web.config files typically cause an application restart -- so that is one thing to be aware of if you are updating yourself (as long as your app doesn't store things in session state this should be fine).

Hope this helps,

Scott