0

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

При этом я успешно отделил логины; однако после входа в систему я могу проверить группы, к которым пользователь принадлежит, через настраиваемые подпрограммы роли, и я могу иметь одинаковые имена пользователей с разными паролями для обоих «приложений».

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

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

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

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

FormsAuthentication.SetAuthCookie(usr.UserName, false); 

Это печенье должно быть основано на маркере пользователя я подозреваю, а не UserName для того, чтобы разделить два провайдера? Это возможно?

ответ

0

Возможно, не ответ, который я бы предпочел, чтобы пойти с, но я был в состоянии разделить эти два, имея одно приложения использовать имя пользователя для Идентов печенья, а другие используй ProviderUserKey (справы) , Таким образом, auth cookie не будет распознаваться из одного «приложения» другому.

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

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

ex. Метод расширения:

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: Nope - asp.net использует имя пользователя auth cookie для разрешения ролей, указанных в файле web.config.

0

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

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

+0

Да, они разделены по названию приложения. Есть два поставщика ролей с разными именами приложений и два поставщика членства с разными именами приложений (конечно, совмещение роли с членством). – Dudeinco