Когда вы говорите, что у вас будет «user_id для доступа к сеансу», это звучит так, как будто вы действительно говорите об идентификаторе сеанса, а не об идентификаторе пользователя. По сути, это cookie, который вы устанавливаете при успешном входе в систему, и сервер использует cookie для поиска нужного сеанса.
Осторожно: перехват сеанса. Использование идентификатора сеанса - довольно стандартная схема (хотя обычно она называется идентификатором сеанса, а не идентификатором пользователя), но она действительно зависит от того, как она реализована. В общем, вы хотите, чтобы сервер приложений обрабатывал это для вас автоматически, а не для того, чтобы кодировать его самостоятельно, потому что есть более и менее безопасные способы сделать это. Например, если идентификаторы сессии являются предположимыми, то ваше приложение уязвимо для так называемого перехвата сеанса . Очевидно, вы не хотите, чтобы идентификаторы были последовательностью, но это еще не все. Вы хотите, чтобы они были случайными, вы хотите, чтобы они не имели шаблонов (не всегда легко увидеть - но есть инструменты для определения наличия шаблонов), вы хотите, чтобы при генерации идентификатора сеанса было достаточно много битов в игре. и т. д. Обычно это то, что разработчики приложений делегируют вспомогательной инфраструктуре.
Осторожно: фиксация сеанса. Еще один риск - фиксация сеанса . Существуют различные варианты, но основная концепция заключается в том, что злоумышленник обманом заставляет кого-то щелкнуть ссылку с известным идентификатором сеанса (что можно сделать, когда идентификатор сеанса передается в URL-адресе вместо использования файла cookie). Например, он может опубликовать ссылку на общедоступном форуме, после чего жертва щелкает по ней и затем аутентифицирует сеанс. Теперь злоумышленник может принять сеанс, и он аутентифицирован для загрузки. Одной из мер противодействия является обеспечение того, чтобы приложение генерировало новый идентификатор сеанса при получении нераспознанного идентификатора сеанса от клиента, а не просто приняло нераспознанный идентификатор сеанса и начало нового сеанса с ним. Если вы используете стандартный механизм для генерации идентификаторов сеансов, то есть хороший шанс (хотя и нет гарантии - посмотрите вашу документацию), что он уже предоставляет эту контрмеру, как минимум, в качестве опции конфигурации. Если вы напишите свое, то это будет то, что неопытный человек почти наверняка пропустит.
Идентификация сессии и идентификаторы пользователей приводят к перехвату сессии. Еще одна вещь. Если вы используете один идентификатор для выполнения двойной обязанности в качестве идентификатора сеанса и идентификатора пользователя - не делайте этого. Во-первых, сеансы и пользователи являются концептуально разными вещами (сеанс имеет ассоциированного пользователя, но это не то же самое, что пользователь), поэтому с точки зрения чистого моделирования это не правильно. Но что более важно, идентификаторы пользователей обычно не являются секретом, и они обнаруживаются в таких вещах, как URL (которые могут видеть пользователи). Идентификаторы сеанса, с другой стороны, являются определенно секретными. Так, например, если каждый раз, когда я захожу в ваше приложение, вы отправляете мне файл cookie с надписью «user_id = 14», тогда все, что нужно сделать, это пойти посмотреть на ваше приложение, заметить, что я пользователь 14, а затем периодически пытаться пройти cookie "user_id = 14" для вашего приложения. Рано или поздно они сделают это в то же время, когда я на самом деле вошел в систему, и вуаля, сессионный угон.