Облачные конечные точки: параметры доступа в фильтре сервлетов

Я пытаюсь создать API с конечными точками Google Cloud.

Поскольку облачные конечные точки не обеспечивают аутентификацию помимо собственного OAuth Google, я пытаюсь создать свой собственный. Поэтому я хочу получить доступ к параметрам, предоставленным для API (например, токен @Named("token")) внутри фильтра сервлета.

К сожалению, я не могу найти предоставленную информацию внутри httpRequest. Это нормально? Есть ли возможность доступа к параметрам?

Я был бы признателен, если бы кто-нибудь мог мне помочь!

ОБНОВЛЕНИЕ:

С информацией от jirungaray я попытался создать аутентификацию с использованием заголовков, но столкнулся с той же проблемой. Использовал REST-клиент для отправки некоторых заголовков, так как я не мог понять, как это сделать с помощью API Explorer. Внутри моего фильтра я пытаюсь получить доступ к токену из заголовков:

@Override
public void doFilter(
        ServletRequest request,  ServletResponse response, FilterChain chain)
        throws IOException, ServletException {

    HttpServletRequest httpRequest = (HttpServletRequest) request;
    String authToken = httpRequest.getHeader(Constants.AUTH_TOKEN);
    ...
    chain.doFilter(request, response);
}

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

С Guice у меня есть следующий провайдер, использующий токен для внедрения FacebookClient (используя токен) для каждого запроса.

@Provides
public FacebookClient getFacebookClientProvider(@Named("fbToken") Provider<String> fbToken) {
    return new DefaultFacebookClient(fbToken.get(), Version.VERSION_2_2);
}

Как описано в вики Guice (SevletModule), здесь используется фильтр sevlet для получить информацию из запроса.

Есть ли какое-либо решение для достижения такого рода DI с облачными конечными точками?


person PhilippS    schedule 21.04.2015    source источник
comment
Если вы хотите, чтобы ваш вопрос получил больше просмотров, вам действительно следует включить java в качестве одного из ваших тегов. Но у вас только 5, и я не уверен, какой из них вы бы предпочли удалить. Вероятно, guice-servlet.   -  person durron597    schedule 22.04.2015
comment
Ok. Спасибо за совет. Буквально пару минут назад удалил. Теперь он вернулся!   -  person PhilippS    schedule 22.04.2015
comment
Вы можете получить представление о том, какие теги включить, наведя на него курсор и увидев, сколько у них подписчиков и сколько у них вопросов. Крошечный тег, такой как guice-servlet, на самом деле никому не поможет найти ваш вопрос, но многие люди ищут последние сообщения с тегами java. Поэтому выберите самые популярные теги, подходящие для вашего сообщения. Если бы я только знал, как решить твой вопрос... :)   -  person durron597    schedule 22.04.2015
comment
Интересно знать. Я подумал, что с тегом java этот вопрос составляет всего один вопрос на миллион, тогда как в случае не столь популярного тега люди, просматривающие этот тег, получают больше внимания, имея всесторонние знания по теме.   -  person PhilippS    schedule 22.04.2015
comment
Лично я большую часть времени просматриваю самые новые/активные вопросы с пометкой Java и иногда добавляю несколько меньших тегов (например, guice ) старые вопросы можно увидеть только в том случае, если у кого-то есть именно ваша проблема.   -  person durron597    schedule 22.04.2015


Ответы (1)


Филипп, Да, это имеет смысл, что вы получаете пустой запрос. Ваши вызовы конечной точки сначала обрабатываются Google (они получают вызовы API), а затем обрабатываются и отправляются обработчику в вашем приложении. Поскольку все это делается в фоновом режиме, очень легко пропустить, что ваши конечные точки на самом деле не получают тот же запрос, который вы отправили, они получают совершенно другой запрос, отправленный из инфраструктуры Google.

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

eg.

    public APIResponse doSomething(SomeComplexRquestModel request,
            HttpServletRequest rawRequest) {
}

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

person jirungaray    schedule 21.04.2015
comment
Обычно я не возражаю против использования поля заголовка. Я бы даже предпочел это тоже. Но как установить это поле с помощью сгенерированной клиентской библиотеки? При использовании этого поля заголовка можно ли получить к нему доступ в фильтре? Это упростит автоматизацию аутентификации за пределами конечных точек. Делает ли это невозможным использование проводника API, поскольку я не могу понять, как установить в нем поле заголовка? - person PhilippS; 21.04.2015
comment
Я обновил вопрос, указав более конкретную информацию о реальной проблеме, которую я хочу решить. Возможно, это поможет найти решение. - person PhilippS; 22.04.2015
comment
Какую проблему вы получаете сейчас? является ли заголовок нулевым, когда вы перехватываете запрос с помощью своего фильтра? - person jirungaray; 23.04.2015
comment
Внутри моего фильтра я пытаюсь получить доступ к заголовку с помощью: httpRequest.getHeader(token); но это всегда возвращает null для заголовков, которые определенно установлены. - person PhilippS; 27.04.2015