Provider uglyness

morten.sorby@capgemini.com

Vote:

Hi All

This is a sort of FYI post :-)

Thought I'd share what we've found with regards to implementing our own membership provinder. Actually it's Johan Olofssons modified ActiveDirectoryMembershipProvider.
It basically only overrides the GetUser, and normalizes the user name, so we were a little bit surprised when the useres came and said they could not search for spesific users in admin mode. Fetch all users went fine, but not filtered by name or e-mail.
This was odd since the findbyemail and username functions had not been overrided.
After looking around for a bit we found the culprit.

EPiServer.Security.ProviderCapabilities, and in the constructor:

static ProviderCapabilities()
{
    _providerDictionary = new Dictionary<Type, ProviderCapabilitySettings>();
    AddProvider(typeof(SqlMembershipProvider), new ProviderCapabilitySettings(Action.Delete | Action.Create | Action.Update, new string[] { "email", "comment" }));
    AddProvider(typeof(WindowsMembershipProvider), new ProviderCapabilitySettings(0, new string[0]));
    ProviderCapabilitySettings settings = new ProviderCapabilitySettings(0, new string[0]);
    settings.WildcardSymbol = "*";
    AddProvider(typeof(ActiveDirectoryMembershipProvider), settings);
    AddProvider(typeof(SqlRoleProvider), new ProviderCapabilitySettings(Action.Delete | Action.Create | Action.Update, new string[0]));
    AddProvider(typeof(WindowsRoleProvider), new ProviderCapabilitySettings(0, new string[0]));
    ProviderCapabilitySettings settings2 = new ProviderCapabilitySettings(0, new string[0]);
    settings2.WildcardSymbol = "*";
    AddProvider(typeof(ActiveDirectoryRoleProvider), settings2);
}

Here it adds * as wildcard for typeof(ActiveDirectoryMembershipProvider), but since our provider is of another type not setup here we get a % as wildcard from the searchuser.aspx in admin...
This sort of setting up is, in my opinion bad when we are dealing with providers, it takes away the agnostic of the provider model.
Had EPiServer at least used "is" instead of typeof to determine the type, inherited classes would have resolved.

So to make things messier we added our own settings in the application_start event :-(

Regads,
Morten

#34967

Nov 23, 2009 12:57

Vote:

You can (should) call ProviderCapabilities.AddProvider() explicitly in your provider's Initalize()-implementation to
specify both what actions are supported and what symbol should be used for wildcardsearches.

/johan

#34969

Nov 23, 2009 13:10

morten.sorby@capgemini.com

Vote:

Thank you :-)

//Morten

#34970

Nov 23, 2009 13:12

morten.sorby@capgemini.com

Vote:

Coseptually I'm not one 100% comfortable with the way this is implemented, since one has has to write code to add a new provider. One can not take an out of the box provider and just make search work with episerver. Unless you are luck and the underlying datastructure happens to use % as a wirldcard.
And to make things worse, EPiServer does not use the ProviderCapabilities where they should, have a look at at EPiServer.UI.Edit.MembershipBrowser, it's used by the /edit/MembershipBrowser:
private List<MembershipUser> SearchUsersAndEmail(string name, string email)
    {
        MembershipUserCollection users = Membership.FindUsersByName("%" + name + "%");
        MembershipUserCollection users2 = Membership.FindUsersByEmail("%" + email + "%");
        List<MembershipUser> list = new List<MembershipUser>();

Here % is hardcoded, so no AD provider will return a hit.

Regards,
Morten

#35011

Nov 24, 2009 10:20

Vote:

Agreed, it would indeed be nice if ProviderCapabilities were configurable through web.config.

As for the hardcoded wildcards I'd say: "Shame on us!"
I've reported to the frontend team.

Thanks for bringing it to our notice!

Best regards,
johan

#35012

Nov 24, 2009 10:31