Исправление x3al, (текущая версия) :
Планирую сейчас блюпринты, потом пойду в django
Не знаю насчёт flask, но джанга всегда будет сохранять кусок юзера в свою базу при аутентикации в ldap. Она не должна дать зайти если юзер из ldap удалён на момент входа, но если есть старая сессия — её никто не убьёт. Без своей модели в джанге нельзя (вообще никак) потому, что в очень многих местах ожидается foreign key на settings.AUTH_USER_MODEL, поэтому, очевидно, таблица с этой AUTH_USER_MODEL обязана быть в той же базе, что и всё остальное приложение.
я ее кеширую вместе с юзером в sql.
Если flask сделан нормально — он не должен кэшировать пароль и должен обновлять копию в твоей rdbms каждый раз когда юзер вводит этот самый пароль.
Или как мне очищать sql от юзеров по таймауту?
Убедись, что твоя проблема — не в сессиях. Судя по твоему вопросу, она именно там.
Ты можешь добавить лишнюю проверку статуса в ldap при подхвате сессии с юзером, это решит все проблемы (ну, у тебя добавится 1 запрос в ldap на буквально каждый HTTP-запрос, но иногда это может быть ок решением).
Но почему я не могу просто и сразу прямо использовать ldap в качестве базы юзеров? без sql или каких-то костылей?
Потому, что foreign key и транзакции между двумя разными базами данных (твоя rdbms и LDAP) — ОЧЕНЬ сложные вещи и django/flask не заморачиваются ими.
Но так же это приведет к лагам между изменением в open-ldap и реакции приложения на эти изменения:
Потому, что у тебя распределённая система и твоя проблема — на выбор — инвалидация кэша либо распределённые транзакции. Прямой способ решить всё это — не делать систему распределённой (= хранить все разрешения и роли в ldap), тогда ты потеряешь возможность управлять юзерами средствами flask/django. И да, тебе придётся переписать весь auth-кусок этих фреймворков поскольку навскидку готового решения (без копирования информации из ldap) я не помню. Я бы посоветовал вместо этого пользоваться костылями, если честно.
Исходная версия x3al, :
Планирую сейчас блюпринты, потом пойду в django
Не знаю насчёт flask, но джанга всегда будет сохранять кусок юзера в свою базу при аутентикации в ldap. Она не должна дать зайти если юзер из ldap удалён на момент входа, но если есть старая сессия — её никто не убьёт. Без своей модели в джанге нельзя (вообще никак) потому, что в очень многих местах ожидается foreign key на settings.AUTH_USER_MODEL, поэтому, очевидно, таблица с этой AUTH_USER_MODEL обязана быть в той же базе, что и всё остальное приложение.
я ее кеширую вместе с юзером в sql.
Если flask сделан нормально — он не должен кэшировать пароль и должен обновлять копию в твоей rdbms каждый раз когда юзер вводит этот самый пароль.
Или как мне очищать sql от юзеров по таймауту?
Убедись, что твоя проблема — не в сессиях. Судя по твоему вопросу, она именно там.
Ты можешь добавить лишнюю проверку статуса в ldap при подхвате сессии с юзером, это решит все проблемы (ну, у тебя добавится 1 запрос в ldap на буквально каждый HTTP-запрос, но иногда это может быть ок решением).
Но почему я не могу просто и сразу прямо использовать ldap в качестве базы юзеров? без sql или каких-то костылей?
Потому, что foreign key и транзакции между двумя разными базами данных (твоя rdbms и LDAP) — ОЧЕНЬ сложные вещи и django/flask не заморачиваются ими.
Но так же это приведет к лагам между изменением в open-ldap и реакции приложения на эти изменения:
Потому, что у тебя распределённая система и твоя проблема — на выбор — инвалидация кэша либо распределённые транзакции. Прямой способ решить всё это — не делать систему распределённой (= хранить все разрешения и роли в ldap), тогда ты потеряешь возможность управлять юзерами средствами flask/django. И да, тебе придётся переписать весь auth-кусок этих фреймворков поскольку навскидку готового решения (без копирования информации из ldap) я не помню.