Создайте обработчик запросов Vaadin, который обрабатывает запрос до того, как Spring Security получит шанс - PullRequest
2 голосов
/ 22 мая 2019

Итак, мы стремимся перенести приложение из Thorntail в Spring Boot.

Одна из проблем заключается в том, что мы используем Vaadin 8 по старым причинам.

Приложение обеспечивает поддержку входа без пароля (как при входе по ссылке).

Теперь vaadin - это одностраничный фреймворк, поэтому мы разделили параметры входа /login и /passwordless на пользовательский интерфейс Vaadin их собственного s.t. мы можем настроить

override fun configure(http: HttpSecurity) {
    http
        .csrf().disable()
        .httpBasic().disable()
        .formLogin().disable()
        .authorizeRequests()
            .antMatchers("/login").anonymous()
            .antMatchers("/passwordless/**").permitAll()
            .antMatchers("/vaadinServlet/UIDL/**").permitAll()
            .antMatchers("/vaadinServlet/HEARTBEAT/**").permitAll()
            .anyRequest().authenticated()
            .and()
        .logout()
            .addLogoutHandler(logoutHandler())
            .logoutUrl("/logout")
            .logoutSuccessUrl("/login?goodbye").permitAll()
            .and()
        .exceptionHandling()
            .authenticationEntryPoint(LoginUrlAuthenticationEntryPoint("/login"))
}

К сожалению, нам придется поддерживать старые ссылки, которые уже были распространены, а также для обратной совместимости. А старые логин-ссылки были установлены как

/#!passwordless/<login-token>

Это означает, что даже если мы добавим фильтр, мы не сможем отличить запрос от любого другого запроса до /.

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

Можем ли мы как-то определить обработчик запроса vaadin (который имеет доступ к местоположению vaadin /#!passwordless/<login-token> и, следовательно, может прочитать <login-token> и перенаправить на /passwordless/<login-token>), прежде чем Spring-security сможет перенаправить нас на /login?

1 Ответ

0 голосов
/ 27 мая 2019

Поскольку хеш не включен в HTTP-запрос, его невозможно разместить на сервере до отправки ответа.

Возможно, вы могли бы настроить фильтр, который перехватывает все запросы на /. Если пользователь аутентифицирован, он ничего не делает. В противном случае он либо перенаправляет на другую страницу, на которой есть некоторый JavaScript, либо затем напрямую возвращает некоторый JavaScript, который проверяет хэш и выполняет перенаправление на стороне клиента либо на /login, либо на /passwordless/<login-token>.

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

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

...