Можно ли, не изобретая велосипед, передать этому декоратору функцию(с параметром request), которую нужно выполнить перед редиректом на логин?

Внешний декоратор над этим декоратором?

Lolka
Внешний декоратор над этим декоратором?

Функция должна выполняться в случае если пользователь не залогинен или превышено время обновления сессии, после определения этого факта и перед переадресацией. Проверкой и переадресацией занимается login_required. Как это сделать внешним декоратором?

Навесьте на /accounts/login/ свой view и там зовите чего заблагорассудится. После вызова отредиректьте на нормальный логин.

Вообще это нужно для обновления списка онлайн-пользователей, желательно без обращения к базе. Сейчас я это пытаюсь сделать через словарь USERS=user. При логине пользователя вызываю функцию и там заношу его в словарь. Но перед этим нужно пробежаться по словарю и проверить залогиненность внесённых пользователей(Как это правильно сделать пока не знаю), у кого превышено время обновления сессии удалить из словаря. Т.е. при каждом логине очередного пользователя весь словарь проверяется заново. Список активных онлайн-пользователей должен выводится в некоторых местах сайта. Если есть идеи как эту задачу правильнее решить буду благодарен.

И где этот словарь хранится? Вообще несколько странно выглядит нежелание юзать базу. Словарь этот будете в файл писать, потом лочить, чтобы не писать из нескольких мест и т.д. и т.п.

Если бы мне нужно было что-то подобное, то я бы заюзал уже имеющийся проект, а не изобретал бы велосипед. Вы же не первый которому нужно показать список юзеров ‘на сайте’ :)

Вот этот, например: http://code.google.com/p/django-tracking/

Ed
И где этот словарь хранится?

В settings.py. Не годится?

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

Нет только в памяти, памяти сколько нужно поставлю, лочить не нужно. Очень нагруженный проект, хотелось бы обращения к диску минимизировать. При перезагрузке,правда, всё пропадет(это поправимо), но вскоре опять заполнится. Показывать нужно при каждом запросе(как в чате), а они идут часто. Нужная информация почти всегда есть под рукой почти в каждом запросе, так зачем еще раз к диску обращаться?

Ed
Если бы мне нужно было что-то подобное, то я бы заюзал уже имеющийся проект, а не изобретал бы велосипед. Вы же не первый которому нужно показать список юзеров ‘на сайте’ :)
Вот этот, например: http://code.google.com/p/django-tracking/

Спасибо, почитал, очень интересно. Для другого проекта обязательно заюзаю, но для этого много лишнего и мне еще нужны для юзера нестандартные поля, которых там нет.

PyCraft
В settings.py. Не годится?

Ну, я не особый знаток django, но сильно подозреваю, что словарь этот будет доступен только одному процессу питона.
У остальных(если они есть, конечно) будут собственные :)

Нет только в памяти, памяти сколько нужно поставлю, лочить не нужно.

Дело тут не в памяти, а в доступе. Вы догадываетесь как это все работает на уровне пониже? Ну, скажем, ваш веб-сервер стартует несколько процессов python, они уже работают с django. Клиентские http запросы разделяются между этими питонами.
Сколько будет жить ваш словарь и в каком процессе?
Лучше, конечно, если более знающие архитектуру django разъяснят как это все работает.

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

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

и мне еще нужны для юзера нестандартные поля, которых там нет.

Все уже придумано за вас, не нужно изобретать велосипед: http://docs.djangoproject.com/en/dev/topics/auth/#storing-additional-information-about-users

Ок. У меня это уже используется. Буду думать в сторону кэширования шаблов.