Как мне реализовать обработчик Auth, который вступает в силу при ответе? - PullRequest
Новая
       8

Как мне реализовать обработчик Auth, который вступает в силу при ответе?

0 голосов
/ 30 мая 2020

Я sh, чтобы реализовать обработчик Auth для запросов, который обрабатывает аутентификацию с сервером авторизации OAuth, чтобы разрешить следующее: 

import requests

requests.get(url, auth=KeycloakAuth())

До сих пор я применил ловушку ответа когда вызывается KeycloakAuth, так что когда клиент перенаправляет вызывающего в Keycloak, ловушка увидит страницу входа в Keycloak, отправит учетные данные в Keycloak и будет перенаправлена ​​обратно клиенту.

Однако это не работает для POST, поскольку запросы отправляют POST на страницу входа в Keycloak вместо GET из-за перенаправления. Keycloak не возвращает форму входа в систему в ответ на POST, и это не удается.

Я подумал о проверке перенаправления в хуке ответа, чтобы я мог изменить перенаправление, чтобы вместо этого выполнить GET в Keycloak, но это похоже, что реализация перенаправления запросов обходит все хуки.

1 Ответ

0 голосов
/ 02 июня 2020

Вникнув в это еще немного, я считаю, что это неправильный вопрос.

Я искал решение, в котором, независимо от исходного метода HTTP, используемого на клиенте (GET, POST, HEAD, et c), библиотека автоматически войдет в Keycloak, а затем «воспроизведет» исходный запрос клиенту и сделает его прозрачным для пользователя библиотеки.

Однако это может ' Возможно, работать с OAuth 2.0 без дальнейшего управления состоянием со стороны библиотеки или клиента из-за перенаправления.

Предположим, что исходный запрос был POST с некоторыми данными. После обнаружения того, что пользователь не вошел в систему, User-Agent будет перенаправлен на сервер авторизации для аутентификации.

Это означает, что данные POST исходного запроса будут потеряны, что исключает возможность повторного воспроизведения при пользовательский агент перенаправляется обратно клиенту после аутентификации.

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

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

Таким образом, этот обработчик Auth, вероятно, не то, что мы можем реализовать в библиотеке.

...