О чем думает сервер, если клиент меняет IP во время активного сеанса?

Question

[Mellowtoy]

Хотелось бы узнать у знающих как с точки зрения сервера (Linux) выглядит смена IP адреса клиента во время активного сеанса?

Узнать хочется то, что будет в логах и каково будет поведение сервера в таком случае. К примеру, я залогинился на Тостере, сижу и печатаю сейчас это сообщение, и в этот момент у меня меняется IP адрес. Будет ли вообще об этом знать сервер ДО перезагрузки страницы? Спасибо.

Comments

[DevMan]

Mellowtoy и при чем тут php?

[Mellowtoy]

DevMan: попало случайно, убрал

[Дмитрий Беляев]

Mellowtoy: не считаю полноценным ответом, поэтому напишу здесь
У меня в одном из проектов требовалась привязка сессии к ip, сделали так:
При авторизации поднимается websocket соединение и авторизуется, в случае дисконнекта (если ip меняется - 100% дисконнект будет) автоматически переподключаем клиента и снова авторизуем
Как итог - никаких токенов в принципе, сессия живет ровно столько, сколько открыт коннект

Answer 1

[DevMan]

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

Comments

[Mellowtoy]

"естественно, сервер не будет никак об этом знать до нового запроса."

А есть ли возможность узнать о смене адреса без перезагрузки страницы? Если сайт на Ajax, к примеру?

[DevMan]

Mellowtoy: так чекайте адрес при каждом ajax-запросе и будете знать.
как вариант - периодически проверять адрес на клиенте, и если он сменился, слать запрос к себе на сервер.

но, откровенно говоря, я слабо представляю какое это имеет практическое значение.

Answer 2

[xmoonlight]

Обычно не привязывают сессию к IP-шнику, но если необходима повышенная безопасность - можно привязать IP адрес к сессии и разлогинить пользователя, если у текущей сессии вдруг сменился IP.
Но если так делают, то обычно перелогинивают в прозрачном режиме незаметно для пользователя: создаётся новая сессия на основе старого токена и генерируется (выписывается) новый для новой сессии (и привязывается к ней), иначе - пользователю необходимо пройти авторизацию заново в ручном режиме.
Это может быть применимо для того, чтобы не могли воспользоваться перехваченными данными сессии (например, вход с тем же токеном) с другого IP-адреса.