C # хранение информации

Question

Привет,

Я работаю над серверной программой на C #, но столкнулся с проблемой.Когда пользователь подключается, его учетная запись проходит проверку подлинности и т. Д. Все в порядке.

Но проблема в том, что серверу придется выполнять множество запросов и функций с именем пользователя, паролем и т. Д. В качестве параметра подключенного пользователя.,Это не было бы проблемой, если бы у меня был только 1 клиент, но многопоточность и множественные соединения делают это сложной задачей.

В настоящее время у меня есть несколько функций, которые я должен вызывать так: (в основном из соображений безопасности)

functionName(action, value, username, password)

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

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

Спасибо за ваше время.

Что я сейчас делаю:

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

Это делает код выглядящим излишним и избыточным.

Редактировать:

В данный момент пользователь войдет в систему, используя свой пароль и имя пользователя.Затем я шифрую информацию и отправляю ее в виде пакета.

Сервер расшифровывает информацию и проверяет имя пользователя и пароль в базе данных.

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

Теперь, как мне (на стороне сервера) проверить, еслиGUID в пакете от клиента является законной на стороне сервера?- я просто временно храню GUID в базе данных?

Answer 1

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

Answer 2

Вы можете подумать о создании метода аутентификации, который возвращает безопасный токен, возможно, GUID

Guid Authenticate(username, password)

и передать это в методах вместо username.password

functionname(action, value, securityToken)

Answer 3

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

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

dsklfgjkgjdlg, у вас есть хеш-строка секретного токена, скажем "craemefraice", вы хешируете токен с помощью своей секретной строки и добавляете его в свой токен, чтобы он мог быть dsklfgjkgjdlg: [thehash]

когда вы хотите проверить токен, вы просто разделяете строку на:, хешируете ее со своей секретной строкой и проверяете, соответствует ли она токену. Если нет, то это недействительно, если это вы проверяете учетные данные в базе данных

Answer 4

Если я правильно понимаю, вы могли бы создать какой-то класс и создать его сначала с параметрами username, password, тогда у него будет только метод functionName (action, value) только с 2 аргументами, вы будете вызывать его так же, как сейчас -6 раз в одной строке (??) и внутри нее будет вызываться фактическое functionName с 4 параметрами, добавляя эти 2 параметра из своих полей.

как SecureFunctionCaller sfc = SecureFunctionCaller (имя пользователя, пароль); sfc.functionName (действие, значение).

Возможно, вам придется скопировать все эти функции в этот класс, так что это зависит от числа. Также вы можете создать объект User с именем пользователя и паролем и использовать 3 параметра функций вместо 4 параметров, если это будет лучше.

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

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