Почему членство в asp.net UserID не хранится в билете аутентификации?

Я смотрел на привязку моей собственной таблицы пользователя к членству asp.net, сохраняя мой userid (int) в области UserData файла cookie аутентификации (Storing and accessing a legacy UserID in asp.net membership).Почему членство в asp.net UserID не хранится в билете аутентификации?

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

Если я конвертирую свою базу данных для использования guid (uniqueidentifier) UserIDs как внешние ключи во всех таблицах, связанных с моими пользователями, тогда мне все же нужен способ сделать UserID легко доступным для моего приложения. Принятый способ получить UserID, кажется, вот так:

Guid userID = (Guid)Membership.GetUser().ProviderUserKey;

Теперь, если я правильно понимаю, это включает в себя чтение из базы данных. Возможно, я придирчива, но, по-видимому, это немного лишнее по каждому запросу. Я был бы склонен поставить его в билет. Я не вижу никакой проблемы с помещением значения PK в билет (guid или int). Существует ли риск для безопасности? Членство, кажется, счастливо, используя UserName как ключ, а не суррогат. Что вызывает вопрос - почему они не поставили UserID в билет?

источник

2012-02-15 Fruitbat

Вы можете использовать пользовательский поставщик членства, который связывает ваши идентификаторы с идентификаторами GUID, например: http://stackoverflow.com/questions/6532418/how-to-combine-using-membership-api-with -own -соответствующие данные/6532611 # 6532611 –

@TimSchmelter - Это, по сути, то, что я делаю. Мне просто интересно, почему идентификатор пользователя с готовым членством не сохраняется в билете проверки подлинности. Они забыли или есть веская причина, чтобы не поместить его туда. – Fruitbat

Cookies и URL-адреса имеют практические максимальные длины - в FormsAuthenticationTicket.UserData документации говорится:.

"Вы должны ограничить количество данных, хранимых в свойстве UserData Вы должны убедиться, что размер имущества UserData делает не результат в недопустимом файле cookie или чрезмерно длинном URL. "

ASP.NET может быть настроен на использование cookieless forms authentication, в котором хранится билет аутентификации по URL-адресу. В этом случае фильтр ASP.NET ISAPI также должен выполнить немного дополнительной работы, чтобы удалить информацию о билете, а затем переписать URL-адрес.

Таким образом, часть причины, вероятно, может быть связана с компромиссом на сохранение минимальной длины файлов cookie/URL-адресов по умолчанию - сохранение зашифрованного сериализованного Guid в билете увеличило бы длину файла cookie/URL и также дополнительный лимит (предоставленный не очень) объемом данных, которые вы можете сохранить в UserData.

источник

2012-02-15 21:24:30 kuujinbo

Это кажется правдоподобным, по крайней мере. Конечно, если имя пользователя уникально, оно охватывает обе функции отображаемого имени и ключа базы данных. Хотя, насколько я вижу, уникальность имени пользователя не является ограничением базы данных, а проверкой в хранимой процедуре CreateUser. – Fruitbat

Да, непонятно, почему имя пользователя не является * табличным * ограничением. Я думаю, что поставщики членства были намеренно написаны, чтобы сбалансировать масштабируемость и гибкость. Возможности, вероятно, были исключены из API, потому что Microsoft ожидала, что разработчики при необходимости откажут своих собственных провайдеров.Не один, чтобы бросить похвалу MS ;-), но ИМХО они сделали довольно чертовски хорошую работу. На моей предыдущей работе я делал * настоящую * работу по разработке и в большой степени использовал 'UserId' (как вы собираетесь?). Вместо написания провайдера создавался статический вспомогательный класс с набором методов, среди прочего, кэшированных 'UserId'. – kuujinbo

Вы всегда можете написать свой собственный UserPrinciple, реализующий IPrinciple, который может дать вам идентификатор пользователя один раз, и это можно назвать в любом месте приложения без фактического попадания в базу данных. Тогда вы можете использовать userId в cookie, если хотите.

источник

2012-02-15 21:30:55 Bilal

Конечно, я могу, но думаю, вы упустили вопрос. – Fruitbat

Почему членство в asp.net UserID не хранится в билете аутентификации?

ответ

Смежные вопросы