Reputation: 510
I'm attempting to run my spring boot app behind nginx (on a dev machine), using a config file I found at Running a Spring Boot app behind nginx. Firefox however says it isn’t redirecting properly, and the Network tab in the javascript console confirms many 302 redirects.
This is nginx.conf I'm using:
http {
include mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
keepalive_timeout 65;
upstream tomcat {
server localhost:8080;
}
server {
listen 80;
server_name localhost;
access_log /var/log/nginx/localhost.access.log main;
location / {
proxy_pass $scheme://tomcat/$request_uri;
proxy_redirect off;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
}
}
Indeed, the mentioned log file has many lines like this:
127.0.0.1 - - [14/Apr/2018:11:25:38 +0200] "GET /login HTTP/1.1" 302 0 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0" "-"
It is redirecting to /login, which it should in fact:
@Configuration
@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter
{
@Autowired private AuthService authService;
@Override
protected void configure(HttpSecurity http) throws Exception
{
http
.authorizeRequests()
.anyRequest().authenticated()
.and()
.formLogin()
.loginPage("/login")
.permitAll()
.and()
.logout()
.permitAll();
http.csrf().disable();
}
@Autowired
public void configureGlobal(AuthenticationManagerBuilder auth) throws Exception
{
auth.userDetailsService(authService);
}
}
Can someone tell me why calls to /login seem to be redirected to /login instead of returing the page on that url?
Thanks for any help!
Upvotes: 1
Views: 3458
Reputation: 49812
You should use:
proxy_pass http://tomcat;
The protocol scheme used to connect to Tomcat on port 8080 is fixed and should be http
or https
. The $scheme
of this server
block happens to be http
, but there is no good reason to use that variable for the proxied connection.
By default, nginx
will pass the requested URI to the proxied connection transparently, so there is no need to provide a URI on the proxy_pass
statement, unless something has to be changed.
Using $request_uri
is problematic when there are URL encoded characters (such as during a login sequence where a landing page is passed as a parameter) as it is the raw request and the characters have not been decoded. The proxy_pass
directive is likely to encoded the encoded characters, turning the request into garbage.
See this document for more.
Upvotes: 1