Создайте Событие жизненного цикла , например, "login-pre-action" (или -post-), как в документированном шаблоне.В его реализации вы получаете доступ к LifecycleEvent, который инкапсулирует исходный HTTP-запрос / ответ.С этим вы можете выяснить, кто входит в систему и с какой конечной точки они подключаются.Проверьте это с вашими условиями и отправьте соответствующие перенаправления.
Редактировать: После вашего комментария, что это может быть серьезной проблемой производительности:
- Во-первых, я только считаю, что это серьезнаяпроблема производительности, когда вы измерили ее и предоставили цифры.
- Во-вторых, вместо того, чтобы использовать ключ компонента по умолчанию
login.events.pre, вы используете key=servlet.service.events.pre, возможно, вы захотите попробовать login.events.post. - В-третьих, вы можете случайно нажатьправильная реализация.Обратите внимание, что веб-вход может проходить через браузер: сеанс не привязан к определенному IP-адресу.После входа в систему из привилегированной сети администратор может легко перевести свой ноутбук в спящий режим, перенести его в Starbucks по соседству и снова открыть.Сеанс (если не истек тайм-аут) будет вполне допустимым, чтобы разрешить привилегированный доступ из Starbucks Wifi, если вы не проверяете каждый запрос.
Если вы действительно требовательны к своей производительности, вы можетехотите найти механизм без базы данных для хранения флага, что доступ уже проверен - например, сохранить утвержденный адрес браузера в сеансе.Ничего себе, я бы не догадался, что я бы публично предложил что-то хранить в сессии.
Но в целом: проблема производительности была бы измеримой.Чтение кода может очень редко выявлять проблемы с производительностью, или, по крайней мере, не те, над которыми стоит работать.