ShowUsYour<Blog>

Expanding upon my speculations: Membership, RoleProvider and ProfileAPI implementation

So, yesterday I jumped out on a limb and speculated how I thought that application architecture might include a wrapper around Membership and the Profile API in ASP.NET Whidbey.  Then the guy who created it chimed in with a comment to let me know that I'm wrong!  So either he's wrong or I am. 

     http://weblogs.asp.net/dneimke/archive/2005/01/31/363437.aspx

ScottGu is obviously a very smart guy who also knows this technology better than anybody.  So it must be me who's wrong, right?  Well no, not necessarily.  I think that the problem was that I didn't set up enough context about the problem that I was thinking of when I wrote that entry.

At lunchtime Mitch and I had an extended - and at times lively - exchange of ideas about this topic.  It took most of lunch before Mitch was able to get me to understand exactly what it was that I was talking about - gee it's good to have someone like Mitch to bounce ideas off of!  As we were chatting away over our lunches, Mitch had a small epiphany which I'd like to try and elaborate on here...

Regarding users and authentication there's 2 primary models and I'll use examples to demonstrate them:

Model #1 : Security User data is separate from application data

You are building the web application for the local telephony company.  The application has application data which revolves around "people".  These "people" are the people who have phone accounts. 

You also have people who can manage the data via a web application.  These users might be employees of the telephony and can view, edit, and create new records.  These users are "Security Users" because they must be known to the application before there authorization is determined.

Model #2 : Security User data is application data

You are building a community web application such as ProjectDistributor or .Text.  Users in this application manage their own data.  The security layer must ensure that the user who is altering a project or blog entry is the same user as the currently authenticated user.

So, that's the two primary user data models.  Now that I've taken some time to set up the context of the problem I plan on uploading some examples to the new ASP_Whidbey group that demonstrate how each model might work at an implementation level.

Speculating about Membership, RoleProvider and ProfileAPI implementation

There's an important area in ASP.NET Whidbey that I've started looking into that I haven't seen much coverage on, that is, how will the new user/security features be used when building a real application?

Membership, RoleProvider and ProfileAPI are the 3 that I'm talking about here.

Membership has some great features for managing users such as creating, retrieving, updating and deleting user  There's also a MembershipUser class which contains some of the instance data for users such as username, email, etc.

The ProfileAPI allows you to store additional arbitrary pieces of data against a MembershipUser.

So, from this you can see that there is a disjoint between all of the user information with some of it stored in the MembershipUser class and the remainder (aside from roles) stored in the Profile class.

Writing a wrapper around Membership, RoleProvider and ProfileAPI

In doing some speculative thinking over the weekend to try and envisage how these classes will get used, I imagined that you would need to create a "User" class to unify that data.  For example, I'd imagine that you wouldn't want to be passing System.Web.Membership.MembershipUser's out of your web services.

So, in-line with the starter kit architecture of today, I would imagine that some sort of User and UserBL classes may get written to unify access to User data.

class UserBL {

    public static bool ValidateUser(MyApplicationUser u) { return Membership.ValidateUser( ... ) }

    public static MyApplicationUser GetUser(string username) { 

        MembershipUser tmp = Membership.GetUser( ... )
        MyApplicationUser usr = new MyApplicationUser()

        // read in all values from MembershipUser
        usr.prop = tmp.prop

        // add values from Profile
        usr.prop = Profile.prop
        

        return usr
    }

    ... etc

}

ProjectDistributor release 1.0.2 now available

Code Camp Oz (1) just announced

Mitch has just announced the date and location of the first Australian Code Camp:

    http://notgartner.com/posts/1162.aspx

With Whidbey about to land into our in-trays this will be a wonderful opportunity to get together and discuss how we implement it.  Mitch and Greg Low have done a lot of the organizing for this and should have a final list of topics and speakers ready soon'ish.

If you are interested in attending as a speaker or a listener or both get in contact with Mitch via the above blog entry.

Cya there!

Remove dead projects from the VS home page

I just logged a feature request on the Feedback center about wanting to be able to remove unwanted projects from the "Recent Projects" list on the VS .NET home page.

If you want it... vote for it!

    http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=5e50f476-4653-4a89-8a78-31f3c10cf190

WebParts :: CustomVerbs

Just released my first prototype showing some WebPart code:

    http://projectdistributor.net/Projects/Project.aspx?projectId=65

• The extra verbs that are available for the Employee Details web part.
• If you change the current "view" on the Employee Details web part and then switch into edit mode and re-enable it, the current view is persisted.  That is, if you were in "Address" view when you hid it, you will still be in "Address" view when you re-add it
• When you are editing the "Employee Details" part, there are some custom properties that you can edit: "Name Header Title" and "Address Header Title".
• The Change View control which talks to the WebPartManager class to change the current display mode.

• complex parts which can talk via Connections.
• parts loaded at runtime.
• large parts - ie: near fullscreen parts.
• discovering parts which are dumped into a folder and discovered via metadata contained within either the assembly or a manifest.
• Still not sure how to put "spacers" into the Verbs collection.

About the Whidbey demo's thing...

Yesterday I blogged about a new group I've created to post small demo's and prototypes of ASP.NET Whidbey projects:

     http://weblogs.asp.net/dneimke/archive/2005/01/27/361426.aspx

I think that learning something such as ASP.NET Whidbey is a very incremental process.  You try something until you get it right and then as you look up you get to see exactly how much more stuff you don't understand. 

I'm presently working through a scenario like this with WebParts and the PortalFramework so, most of my little demo's will be related to what I'm learning there.  My end goal is to see whether those 2 things together can be used to build a rudimentary plug-in Framework.

While I'm learning that it will be good to get side-tracked by others who post their little snippets on other parts of the new technology: Custom Builders, Caching, Theming, Whacky Validation scenario's etc. and, in seeing their stuff it might just open a little gate for me to make a breakthrough in the stuff that I'm tackling.

So, if you have a folder named C:\WhidbeyTests\... and it's filling up with little tests I'm interested :-)

VS 2005 Beta 1 Expiry Date is...

July 1, 2005

... as per Dan Fernandez's blog: http://weblogs.asp.net/danielfe/archive/2005/01/27/361988.aspx

Current version of Visual Web Developer

I posted a question in the ASP.NET forums asking about what is the current build of Visual Web Developer:

    http://lab.msdn.microsoft.com/express/vwd/

Fredrik answered and said that he believes that the October CTP of Express is the latest version.  I'll try to find out when the next release of VWD will be and post it here.

Custom Build Providers

I came across this blog entry from Fritz Onion today about an experience that he had with Custom Build Providers:

    http://pluralsight.com/blogs/fritz/archive/2004/09/06/2188.aspx

It's a very interesting proposition and I really do wonder how things such as this will really get used into the future.  In Fritz's example he uses it to derive a strongly typed - and therefore intellisensed - experience at design time.  That's cool but, in that case it's really no different to any code-spitter tool.  It's just that the cost of parsing and code-gen has moved away from a separate code-gen tool into the IDE.  There's really no great gain though as you still need some tool to build the .dal tool (using the example case) and you still need to write code to emit code. 

Of couse, that's not to say that my jaw wouldn't have dropped too! ;-)