Как удалять данные сеанса через регулярные промежутки времени, каждый час?

Комментарии

Поздравляем с использованием токенов для предотвращения повторной отправки (рефакторинг «Ввести синхронизирующий токен» из книги «Основные шаблоны J2EE»). :^)

Кварц ценен для сложного или точного планирования. Но ваши требования не нуждаются в Quartz. Может быть полезнее изучить CDI, java.util.Timer, ScheduledExecutor и/или таймеры EJB.

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

Будьте осторожны, если вы когда-либо сохраняете ссылки на HttpSession или передаете его в качестве параметра. Хранение ссылок предотвращает сборку мусора после завершения сеанса, что приводит к (большой?) утечке памяти. Попытки очистить ссылки с помощью HttpSessionListener и других приемов могут не сработать и привести к беспорядку. Передача HttpSession методам в качестве параметра делает их искусственно зависимыми от контейнера сервлетов и затрудняет модульное тестирование, поскольку вам приходится имитировать сложные объекты HttpSession. Все данные сеанса удобнее заключать в единый объект UserSessionState — хранить ссылки на this в переменных экземпляра сеанса и объекта. Это также известно как шаблон объекта контекста, т. е. хранить все ваши данные в одном или нескольких объектах контекста POJO, независимо от классов протокола HTTP.

Отвечать

Я предлагаю два альтернативных решения вашей проблемы:

1. Используйте java.util.Timer экземпляр singleton

   Вы можете заменить java.util.Timer (представленный в Java SE 1.3) на ScheduledExecutor (представленный в Java SE 5) для почти идентичного решения.

   Это доступно с JVM. Он не требует установки jar и настройки. Вы вызываете timerTask.schedule, передавая экземпляр TimerTask. Когда расписание подходит к концу, вызывается timerTask.run. Вы удаляете запланированные задачи через timerTask.cancel и timerTask.purge, которые освобождают используемую память.

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

   Я предлагаю вам создать два глобальных синглтона: экземпляр Timer и экземпляр TimerTask. В вашем пользовательском экземпляре TimerTask сохраните список всех пользовательских сеансов (в форме POJO, такой как UserSessionState или компонент Spring/CDI, а не в форме HttpSession). Добавьте в этот класс два метода: addSessionObject и removeSessionObject с параметром UserSessionState или подобным. В методе TimerTask.run выполните итерацию по набору UserSessionState и очистите данные.

   Создайте собственный HttpSessionListener — из sessionCreated поместите в сеанс новый экземпляр UserSessionState и вызовите TimerTask.addUserSession; из sessionDestroyed вызовите TimerTask.removeUserSession.

   Вызовите синглтон timer.schedule глобальной области действия, чтобы запланировать экземпляр TimerTask для очистки содержимого ссылки области сеанса.

2. Использовать список токенов с ограниченным размером (без очистки)

   Не очищайте токены по прошедшему времени. Вместо этого ограничьте размер списка (например, 25 токенов) и сохраните самые последние сгенерированные токены.

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

   if (++putIndex > maxSize) {
       putIndex = 0;
   }
   list.put(putIndex, newElement);
   

   Здесь не требуется планировщик, и нет необходимости формировать и поддерживать набор всех пользовательских сессий.

Я думаю, что это должно быть намного проще.

О реализации токена синхронизатора

1. Маркеры в шаблоне маркера синхронизатора НЕ предназначены для повторного использования. Токен считается действительным только для одной отправки. Ни больше ни меньше.

2. В любой момент времени вам нужно сохранять только один токен для сеанса.

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

4. При отправке все, что вам нужно сделать, это проверить, совпадают ли токен в форме и сеанс. Если это так, разрешите отправку формы и сбросьте значение токена в сеансе.

5. Теперь, если пользователь повторно отправляет ту же форму (со старым токеном), токены не будут совпадать, и вы можете обнаружить двойную отправку или устаревшую отправку.

6. С другой стороны, если пользователь перезагрузит саму форму, обновленный токен теперь будет присутствовать в скрытом элементе формы.

Вывод - нет необходимости сохранять список токенов для пользователя. Один токен на сеанс — это как раз то, что нужно. Этот шаблон широко используется в качестве меры безопасности для предотвращения атак CSRF. Где каждая ссылка на странице может быть вызвана только один раз. Даже это можно сделать с помощью всего одного токена за сеанс. Для справки вы можете увидеть, как работает CSRF Guard V3 https://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project#Source_Code

О сеансах

1. Объект сеанса имеет значение только до тех пор, пока поток выполнения каким-то образом привязан к паре http-запрос/ответ. Или проще говоря, пока пользователь просматривает ваш сайт.

2. Как только пользователь ушел, сеанс (из JVM) также исчезнет. Таким образом, вы не можете использовать таймер для его сброса.

3. Сеансы сериализуются серверами, чтобы убедиться, что они могут быть запущены, когда пользователь повторно посещает ваш сайт (jsessionid используется для идентификации того, какой сеанс должен быть десериализован для какого сеанса браузера).

4. Существует тайм-аут, связанный с сеансом, если тайм-аут истекает, сервер запускает новый сеанс, когда пользователь повторно посещает.

Вывод - нет веской причины периодически сбрасывать сеансы пользователей - и нет способа сделать это.

Дайте мне знать, если я что-то неправильно понял, и я надеюсь, что это поможет.

Моя идея будет примерно такой:

Краткая версия:

1. изменить интервал задачи на 1 минуту;
2. добавить метод unsetAllTokensIfNeeded к SessionTokenService, который будет вызываться каждую минуту, но будет просто очищать список токенов, если это действительно необходимо (в этом случае решение принимается на основе времени).

Подробная версия:

Ваша запланированная задача будет запускаться каждую минуту, вызывая метод unsetAllTokensIfNeeded, реализованный SessionToken. Реализация метода проверит, когда последний раз список токенов был чистым, и вызовет unsetAllTokens, если это было час назад.

Но для того, чтобы вызывать его в каждом отдельном сеансе с областью действия SessionTokenService, вам понадобится список существующих SessionTokenService, чего можно добиться, зарегистрировав его во время создания в службе, которая будет его очищать (здесь вы должны использовать WeakHashMap, чтобы избежать жестких ссылок, это позволит избежать сбора объектов сборщиком мусора).

Реализация будет примерно такой:

Токены сеанса:

Интерфейс:

public interface SessionTokenService extends Serializable {
    public boolean isTokenValid(String token);
    public String getLatestToken();
    public boolean unsetToken(String token);
    public void unsetAllTokens();
    public boolean unsetAllTokensIfNeeded();
}

Выполнение:

@Service
@Scope("session")
public final class SessionToken implements SessionTokenService, DisposableBean, InitializingBean {

    private List<String> tokens;
    private Date lastCleanup = new Date();

// EDIT {{{

    @Autowired
    private SessionTokenFlusherService flusherService;

    public void afterPropertiesSet() {
        flusherService.register(this);
    }

    public void destroy() {
        flusherService.unregister(this);
    }

// }}}

    private static String nextToken() {
        long seed = System.currentTimeMillis(); 
        Random r = new Random();
        r.setSeed(seed);
        return Long.toString(seed) + Long.toString(Math.abs(r.nextLong()));
    }

    @Override
    public boolean isTokenValid(String token) {        
        return tokens == null || tokens.isEmpty() ? false : tokens.contains(token);
    }

    @Override
    public String getLatestToken() {
        if(tokens==null) {
            tokens=new ArrayList<String>(0);
        }
        tokens.add(nextToken());            

        return tokens.isEmpty() ? "" : tokens.get(tokens.size()-1);
    }

    @Override
    public boolean unsetToken(String token) {                
        return !StringUtils.isNotBlank(token) || tokens==null || tokens.isEmpty() ? false : tokens.remove(token);
    }

    @Override
    public void unsetAllTokens() {
        if(tokens!=null&&!tokens.isEmpty()) {
            tokens.clear();
            lastCleanup = new Date();
        }
    }

    @Override
    public void unsetAllTokensIfNeeded() {
        if (lastCleanup.getTime() < new Date().getTime() - 3600000) {
           unsetAllTokens();
        }
    }

}

Сброс токена сеанса:

Интерфейс:

public interface SessionTokenFlusherService {
    public void register(SessionToken sessionToken);
    public void unregister(SessionToken sessionToken);
}

Выполнение:

@Service
public class DefaultSessionTokenFlusherService implements SessionTokenFlusherService {

    private Map<SessionToken,Object> sessionTokens = new WeakHashMap<SessionToken,Object>();

    public void register(SessionToken sessionToken) {
        sessionToken.put(sessionToken, new Object());
    }

    public void unregister(SessionToken sessionToken) {
        sessionToken.remove(sessionToken);
    }

    @Scheduled(fixedDelay=60000) // each minute
    public void execute() {
        for (Entry<SessionToken, Object> e : sessionToken.entrySet()) {
            e.getKey().unsetAllTokensIfNeeded();
        }
    }

}

В этом случае вы должны использовать функцию задачи, управляемой аннотациями, из Spring:

<task:annotation-driven executor="taskExecutor" scheduler="taskScheduler"/>
<task:scheduler id="taskScheduler" pool-size="10"/>

С моей точки зрения, это было бы простым и хорошим решением.

ИЗМЕНИТЬ

При таком подходе вы более или менее регистрируете SessionToken в Flusher, когда spring завершает конфигурацию bean-компонента, и удаляете его, когда spring уничтожает bean-компонент, это делается при завершении сеанса.

Я мало что знаю о Quartz. Но, видя ваше исключение, я могу предположить, что планирование является частью асинхронной связи. Поэтому для достижения этой цели используются многопоточность и модель, управляемая событиями. Итак, в вашем случае вы пытаетесь создать bean-компонент preventDuplicateSubmissionService . Контейнер создает bean-компонент как часть объекта. Но когда вы обращаетесь к нему, поток, созданный Quartz как часть асинхронного планирования, пытается получить услугу. Но , для этого потока bean-компонент не создается. Может быть, вы используете scope = "request">. Итак, когда областью является запрос для каждого HTTP-запроса, создается его объект. В вашем случае, когда вы пытаетесь получить доступ к bean-компоненту, тогда bean-компонент с запросом область не создается, потому что доступ к bean-компоненту осуществляется в режиме, отличном от http, поэтому, когда поток пытается получить доступ к службе, возникает исключение. Я также перешел от той же проблемы, когда пытался получить доступ к bean-компоненту, используя многопоточность в serviceImpl.in в моем случае bean-компонент для области запроса не был создан, потому что он создается для каждого режима HTTP-запроса. Я реализовал решение, данное здесь, и оно работает для меня. Доступ к прокси-компонентам с ограниченной областью действия в потоках

Кажется, периодическое задание по удалению токенов, которое вы настроили, не запускалось в контексте определенного пользовательского сеанса или всех пользовательских сеансов.

Я не уверен, есть ли какой-либо механизм для сканирования всех активных сеансов и их изменения, однако альтернатива, которую я предлагаю, такова:

Сохраните пару уникальных токенов с отметкой времени на стороне сервера. Отправляйте токен пользователю (но не метку времени) только при представлении формы. Когда форма отправлена, найдите, когда этот токен сгенерирован - если он истек, отклоните его.

Таким образом, вам даже не нужен таймер, чтобы удалить все токены. Использование таймера также удалит вновь созданный токен.

В исходном методе Question (который работал правильно в соответствии с расписанием) используйте приведенный ниже код...

package quartz;

import org.quartz.JobExecutionContext;
import org.quartz.JobExecutionException;
import org.springframework.scheduling.quartz.QuartzJobBean;

public final class RemoveTokens extends QuartzJobBean implements javax.sevlet.http.HttpSessionListener {

    static java.util.Map<String, HttpSession> httpSessionMap = new HashMap<String, HttpSession>();

    void sessionCreated(HttpSessionEvent se) {
        HttpSession ss = se.getSession();
        httpSessionMap.put(ss.getId(), ss);
    }

    void sessionDestroyed(HttpSessionEvent se) {
        HttpSession ss = se.getSession();
        httpSessionMap.remove(ss.getId());
    }

    @Override
    protected void executeInternal(JobExecutionContext context) throws JobExecutionException {
        Set<String> keys = httpSessionMap.keySet();

        for (String key : keys) {
            HttpSession ss = httpSessionMap.get(key);
            Long date = (Long) ss.getAttribute("time");

            if (date == null) {
                date = ss.getCreationTime();
            }

            long curenttime = System.currentTimeMillis();
            long difference = curenttime - date;

            if (difference > (60 * 60 * 1000)) {
                /*Greater than 1 hour*/
                List l = ss.getAttribute("YourList");
                l.removeAll(l);
                ss.setAttribute("time", curenttime);
            }
        }
    }
}