2014-02-02 3 views
18

Я защищаю свое приложение, используя Spring Security 3.1.3, и у меня есть требование разрешить пользователям входить в систему по ссылке в стороннем приложении.Spring Security 3.1.3 запрос querystring stripped

Однако ссылка в стороннем приложении будет перенаправляться на определенный ресурс, а не на страницу входа, где ресурс, который пользователь желает получить для доступа, будет определяться как параметр querystring. Так, например, ссылка будет иметь вид //server.com/app/build/panel.jsp? Resourceid = 'blah'`

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

Теперь все это отлично работает, кроме строки запроса, которая лишается Spring Security, прежде чем она войдет в поток обработки запроса. Это показано в отладочном выпуске Spring Security;

org.springframework.security.web.savedrequest.HttpSessionRequestCache: DefaultSavedRequest добавлено к сессии: DefaultSavedRequest [http://server.com:8080/app/build/panel.jsp]

т.е. строки запроса не сохраняется, а? resourceid = 'blah' удален.

Примечание. В настоящее время я использую Ant-сопоставление. Мне не нужно на самом деле сопоставлять запрос.

В более ранних версиях Spring Security казалось, что вы можете повлиять на это поведение, используя BeanPostProcessor в соответствии с этим сообщением, Spring Security - Url with request parameters rules ignored. Но метод DefaultFilterInvocationSecurityMetadataSource.setStripQueryStringFromUrls() был удален из Spring Security 3.1.3.

Как настроить Spring Security, чтобы не отделять запрос от исходного запроса? Итак, когда пользователь перенаправляется после входа в систему до исходного URL-адреса, параметр querystring будет сохранен?

Большое спасибо Howard

+1

Я отлажена через текущую версию (3.2.3) и нашла то же самое. В javaDoc RequestWrapper есть просветительский комментарий: Параметры (как определено в RFC 2396) удаляются из сегментов пути значений servletPath и pathInfo запроса. Однако я также заметил, что к моменту поступления запроса в оболочку контейнер, похоже, отключил их (в моем случае Tomcat 7). – hoserdude

+0

Вы когда-нибудь находили решение? Я сталкиваюсь с той же проблемой с именем RememberMe. У меня есть ссылка на отказ в электронном письме с двумя параметрами. Он работает, если нет cookie RememberMe или если пользователь уже выполнил вход в систему. Если существует допустимый файл cookie, и пользователь не зарегистрирован, параметры будут удалены до того, как запрос будет перенаправлен после успешного входа в систему RememberMe. – LWK69

+0

Из того, что я помню, проблема заключалась в том, что в запросе были определенные символы. Для этого приложения я имел дело с querystring, который был получен от интерфейса AngularJS, и что в запросе также содержалась навигационная страница AngularJS, которая была представлена ​​символом #. Итак, querystring было что-то вроде // server/app/some-page? # New-issue /. Это было присутствие # char, которое, казалось, означало, что весь запрос был удален. У вас есть специальные символы в вашем запросе? – user3262600

ответ

0

Это в основном обработчик успеха.

Вы можете посмотреть на этом примере:

@Override 
protected void configure(HttpSecurity http) throws Exception { 
    http 
     .authorizeRequests() 
     .antMatchers("/login*") 
     .permitAll() 
     .anyRequest() 
     .authenticated() 
     .and() 
     .formLogin() 
     .successHandler(new RefererAuthenticationSuccessHandler()); 
} 

Более подробная информация о нем: http://www.baeldung.com/spring-security-redirect-login

+0

На этот вопрос ответил плакат: ошибка кодирования - см. Комментарии –

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