Можно ли создать систему входа в систему, которая не использует сеанс / cookie на стороне клиента?

Я работаю над приложением Flask, которое будет использовать медицинский клиент. Их ИТ-отдел настолько заботится о безопасности, что отключает файлы cookie и сценарии по всей сети.

К счастью, wtf-forms удалось решить одну из этих проблем с помощью проверки ввода формы на стороне сервера.

Однако я зацикливаюсь на системе входа в систему. Я реализовал flask-login, но для этого, по-видимому, требуются данные на стороне клиента, поскольку я не могу войти в систему при тестировании в браузере с отключенными этими функциями.

Есть ли способ создать логин с нулевыми данными на стороне клиента?

Спасибо за помощь.


person Chockomonkey    schedule 22.02.2014    source источник
comment
Вы нашли решение этой проблемы? Хотел бы услышать подробности об этом, так как я также столкнулся с той же проблемой, когда он не мог пройти экран входа в систему и продолжал его зацикливать ...   -  person jdp    schedule 21.03.2018
comment
@Jignesh Я не закончил этот проект, так как он был заброшен :(   -  person Chockomonkey    schedule 22.03.2018


Ответы (4)


Конечно, вы можете обойтись без файлов cookie. Вам просто нужно получать авторизацию по каждому запросу.

Вот пример во флаконе с использованием только базовой HTTP-аутентификации. Если вы не используете 100% времени HTTPS, вам следует использовать Digest Auth, который является безопасный.

person Javier    schedule 22.02.2014

С такими ограничениями, как отсутствие нулевых данных на стороне клиента, вы можете передать токен сеанса в параметрах GET каждой ссылки, отображаемой на странице html.

Или вы можете создать только POST-представления со скрытым вводом токена (что действительно может быть более безопасным).

person Benjamin Toueg    schedule 22.02.2014
comment
Затем каждый раз, когда кто-то копирует / вставляет ссылку, любой пользователь, нажимающий на эту ссылку (обязательно), получает доступ к учетной записи пользователя, который ее скопировал. Это маскировка под безопасность, не связанная с безопасностью. - person FrankieTheKneeMan; 22.02.2014
comment
Вы можете привязать токен к IP-адресу или сделать все в POST. - person Benjamin Toueg; 22.02.2014
comment
DHCP делает это практически невозможным. Блуждающий клиент в беспроводной сети загружался каждый раз, когда он перемещал свой портативный компьютер. - person FrankieTheKneeMan; 22.02.2014
comment
Как было сказано выше, вы можете спроектировать весь свой сайт в POST. Что касается DHCP, я думаю, что ограничения, с которыми сталкивается OP, связаны с какой-то частной сетью компании, в которой компьютеры могут быть подключены к сети с фиксированным IP. Так что это зависит от ситуации. - person Benjamin Toueg; 22.02.2014
comment
OP сказал, что его клиент - медицинский клиент, заботящийся о безопасности, и ничего больше. Хотя возможно, что они используют только проводные терминалы, вполне возможно, что они контролировали корпоративные ноутбуки, планшеты и т. Д. - person FrankieTheKneeMan; 22.02.2014
comment
А проектировать весь сайт в POST - ужасная архитектура. Лучше убедить клиента внести ваше имя хоста в белый список и подключаться только через SSL. - person FrankieTheKneeMan; 22.02.2014
comment
Поправьте меня, если я ошибаюсь, но веб-формы ASP.NET - это формы везде на ваших веб-страницах. И это технология, которая широко используется, хотя я согласен, что это ужасно. - person Benjamin Toueg; 22.02.2014
comment
Определенно POST, а не GET. Именно так работают веб-формы (все является POST и все отправляет состояние обратно самому себе) - это довольно ужасно, но если вы не можете использовать сценарии и не можете использовать файлы cookie, это единственный способ, которым я знаю для сохранения состояния - это передавать токен туда и обратно через скрытый ввод и форму (единственное, что у вас не может быть никаких ссылок - все должно быть кнопкой, потому что все должно отправить форму, чтобы сохранить состояние [ хотя вы можете стилизовать кнопки так, чтобы они выглядели как ссылки]) - person Sean Vieira; 22.02.2014
comment
HTTP Basic Auth также предоставит вам аутентификацию, как и другой вариант в этой среде. - person Sean Vieira; 22.02.2014

Другой подход, который напоминает мне старые добрые времена в PHP с использованием trans-sid, заключался бы в передаче session_id в URL-адресе и сохранении сеанса на бэкэнде, чтобы параметры URL-адреса не становились слишком большими (в случае большого сеанса магазины).

Вы можете реализовать это, используя комбинацию сигналов @app.url_defaults и @app.url_value_preprocessor, также известных как препроцессоры URL Flask .

Это зависит от того, правильно ли вы используете url_for, потому что туда будет добавлен идентификатор сеанса. Давайте сделаем короткое доказательство концепции:

@app.url_defaults
def add_session_id(endpoint, values):
    if 'session_id' in values:
        # Allows to manually override the session_id, might not be wanted.
        return
    if g.session_id:
        values['session_id'] = g.session_id

@app.url_value_preprocessor
def pull_session_id(endpoint, values):
    g.session_id = values.pop('session_id', None)

Теперь все, что вам нужно сделать, это сохранить сеанс в удобном месте (например, используя БД или Redis и установите session_id с помощью g.session_id = session_id_here.

В каждом последующем запросе g.session_id должен быть тем же идентификатором сеанса, потому что url_for должен добавлять ?session_id=yoursessionid к URL-адресу. Ваша аутентификация должна проверить наличие g.session_id и действовать соответствующим образом.

Обратите внимание, что если ваш сеанс остается небольшим, вы, вероятно, можете сохранить весь сеанс в параметре url вместо идентификатора.

person Menno    schedule 22.02.2014

Неа. Это буквально невозможно по чистому HTTP. HTTP - это протокол без сохранения состояния, что означает, что для сохранения состояния клиент должен иметь возможность идентифицировать себя при каждом запросе.

Что вы можете сделать, так это базовую аутентификацию HTTP через HTTPS, а затем получить доступ к этой аутентификации на стороне сервера.

person FrankieTheKneeMan    schedule 22.02.2014
comment
Это могут быть обходные пути, например передача токена в ответах http html. - person Benjamin Toueg; 22.02.2014
comment
Вы можете передать сеанс в параметрах GET, но это так же безопасно, как и просто сделать все ваши ресурсы общедоступными. - person FrankieTheKneeMan; 22.02.2014
comment
Не совсем так, или объясните, почему это будет менее безопасно. - person Benjamin Toueg; 22.02.2014
comment
Это просто небезопасно. Он не обеспечивает защиты учетной записи и позволяет очень легко случайно предоставить злоумышленнику доступ к вашей учетной записи. - person FrankieTheKneeMan; 22.02.2014