Spring Security-API网关模式-错误? [英] Spring Security - api gateway pattern - bug?
问题描述
我们创建了一个模仿Spring Security-API Gate Pattern教程的应用程序( https://spring.io/guides/tutorials/spring-security-and-angular-js/#_the_api_gateway_pattern_angular_js_and_spring_security_part_iv ).唯一的变化是我们使用的是MySQL数据库而不是Redis.
We've created an application that mimics the Spring Security - API Gate Pattern tutorial (https://spring.io/guides/tutorials/spring-security-and-angular-js/#_the_api_gateway_pattern_angular_js_and_spring_security_part_iv). The only variation is that we're using a MySQL database rather than Redis.
使用localhost:8080作为根，我们有localhost:8080/login(登录页面)，localhost:8080/ui(jQuery客户端)和localhost:8080/api(静态Web服务，业务逻辑等).
Using localhost:8080 as the root, we have localhost:8080/login (login page), localhost:8080/ui (jQuery client), and localhost:8080/api (restful web services, business logic, etc.)
我们发现会话处理和转发到各个实体的工作正常.这意味着将按预期方式创建会话，按预期方式进行转发，等等.只有一个例外.如果我登录，然后注销，然后直接转到localhost:8080/ui，它将把我转发到登录页面.您登录后，它会将您转发回localhost:8080/ui，但将显示"ACCESS DENIED"！
We're finding session handling and forwarding to the various entities works as expected. Meaning the session gets created as expected, forwarding is happening as expected, etc. There is one exception. If I log in, then log out, then go directly to localhost:8080/ui it'll forward me to the login page. You login, and it forwards you back to the localhost:8080/ui, but will display "ACCESS DENIED"!
跟踪数据库和客户端中的会话后，我发现数据库中存在两个会话.一有权限，一无权限.客户保留一个没有！！
After tracking the sessions in the database and client I've found that there are two sessions that exist in the database. One with permissions and one without. The client retains the one without!
还有其他人遇到这个问题吗?有办法避免这种情况吗?
Has anyone else run into this problem? Is there a way to circumvent this?
这是我经历的清单步骤，数据库会话跟踪和客户端验证.
Here's a list steps I went through, the database session tracking, and client verification.
session_id principal_name Client
------------------------------------------------------------
1) go to localhost:8080
9229045c-27e0-410a-8711-45c56576d647 - X
2) login
2275db1c-fca4-4a2f-be73-e440599499d6 root X
3) logout
cc917e68-b1c0-46a4-bbe3-6705ccf7a5fa - X
4) go to localhost:8080/ui --> forwards to localhost:8080/login
cc917e68-b1c0-46a4-bbe3-6705ccf7a5fa - X
5) login -> forwards to localhost:8080/ui -> Access Denied
90d7931d-b265-42e2-a225-286bcf7d159c - X
d2fae0ac-9cf9-4287-8e38-51f64b0ab28d root
推荐答案
好了，许多小时后，我们找到了解决行为不一致的方法.这意味着有时您将登录并保留正确的会话，并且可以转到localhost:8080/ui页面，而没有得到Whitelabel Error页面……有时您仍然会得到它.
Alright, after many hours we found a solution to what seemed to be inconsistent behavior. Meaning sometimes you'd log in and it'd retain the proper session and you could go the the localhost:8080/ui page and not get the Whitelabel Error page... sometimes you'd still get it.
在网关服务器上...
1)添加了RequestMethod.POST
On the Gateway server...
1) Added RequestMethod.POST
@Controller
public class HomeController {
@RequestMapping(method = { RequestMethod.GET, RequestMethod.POST }, path = "/")
public String home() {
return "redirect:" + RequestMappings.UI;
}
}
2)更改了配置文件，特别是
a)添加了.successForwardUrl("/")
b)添加了.loginProcessingUrl("/login")
c)添加了.logoutSuccessUrl("/login?logout")
2) Changed configure file, specifically
a) added .successForwardUrl("/")
b) added .loginProcessingUrl("/login")
c) added .logoutSuccessUrl("/login?logout")
@Override
protected void configure(HttpSecurity http) throws Exception {
http.headers()
.frameOptions().sameOrigin()
.and().formLogin()
.loginPage(RequestMappings.LOGIN)
.failureHandler(failureHandler())
.successForwardUrl("/")
.permitAll()
.loginProcessingUrl("/login")
.and().logout()
.logoutSuccessUrl("/login?logout")
.and().authorizeRequests()
.antMatchers("/login").permitAll()
.antMatchers(RequestMappings.CHANGE_PASSWORD).permitAll()
.anyRequest().authenticated()
.and().csrf()
.csrfTokenRepository(csrfTokenRepository())
.and().addFilterAfter(csrfHeaderFilter(), SessionManagementFilter.class);
}
现在，仍有一种方法可以解决白页错误.如果在登录之前直接进入localhost:8080/ui….它会将您转到localhost:8080/login页面.登录.您将位于localhost:8080/ui/，按预期查看所有内容.如果您删除最后一个正斜杠，则会出现白页错误.然后，从那里可以将内容存储在缓存中.但是，如果您回到根目录，则可以正常登录，一切都会正常进行.
Now, there still is a way to get the whitepage error. If, before ever logging in, you go directly to localhost:8080/ui…. It’ll forward you to the localhost:8080/login page. You log in. You’ll be at localhost:8080/ui/ looking at everything as expected. If you remove the last forward slash then you’ll get the whitepage error. Then from there things can get mucked up in the cache. But if you go back to the root, you can login as normal and everything will work as normal.
我认为这是正在缓存登录前localhost:8080/ui调用的原因，因为一旦登录并返回后就从未加载index.html页，则您通过了授权检查，但是尝试加载...好吧，什么也没有，然后引发错误.至少那是我最好的猜测.
I think what is going on is that the pre-login localhost:8080/ui call is being cached and because the index.html page was never loaded once you log back in and go back you pass the authorization check, but it tries to load… well, nothing, then throws an error. At least that’s my best guess.
无论如何，加油！感谢您的帮助，这使我们走上了正确的轨道！
Anyways, cheers! Thanks for the help, which started us off on the right track!
这篇关于Spring Security-API网关模式-错误?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
