Членство в ASP.NET с использованием созданного UserId в строке запроса - PullRequest
0 голосов
/ 09 февраля 2011

Привет. В настоящее время я изучаю .net и создаю свой первый настоящий веб-сайт с использованием .net.

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

Ответы [ 3 ]

1 голос
/ 09 февраля 2011

Зачем вам это нужно в строке запроса?Это обеспечивается ...

If HttpContext.Current.User.Identity.IsAuthenticated Then
    Dim user As MembershipUser = Membership.GetUser()
    Dim guid as Guid= DirectCast(user.ProviderUserKey, Guid)
End If

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

Если вы хотите сохранить идентификатор пользователя как чужой ключ, можно использовать уникальный идентификатор, предоставляемый MembershipProvider.

Если вы хотите использовать вместо этого целое число (удобочитаемость, меньше места на диске), вам нужно создать таблицу (aspnet_UserID), которая отображает guid на ваш int-ID в отношении один-к-одному,Создайте также триггер для вставок и удалений в таблице aspnet_Users, например:

CREATE TRIGGER [dbo].[trgCreateUserID] ON [dbo].[aspnet_Users]
FOR INSERT
AS

INSERT INTO dbo.aspnet_UserId(fiUser)
    SELECT UserID FROM inserted

и

CREATE TRIGGER [dbo].[trDeleteUserID] ON [dbo].[aspnet_Users]
FOR DELETE
AS

DELETE FROM dbo.aspnet_UserId 
    WHERE fiUser IN(SELECT UserID FROM DELETED)
0 голосов
/ 09 февраля 2011

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

http://en.wikipedia.org/wiki/Security_through_obscurity

Но тогда ЕСЛИ у вас есть правильно защищенное приложениеИдентификаторы должны быть в порядке.

Вероятно, вы все равно должны хранить UserId в сеансе, чтобы он не передавался в браузер.

0 голосов
/ 09 февраля 2011

, безусловно, хорошо связывать пользовательские данные с FK, в зависимости от дизайна вашей базы данных.

в общем случае я бы не помещал идентификатор пользователя в строку запроса, если это действительно не требуется, если вы включили и правильно поддерживаете аутентификацию пользователя, информация о подключенном в данный момент пользователе доступна в классах User.Identity и Principal.

...