Resteasy Common QueryParams для некоторых сервисных вызовов - PullRequest
Новая
       7

Resteasy Common QueryParams для некоторых сервисных вызовов

0 голосов
/ 15 апреля 2011

Я использую клиентскую среду Resteasy и у меня есть несколько методов, которые требуют аутентификации на сервере. Аутентификация достигается с помощью билета сеанса, и этот билет должен быть включен в качестве параметра запроса в URL запроса. По умолчанию, мне нужно передать билет на все мои сервисные вызовы следующим образом: 

@Path("/services")
public class MyServiceClient {

    @POST
    @Path("service1")
    public void callService1(@QueryParam("ticket") String ticket);

    @GET
    @Path("service2")
    @Produces("text/plain")
    public String callService2(@QueryParam("ticket") String ticket, ...);
}

Но я не хочу передавать параметр ticket каждому из моих сервисных вызовов. Мне нужно решение, чтобы установить его в качестве параметра запроса для каждого из этих вызовов обычным способом. Таким образом, мои методы вызова службы будут принимать только фактические параметры службы, за исключением заявки. Но при запросе услуги билет будет включен в URL запроса.

Есть ли способ сделать это?

Заранее спасибо.

Ответы [ 2 ]

1 голос
/ 26 апреля 2013

У меня такая же ситуация. Извините, что воскресил старую ветку, но все равно ...

Вместо того, чтобы помещать тикет в строку запроса, почему бы не включить его в качестве заголовка HTTP, в частности, заголовка авторизации, например: 

Authorization: Token ABCD1234-1234-1234-1234-ABCD1234ABCD

Вы также можете принять Basic auth. Это позволяет вам использовать API из веб-браузера без каких-либо модных плагинов или расширений. Заголовок будет выглядеть так: 

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Затем в своем коде на стороне сервера используйте HttpServletFilter для защиты всего доступа к вашему RestEasyServlet. В методе doFilter прочитайте заголовок авторизации. Только вызывайте chain.doFilter (который передаст запрос в RestEasyServlet), если заголовок проверен. Если его там нет или он просрочен или недействителен и т. Д., То из вашего фильтра верните HTTP 401.

Если ваш заголовок аутентификации начинается с "Token", удалите первые шесть символов, а затем возьмите оставшуюся часть значения и выполните поиск в таблице базы данных сеанса или на карте. Если он там и не истек, пропустите их.

Если ваш заголовок аутентификации начинается с «Basic», удалите первые шесть символов, а Base64 расшифруйте остальные. Разделите на ":" и используйте два токена, чтобы найти пользователя в вашей базе данных.

Я тоже немного обманываю в своем фильтре. Так как мне все равно приходится искать этот токен (или имя пользователя / пароль) из базы данных, я создаю объект User из ResultSet и сохраняю его в ThreadLocal на фильтре. Затем я предоставляю статический метод для моего фильтра, который позволяет мне получить доступ к «текущему пользователю» из любой точки JVM. Я использую команду try / finally в своем фильтре, чтобы очистить ThreadLocal, чтобы он всегда очищался после завершения запроса.

1 голос
/ 07 мая 2011

Я думаю, вы можете связать @PathParams с классом включения, чтобы они могли использоваться в каждом методе без переобъявления Я никогда не пробовал, но видел пример здесь: http://www.mastertheboss.com/web-interfaces/309-handling-web-parameters-with-resteasy.html

...