Radist_101: ага, можно не в md5, а в sha1 засовывать из соображений паранойи.
Но, каждый session_id железно будет уникальным, если кодировать в нем user_id + соль.
Теперь, когда сессии хранятся на сервере, вы можете сами давать им свои значения.
Например, session_id = md5(user_id + login + соль ).
Ну и писать session_id в базу и в куку юзера.
Radist_101: Да, правильно. Можно еще сделать поле ID юзера - уникальным, исходя из вашей задачи наверное - это было бы логично. Тогда не нужен будет before_request и всякие там проверки.
Radist_101: Надо запросить у базы все сессии данного юзера.
И удалить их тоже.
Типа, "'DELETE FROM session WHERE '".
После этого все сессии, на всех устройствах у юзера станут недействительны.
session.clear() - не обязательно.
Можно просто просто заредиректить на /logout/ - текущего юзера.
Radist_101: Вы можете хранить сессии в MySQL. Возможно, вам будет удобнее. Зайдете и сделаете выборку. А когда с MySQL разберетесь, то можно будет перенести в редис, да и то если будет тормозить.
А если будет работать быстро, то с редисом можно не заморачиваться.
Radist_101: А по идеи с этим снипетом заработает session_protection == 'strong'.
flask-login сам будет уже проверять и before_request будет не нужен.
before_request - пригодился бы, если вы захотите сами написать проверку.
Ну то есть обратились к базе редиски. И проверили сколько открытых сессий у юзера, если больше одной то их бы отстрелили.
Radist_101: Если сессии хранятся на сервере, то обратится к серверу и проверить.
Например, обратится к MySQL, sqlite, текстовые файлы и т.д.
А вот если сессии хранятся в куках пользователя, тогда два пути. Или переходить на серверное хранение или написать что-нибудь самописное. И хранить имя сессии и user_id в виде словаря, где-нибудь на сервере и обращаться при необходимости. В redis хорошо такие вещи держать, в формате ключ - значение.
Scorry: , Руслан Федосеев: , ну хорошо. Вот я через IMAP принял почту. Для меня это не проблема.
Но дальше, допустим мне надо отсортировать письма прошлого месяца, от определенного отправителя, от определенного получателя, с определенной темой.
Хотите сказать, что в IMAP эта сортировка будет быстрее, чем с индексированными полями в MySQL?
Вот есть у меня сервер myserver.com. На котором стоит postfix на 25 порту.
Я посылаю на него письмо с другого сервера:
sc5:~ # mail user@myserver.com
Subject: test
test
EOT
sc5:~ #
Письмо ушло.
Теперь если я зайду на свой сервер myserver.com, то увижу это письмо в файле:
/var/mail/user
Мне нужно, чтобы это письмо оказалось в mysql базе.
Nadz Goldman: Мне кажется, что вы даже не понимаете о чем идет речь.
По вашим ссылкам.
Найдите хоть одну статью, в которой шла бы речь о сохранении входящих сообщений.
Там используется MySQL совсем для других целей.
Scorry: Ну представьте у вас есть сайт, который должен каким-то образом получить почту, отфильтровать и обработать ее. Для меня самый лучший путь - это обращаться к MySQL базе и забирать почту оттуда. Каким образом ее туда доставить в этом и заключается вопрос.
POP3 - не нужен.
А можно ссылку как заставить exim складывать входящую почту в MySQL?
И ссылку на модуль postfix чтобы он мог сохранять входящие письма в MySQL?
Я ничего подобного найти не могу.
Если "Пусть будет еще один скрипт, который будет проходить по imap ящику, индексировать его и складывать в базу необходимую информацию. " То зачем тогда imap? :)
Только лишнее звено получается.
А напрямую сайту работать с imap неудобно. Медленно. И потеря реляционной составляющей, которая есть в MySQL.
Дальше с этими письмами будет работать сайт, который находится на том же сервере.
Сайт будет обращаться к mysql базе забирать за нужный период письма.
Дополнительно их обрабатывать и т.д.
Но, каждый session_id железно будет уникальным, если кодировать в нем user_id + соль.