Разве это Django Middleware Thread-safe?

Question

Я пишу приложение для форума на Django, используя пользовательскую сессию/auth/users/acl system. Одной из целей является то, что пользователи могут просматривать и использовать мое приложение, даже если у них есть файлы cookie. Исходя из мира PHP, лучшим решением проблемы является добавление sid = к каждой ссылке на странице. Вот как я планирую это сделать:

Сессия промежуточного программного обеспечения проверяет, имеет ли пользователь cookie сеанса или помнит меня. Если он это сделает, это, скорее всего, означает, что куки работают для него. Если он этого не делает, мы генерируем новый идентификатор сеанса, открываем новый сеанс (создаем новую запись в таблице сеансов в БД), затем отправляем cookie и перенаправляем пользователя туда, где он есть, но с SID, добавленным к url. После перенаправления промежуточного программного обеспечения будет видно, можно ли получить идентификатор сеанса из файла cookie или GET. Если его cookie, мы перестаем добавлять sid к URL-адресам. Если его ПОЛУЧИТЬ, мы сохраняем их.

Я планирую вставить SID = часть в url, украсив django.core.urlresolvers.reverse и reverse_lazy с моей собственной функцией, которая добавляет к ним sid =. Однако это вызывает некоторые проблемы, потому что и middlewares urlresolvers, и не являются потокобезопасными. Для преодоления этого я создал что-то вроде этого:

class SessionMiddleware(object): 
    using_decorator = False 
    original_reverse = None 

    def process_request(self, request):   
     self.using_decorator = True 
     self.original_reverse = urlresolvers.reverse 
     urlresolvers.reverse = session_url_decorator(urlresolvers.reverse, 's87add8ash7d6asdgas7dasdfsadas') 

    def process_response(self, request, response): 
     # Turn off decorator if we are using it 
     if self.using_decorator: 
      urlresolvers.reverse = self.original_reverse 
      self.using_decorator = False 
     return response 

Если SID должен быть принят через ссылку, process_request устанавливает using_decorator истинного и хранит недекорированный urlresolvers.revers в отдельном методе. После того, как страница отображается, process_response проверяет using_decorator, чтобы увидеть, нужно ли выполнять «сбор мусора». Если это так, он возвращает обратную функцию в исходное состояние без декодирования.

Мой вопрос в том, является ли этот подход потокобезопасным? Или увеличение трафика на моем форуме может привести к тому, что промежуточное ПО украсит эти функции снова и снова и снова, не выполняя «сборку мусора»? Я также настоятельно рекомендую использовать регулярное выражение для простого снятия HTML-ответа для ссылок и предоставления фильтров шаблонов и переменных для ручного добавления SID в места, которые не указаны регулярным выражением.

Какой подход лучше? Также является ли текущий поток безопасным?

Answer 1

Прежде всего: использование SID в URL-адресе довольно опасно, например, если вы скопируете &, вставьте ссылку для друга, в которой он зашел, как вы. Поскольку большинство пользователей не знают, что такое SID, они столкнутся с этой проблемой. Таким образом, вы никогда не должны использовать SID в URL-адресе, а так как Facebook и друзья все требуют куки, вы тоже должны быть в порядке ...

С учетом этого, monkeypatching urlresolvers.reverse к счастью не работает! Возможно, это будет выполняться с помощью пользовательского подкласса URLResolvers, но я рекомендую против него.

И да, ваше промежуточное ПО не является потоковым. Middlewares инициализируются только один раз и разделяются между потоками, а это означает, что хранение чего-либо на себе является не threadsafe.