Является ли это Django Middleware потокобезопасным?

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

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

Я планирую вставить часть SID= в URL, украсив django.core.urlresolvers.reverse и reverse_lazy моей собственной функцией, которая добавляет к ним ?sid=. Однако это вызывает некоторые проблемы, потому что оба промежуточных программного обеспечения 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 значение true и сохраняет необработанные urlresolvers.revers в отдельном методе. После рендеринга страницы process_response проверяет с помощью_decorator необходимость выполнения «сборки мусора». Если это так, он возвращает обратную функцию в исходное неукрашенное состояние.

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

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


django python-2.6 django-1.4
person Ralfp    schedule 26.05.2012    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

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

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

person Florian Apolloner    schedule 29.05.2012
comment
Моя проблема связана с онлайн-списками и онлайн-счетчиками. Когда вас посещает пользователь, который не использует куки, вы в конечном итоге заканчиваете тем, что онлайн-счетчик становится смехотворно большим, поскольку каждый запрос от него открывает новую сессию. Я думаю, что буду противостоять этому, отображая и подсчитывая только тех пользователей, у которых в поле сопоставления установлено значение true, следовательно, тех, кто сделал второй запрос, который успешно совпал с сеансом. - person Ralfp; 30.05.2012