Я работаю над веб-приложением с Java EE 6 (JSF CDI EJB), которое не должно разрешать одновременный вход в систему (один и тот же пользователь и пароль).
Что мне нравится:
Если пользователь дважды входит в систему, первый сеанс должен быть признан недействительным, а данные старого сеанса (включая все компоненты CDI с SessionScope или другими областями, такими как WindowScope из Apache CODI) переносятся в новый сеанс.
Это что-то вроде подхода к захвату разыскиваемой сессии :-)
Вы можете использовать bean-компонент без сохранения состояния для пользователя, поэтому каждый раз, когда нужно пытаться войти в систему/повторно войти в систему, текущий сеанс становится недействительным (в начале процедуры входа в систему)
рассмотреть такой подход:
try {
session = request.getSession(); //the request is passed by another page or action
if(session.getAttribute("user") != null) {
//your code to forward or handle the existing user (re-log in/ do nothing etc.)
}
Я решил эту проблему с помощью фильтра
открытый класс SessionReplicationFilter реализует фильтр {
@Inject
SessionReplicationManager manager;
public SessionReplicationFilter() {
}
@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException, ServletException {
//Process chain first
if (chain != null) {
chain.doFilter(request, response);
}
//check http request
if (request instanceof HttpServletRequest) {
HttpServletRequest httpRequest = (HttpServletRequest) request;
// Retrieve the session and the principal (authenticated user)
// The principal name is actually the username
HttpSession session = httpRequest.getSession();
Principal principal = httpRequest.getUserPrincipal();
if (principal != null && principal.getName() != null && session != null) {
manager.checkExistingSession(principal.getName(), session))
}
}
}
@Override
public void init(FilterConfig filterConfig) throws ServletException {
}
@Override
public void destroy() {
}
}
Менеджер смотрит вслед
Открытый класс @ApplicationScoped SessionReplicationManager {
private Map<String, HttpSession> map = new ConcurrentHashMap<String, HttpSession>();
public boolean checkExistingSession(String user, HttpSession session) {
if (map.keySet().contains(user)) {
if (!session.getId().equals(map.get(user).getId())) {
System.out.println("User already logged in ");
HttpSession oldSession = map.get(user);
// copies all attributes from the old session to the new session (replicate the session)
Enumeration<String> enumeration = oldSession.getAttributeNames();
while (enumeration.hasMoreElements()) {
String name = enumeration.nextElement();
System.out.println("Chaning attribut " + name);
session.setAttribute(name, oldSession.getAttribute(name));
}
// invalidates the old user session (this keeps one session per user)
oldSession.invalidate();
map.put(user, session);
return true;
}
} else {
System.out.println("Putting "+user+" into session cache");
map.put(user, session);
return false;
}
return false;
}
}
Он очень хорошо работает с аннотированными компонентами CoDI ViewScoped.
Если первый пользователь становится недействительным, каждый запрос (AJAX) вызывает исключение с истекшим сроком действия сеанса, которое можно легко обработать даже с помощью кнопки восстановления сеанса.
Единственная незначительная проблема с bean-компонентами с областью просмотра заключается в том, что они получают новый идентификатор представления. Поменяв их на исходные, все работает нормально.
Вещи, которые мне нужно добавить:
В этом комментарии не хватает:
С уважением
В Java EE 6 нет встроенного механизма для этого.
Поскольку я не могу себе представить, что вы хотите перенести что-то вроде текущего варианта использования (например, открытый процесс оформления заказа) из одного сеанса в другой, я предлагаю вам просто отследить состояние графического интерфейса пользователя.
URL-адреса RESTful звучат как идеальный подход для этого. Сохраните последний пользовательский URL/действие пользователя (например, www.myapp.com/orders/new/12) и повторно откройте его при новом входе в систему.
Если вы не хотите сохранять это в БД, идентификатор пользователя / URL-адрес карты в области приложения может быть способом KISS.
