Как передать данные аутентификации в запросе HTTP DELETE?

Я пытаюсь создать REST API после семантики метода HTTP, но я застрял в методе DELETE.Как передать данные аутентификации в запросе HTTP DELETE?

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

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

Выдать запрос POST с идентификатором пользователя в качестве тела. Мне это не нравится, потому что я в основном использую POST с идентифицированным ресурсом и потому что семантически звучит неправильно для меня.
Сделайте запрос, чтобы идентификатор пользователя являлся переменной пути. Это будет выглядеть так. путь/к/услуге/ResourceId/{ResourceId}/идентификатор пользователя/{} идентификатор пользователя. Моя проблема заключается в том, что в запросах POST и PUT userId является частью тела. API не будет выглядеть последовательным, но, я думаю, я все еще мог бы изменить другие 2, поэтому идентификатор пользователя также является частью URL-адреса.

Любые предложения?

источник

2016-07-28 Kilian

Вы должны использовать параметр HTTP-заголовка для передачи токена пользователя.

@DELETE 
@Path("/{id}") 
@Consumes(MediaType.APPLICATION_JSON) 
@Produces(MediaType.APPLICATION_JSON) 
public Info deleteInfo(
     @HeaderParam("Authorization") String token, 
     @PathParam("id") Long id){ 
}

источник

2016-07-29 08:06:46 Justas

Является ли это еще применимым, когда пользователь уже авторизован? В моем случае причиной, по которой мне нужен userId, является проверка того, что ресурс действительно принадлежит ему, так как это конечное приложение, которое хранит данные. Поэтому я думаю, что это не было бы авторизацией в этом случае, просто проверка того, что ресурс 1 принадлежит пользователю 1, а не пользователю 2. Будет ли это подход к передаче данных клиентов для проверки для каждого приложения и метода? Является ли информация о клиенте, как его идентификатор, недействительной переменной пути, как в случае, если он выдает запрос GET, чтобы получить все свои ресурсы из приложения? (например, path/to/app/user/{userId}) – Kilian

Аутентификация = логин + пароль (кто вы) Авторизация = разрешения (что вам разрешено делать) - http://stackoverflow.com/questions/6556522/authentication -versus авторизации. В моем приложении я использую логин POST с телом JSON, который содержит имя пользователя и пароль, он возвращает токен, который используется позже в параметре заголовка. – Justas

Вы правы, это авторизация пользователя. В этом случае я буду придерживаться этого. благодаря – Kilian

HTTP-аутентификация, может быть? Это для чего, нет? См. RFC 7235.

источник

2016-07-28 17:48:02

Аутентификация осуществляется на уровне шлюза и связь осуществляется с ДЗ, то есть, где шлюз для внутреннего приложения, где мне нужно userId.to быть честным, я не очень хорошо знаком с ограничения безопасности один раз внутри внутренней сети компании, но я предполагаю, что аутентификация в каждом вызванном микросервисе не будет очень результативной. – Kilian

Как передать данные аутентификации в запросе HTTP DELETE?

ответ

Смежные вопросы