Клиент Джерси: аутентификация не проходит при перенаправлении Дженкинсом

Question

Я пытаюсь использовать REST API Дженкинса. Дженкинс требует POST-запрос к URL, чтобы удалить работу. Это приводит к следующему:

1. Я говорю своему выбранному Клиенту отправить POST на соответствующий URL.
   Клиент отправляет POST и авторизуется, используя имя пользователя и пароль.
2. Дженкинс удаляет работу.
3. Jenkins возвращает «302 - Найдено» с расположением папки, содержащей удаленное задание.
4. Клиент автоматически отправляет POST в местоположение.
5. Дженкинс отвечает «200 - ОК» и полными HTML страницы папки.

Это Почтальон прекрасно работает (если, конечно, я не отключу «Автоматически следовать перенаправлениям»). Однако на шаге 5 Джерси продолжает набирать «404», потому что я запретил анонимным пользователям просматривать данную папку. (Или «403», если я полностью заблокировал анонимных пользователей.) Обратите внимание, что аутентификация работает на шаге 1, потому что задание было успешно удалено!

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

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

Код в вопросе:

HttpAuthenticationFeature auth = HttpAuthenticationFeature.basicBuilder()
    .credentials(username, token)
    .build();
Client client = ClientBuilder.newBuilder()
    .register(auth)
    .build();
WebTarget deleteTarget = client.target("http://[Jenkins-IP]/job/RestTestingArea/job/testJob/doDelete")  
Response response = deleteTarget.request()
    .post(null);

РЕДАКТИРОВАТЬ:"302-Найдено" имеет только 5 заголовков в соответствии с почтальоном: Дата, X-Content-Type-Options ("nosniff"), Location, Content-Length (0) и Server. Так что ни куки, ни токены, которые мог бы использовать Почтальон, и Джерси не обращали на это внимания.

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

EDIT2: Я также определил, что проблема явно в аутентификации. Если я разрешу анонимным пользователям просматривать нужную папку, ошибка исчезнет, ​​и сервер ответит 200.

Answer 1

Я нашел ответ с помощью Пола Самсота и Гаутама .

TL; DR: Это намеренное поведение, и вы необходимо установить системное свойство http.strictPostRedirect=true, чтобы заставить его работать или выполнить второй запрос самостоятельно.

---

Как также описано здесь , HttpURLConnection решено не реализовывать перенаправление, как оно определено в стандарте HTTP, а вместо этого, как это было реализовано во многих браузерах (в терминах непрофессионалов: «Делайте это, как все, вместо того, как это должно работать»). Это приводит к следующему поведению:

1. Отправка POST на URL_1.
2. Сервер отвечает «302 - Найдено» и включает в себя URL_2.
3. Отправка GET на URL_2 , отбрасывая все заголовки .
4. Сервер отвечает «404 - не найден», так как второй запрос не включает правильные заголовки аутентификации.
5. Ответ «404» это тот, который получен кодом, так как шаги 2 и 3 «скрыты» нижележащим кодом.

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