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

Question

Я пытался связать свою собственную таблицу User с членством asp.net, сохранив свой идентификатор пользователя (int) в области UserData куки-файла аутентификации ( Хранение и доступ к устаревшему UserID в членстве asp.net ).

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

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

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

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

Answer 1

Файлы cookie и URL-адреса имеют максимальную практическую длину - в документации FormsAuthenticationTicket.UserData указано:

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

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

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

Answer 2

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