Ramseur's Rainbow Portal 2.0 Blog

Ramseur,
I don’t really understand what you want to mean with “gave him the normal week time limit to show me something”, because I’m not ready to take commitment of a dead line right now. And what I told you about membership does not have anything to do with development release. I just felt it is somehow wrong, and that’s why (my opinion):
- First there are tables and procedures identical with standard MS membership schema, so in my case at least, I want to keep it in original form to be used with other application I use(On my provider I have rights to only one database). The current Rainbow membership has altered some of the standard stored procedures, so that I want to prevent.
-Second reason, was the architecture of the Rainbow provider. I take a look at it, and I discovered two things. First, it extend the standard membership with some profiles like attributes ( name; phone; company; address; zip; city; countryID; stateID; fax;
sendNewsletter;etc) and add change the standard use of ApplicationName,and userName with coresponded Guid on some of the methods.

Mgf architectural solution for dealing with dynamically setting the application name was placed only in the Role provider(but not also in the membership provider ??) this way: the application name is substituted with portal alias , and the application name is added as a parameter to every method of the provider and also to stored procedures.

Certainly, this is a technically viable option. There are problems with this approach though:
- Developers would have to explicitly manage the application name throughout their code, whereas in the standard provider the value gets set once and you can forget about it.
- from a testing perspective, the test cost of having another parameter inside of every provider and feature method is rather expensive.

I want to use custom provider for role and membership but only to override the default getter for application name.
ex:
public class RainbowProvider : SqlMembershipProvider
{
public override string ApplicationName
{
get
{
string appNameFromContext =
(string)HttpContext.Current.Items[“ApplicationName”];
if (appNameFromContext != “NOTSET”)
return appNameFromContext;
else
return base.ApplicationName;
}
}
}
And this combined with An HttpModule for determining the correct application name:

using System;
using System.Web;
public class PortalApplicationProcessor : IHttpModule
{
public void Dispose(){ return; }

private void DetermineApplicationName(Object sender, EventArgs e)
{
HttpApplication app = (HttpApplication)sender;
HttpContext context = app.Context;
string qAppName = app.Request.QueryString[“appname”];
if (!String.IsNullOrEmpty(qAppName))
context.Items[“ApplicationName”] = qAppName;
else
context.Items[“ApplicationName”] = “NOTSET”;
}

public void Init(HttpApplication app)
{
app.BeginRequest +=
new EventHandler(this.DetermineApplicationName);
}
}
This all works so transparently because internally SqlMembershipProvider always calls the public ApplicationName getter whenever the provider needs this value.

This approach is also safe from a concurrency perspective because the custom provider is depending on the HttpContext for the application name value. Because the context is local to each ASP.NET request, there is no chance that simultaneous page requests will tromp on each other’s application name. Even if two different page threads are simultaneously calling the ApplicationName getter, each thread will end up with a different value pulled from that thread’s associated  ttpContext.

And more have some benefits, like this:
I run a trace using current membership (mgf) for only one page with 4 modules on it, and I saw :
4 aspnet_membership_getUserByName
4 aspnet_UsersInRoles_IsUserInRole , which means this way we loose any caching mechanism of standard role provider.

Another thing to keep in mind though with data-store-specific keys is that after you start
designing provider-based features with a hard dependency on a specific key format, you have potentially limited your interoperability with other features, including features that no one has dreamed up yet. Although the combination of username and application name can be a bit awkward at times, it does it make it possible for completely random features to integrate at the level of the various provider-based object APIs.

In my mind I just want to put all extended properties found now in membership in profile, and extend the standard profile using  “inherits="Rainbow.Framework.Core.Provider.rbCurrUser" “ aproach, not to really make a custom profile provider.
But again, I’m not intend to prove anything, and I don’t want to make this the Rainbow way , I just want to see the diference in performace and for my own use (the advantage of an open source). As I told you I really apreciate what the mgf did , is great work and has inspired me. Also all his work on the Rainbow modules changing it to work on membership is well done and don’t intend to change anything. As you see, I realy need to keep the standard asp membership schema because of my provider, so I have to do it. And again you are right, the fact are mgf have done this and the rest of us just comment on it.

I'm very concerned about using anything other than the standard MS implementation of membership. If people want other functionality then make additional Stored Procs and tables like the CS people and others have done.

Rainbow must be 100% compatible to be successful and we get only disadvantages by trying to rework the MS implementations.

regards, Mark

Sticking with the standard aspnetdb stored procedures is very important when you consider our stated goal of being able to do Single-SignOn between apps.  Also, I thought we already agreed back in February about how to go about this (see my blog entry on using a custom provider).  

I'm also concerned that I have not been able to get any reply from MFG.  I've posted several issues with the current release in the Rainbow 2 dev forum and need to know what MFG's intentions were with regard to editing users, etc.  I'm willing to work with them on fixes if we can communicate, but am at a loss if I can't even get a simple reply.  It is great they did so much work, but I'm not sure if it will come to anything if we can't work as a team, which requires good communication on design and solutions.  

Not sure how to procede.  There are a lot of bugs in the current MFG version.  I would rather spend my time debuging a version using standard membership with custom provider as Jonathan and I laid out back in February.  

Filip, how close are you to having your version ready for testing?