Программное добавление поставщика членства

Question

У меня есть приложение .Net, которое использует произвольное количество провайдеров членства. Я не буду вдаваться в причины, но я не хочу, чтобы они были предварительно настроены, но я хочу создавать и добавлять их программно. Есть какой-либо способ сделать это? У меня нет проблем с созданием провайдеров, но Membership.Providers только для чтения, поэтому я не могу их добавить.

Answer 1

Поздний, поздний ответ, но вы можете использовать рефлексию:

public static class ProviderUtil
{
    static private FieldInfo providerCollectionReadOnlyField;

    static ProviderUtil()
    {
        Type t = typeof(ProviderCollection);
        providerCollectionReadOnlyField = t.GetField("_ReadOnly", BindingFlags.Instance | BindingFlags.NonPublic);
    }

    static public void AddTo(this ProviderBase provider, ProviderCollection pc)
    {
        bool prevValue = (bool)providerCollectionReadOnlyField.GetValue(pc);
        if (prevValue)
            providerCollectionReadOnlyField.SetValue(pc, false);

        pc.Add(provider);

        if (prevValue)
            providerCollectionReadOnlyField.SetValue(pc, true);
    }
}

Затем в своем коде вы можете сделать что-то вроде этого:

MyMembershipProvider provider = new MyMembershipProvider();
NameValueCollection config = new NameValueCollection();
// Configure your provider here.  For example,
config["username"] = "myUsername";
config["password"] = "myPassword";
provider.Initialize("MyProvider", config); 

// Add your provider to the membership provider list
provider.AddTo(Membership.Providers);

Это хак, потому что мы используем отражение, чтобы установить приватное поле "_ReadOnly", но, похоже, оно работает.

Вот отличный пост об этой проблеме: http://elegantcode.com/2008/04/17/testing-a-membership-provider/

Еще один хороший пост: http://www.endswithsaurus.com/2010/03/inserting-membershipprovider-into.html

Обратите особое внимание на предупреждения об использовании _ReadOnly в этих сообщениях, так как вы захотите взвесить недостатки манипулирования коллекцией только для чтения с требованиями вашего проекта и тем, чего вы пытаетесь достичь.

С уважением,

-Doug

Answer 2

Простой способ взломать - сначала создать пользовательского поставщика членства (в качестве оболочки) и подключить его к web.config. Затем вы реализуете этот провайдер, чтобы иметь возможность аутентифицировать пользователей по списку реальных провайдеров членства.

Поскольку упаковщик принадлежит вам, вы ограничены только своим воображением.

Answer 3

Я знаю, что это уже не имеет значения, но для будущих читателей я добавлю свое решение для аналогичной проблемы.

Я хотел создать провайдера, который бы добавлял некоторые функции к любому другому провайдеру (шаблон декоратора), поэтому я хотел добавить внутреннего провайдера в коллекцию провайдеров (для вышеупомянутого - он не будет работать, потому что если провайдер отсутствует в коллекции провайдеров, он не сможет создавать пользователей).

Мне не понравилось решение для отражения по двум причинам:

Очевидный - он нарушает инкапсуляцию.

Второй - код должен выполняться без разрешений на отражение, в противном случае любой фрагмент кода сможет добавить своего поставщика - так что любая безопасность будет скомпрометирована.

(простое) решение, которое я нашел, состояло в том, чтобы зарегистрировать обоих поставщиков в web.config, установить поставщика по умолчанию для моего поставщика и загрузить второго поставщика во время выполнения из коллекции поставщиков.

По первому вопросу - если вы знаете, какие поставщики вам понадобятся до выполнения, лучше зарегистрировать их в web.config и, возможно, изменить их свойства во время выполнения.

Другое решение (которое все еще было бы «правильным», но медленным) состояло бы в том, чтобы делегировать проверку безопасности небольшому exe-файлу, изменить его app.config, запустить его и вернуть результат в качестве вывода (ваш провайдер может сделать этот). DPAPI может обеспечить безопасность для доставки пароля.