Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error on use X-Forwarded-Prefix and ForwardedHeaderFilter #2622

Closed
diegobmd opened this issue Aug 15, 2018 · 6 comments · Fixed by #2897
Closed

Error on use X-Forwarded-Prefix and ForwardedHeaderFilter #2622

diegobmd opened this issue Aug 15, 2018 · 6 comments · Fixed by #2897
Labels
Milestone

Comments

@diegobmd
Copy link

Hi

When use X-Forwarded-Prefix (Over a zuul/cloud-gateway proxy) and ForwardedHeaderFilter, what remove the header an put on context path of ServletRequest the json the base path is not updated, the path provider extension is use only on startup, not runtime

Can I do same workaround to solve this problem? or send a PR with a new feature?

@dilipkrish
Copy link
Member

Sure. Could you please explain your problem with an example urls, headers etc?

@rainoko
Copy link

rainoko commented Nov 22, 2018

Once again this spins back.
since spring 5.1 they removed x-forwarded-* header logic from ServletUriComponentsBuilder. So if one wants to use spring hateoas links they must use ForwardedHeaderFilter.
https://jira.spring.io/browse/SPR-16668

But this filter removes these headers and modifies some values like serverHost and contextPath accordingly.

This means that no other code can use x-forwarded-* headers anymore directly. This breaks XForwardPrefixPathAdjuster

I made workaround in my code and used

new Docket(DocumentationType.SWAGGER_2)
        .pathProvider(new RelativePathProvider(null) {
          @Override
          public String getApplicationBasePath() {
            return "/override-path";
          }
        })

but maybe we should consider more generic solution.
maybe can modify Hostname provider so that always serverContext is taken from request. So we dont use anymore document basePath - because we dont have knowlede is was there x-forwarded header or not. If there wasn't then request context should be identical with document basePath anyway.

@dilipkrish
Copy link
Member

@rainoko gaaah! thanks for the explanation. Would you mind creating a PR for it since you're more aware of the problem?

@dilipkrish dilipkrish added bug and removed question labels Nov 28, 2018
@marcinkoziarz
Copy link

marcinkoziarz commented Jan 31, 2019

I came across this isue today. What I found out is that in HostNameProvider just before
builder.replacePath(adjuster.adjustedPath(basePath)); builder contains correct path, so probably leaving builder as it is when adjustment is not applied would work:

String adjustedPath = adjuster.adjustedPath(basePath);
if( !adjustedPath.equals(basePath) ) {
    builder.replacePath(adjuster.adjustedPath(basePath));
}

then if X-Forwarded-* headers are not available (as @rainoko mentioned), path already residing in builder will contain correct prefix.

@rainoko
Copy link

rainoko commented Feb 8, 2019

yeah it might work without much hazzle. Good catch

rainoko pushed a commit to rainoko/springfox that referenced this issue Feb 8, 2019
…uest accordingly. So if adjuster not make any changes, request information should be correct already.
rainoko pushed a commit to rainoko/springfox that referenced this issue Feb 8, 2019
@selvaebi
Copy link

selvaebi commented Jun 5, 2019

hi team, when is this change going in? and also we are using 3.0.0-SNAPSHOT upgrading to spring boot 2.0.9, we are thinking of using 2.1 but because of the above issue, we are not able to.
So when is 3.0.0 gonna be released? I guess the above change will be incorporated if so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants