ASP.NET 3.5 несколько ролевых провайдеров

У меня есть приложение ASP.NET 3.5, которое я недавно расширил несколькими поставщиками членства и ролей, чтобы "прикрепить" второе приложение в этом приложении. У меня нет прямого доступа к конфигурации IIS, поэтому я не могу разбить его на отдельный каталог приложений.

Тем не менее, я успешно разделил логины; однако после входа в систему я могу проверить группы, к которым принадлежит пользователь, с помощью пользовательских подпрограмм ролей, и я могу иметь одинаковые имена пользователей с разными паролями для обоих "приложений".

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

Как я могу смягчить это? Если я ограничен одним приложением для работы с несколькими поставщиками ролей и членства, а в файле cookie для аутентификации хранится имя пользователя, которое может быть передано, могу ли я что-нибудь сделать?

Я понимаю, что ситуация не идеальна, но это наложенные ограничения на данный момент.

Пример аутентификации (после проверки):

FormsAuthentication.SetAuthCookie(usr.UserName, false);

Этот файл cookie должен основываться на подозрительном токене пользователя, а не на имени пользователя, чтобы разделить двух поставщиков? Это возможно?

Источник

2 ответа

Решение

Возможно, это не тот ответ, который я предпочел бы использовать, но я смог разделить их, когда одно приложение использовало имя пользователя для файла cookie аутентификации, а другое - ProviderUserKey (guid). Таким образом, cookie-файл аутентификации не будет распознан из одного "приложения" в другое.

FormsAuthentication.SetAuthCookie(user.ProviderUserKey.ToString(), false);

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

ех. Метод продления:

public static string GetUserName(this IPrincipal ip)
{
    return MNMember.MNMembership.GetUser(new Guid(ip.Identity.Name), false).UserName;
}

Если MNMember является статическим классом, MNMembership возвращает вторичного поставщика членства, а GetUser - стандартную функцию поставщиков членства.

var validRoles = new List<string>() { "MNExpired", "MNAdmins", "MNUsers" };
            var isValidRole = validRoles.Intersect(uroles).Any();
            if (isValidRole)
            {
                var userIsAdmin = uroles.Contains("MNAdmins");
                if (isAdmin && !userIsAdmin)
                {
                    Response.Redirect("/MNLogin.aspx");
                }
                else if (!userIsAdmin && !uroles.Contains("MNUsers"))
                {
                    Response.Redirect("/MNLogin.aspx");
                }...

Где isAdmin проверяет, отображается ли подкаталог в пути.

Кажется, хак, но, похоже, работает.

Изменить: Теперь, когда я не использую имя пользователя в качестве токена, я смогу вернуться к использованию web.config для безопасности каталогов, что означает, что хак главной страницы должен быть удален. (Теоретически?)

Изменить 2: Нет - asp.net использует файл cookie имени пользователя для разрешения ролей, указанных в файле web.config.

Источник

Вы пытались указать атрибут applicationName в строке подключения к членству?

https://msdn.microsoft.com/en-us/library/6e9y4s5t.aspx?f=255&MSPPError=-2147217396

Источник
Другие вопросы по тегам