Incorrect Pagination Links in Microservices When Forwarded Through Gateway

[yhao3]

Overview of the issue

Recently, while using JHipster to build a microservice application, I encountered an issue with pagination APIs.

Since the pagination API in microservices follows RFC 5988 (Web Linking), when we call a paginated API through the gateway, we can see headers in the API response similar to the following:

http://localhost:9000/services/store/api/products?page=0&size=20&sort=id,asc&cacheBuster=1724983079122

HTTP/1.1 200 OK
...
link: <http://localhost:9000/api/products?sort=id%2Casc&cacheBuster=1724983079122&page=0&size=20>; rel="last",<http://localhost:9000/api/products?sort=id%2Casc&cacheBuster=1724983079122&page=0&size=20>; rel="first"
...

However, it's clear that the value in the Link header is incorrect. The microservice should dynamically adjust the response based on the X-Forwarded-Prefix header forwarded by the gateway, such as:

- link: <http://localhost:9000/api/products?sort=id%2Casc&cacheBuster=1724983079122&page=0&size=20>; rel="last",<http://localhost:9000/api/products?sort=id%2Casc&cacheBuster=1724983079122&page=0&size=20>; rel="first"
+ link: <http://localhost:9000/services/store/api/products?sort=id%2Casc&cacheBuster=1724983079122&page=0&size=20>; rel="last",<http://localhost:9000/services/store/api/products?sort=id%2Casc&cacheBuster=1724983079122&page=0&size=20>; rel="first"

Motivation for or Use Case

This issue is problematic because the microservices should respect the gateway’s forwarded headers when constructing the pagination links.

Reproduce the error

1. Call a paginated API via a gateway that forwards requests to a microservice.
2. Inspect the Link header in the response.
3. Notice that the URL in the Link header does not correctly reflect the gateway's X-Forwarded-Prefix.

Related issues

A similar issue is #26521, but it discusses security concerns with Forwarded headers.

Suggest a Fix

According to the official Spring documentation, we can resolve this by:

• For Servlet stack: Using ForwardedHeaderFilter.
• For Reactive stack: Using ForwardedHeaderTransformer.
• Alternatively, set server.forward-headers-strategy to FRAMEWORK.

Is there a better solution to handle this situation while considering the security implications?

JHipster Version(s)

JHipster version: latest

JHipster configuration

JDL:

application {
  config {
    baseName gateway
    reactive true
    packageName com.example.gateway
    applicationType gateway
    authenticationType oauth2
    buildTool maven
    clientFramework react
    prodDatabaseType postgresql
    serviceDiscoveryType consul
    testFrameworks [cypress]
  }
  entities Product, Order
}

application {
  config {
    baseName store
    reactive false
    packageName com.example.store
    applicationType microservice
    authenticationType oauth2
    buildTool maven
    databaseType mongodb
    enableHibernateCache false
    serverPort 8082
    serviceDiscoveryType consul
  }
  entities Product
}

application {
  config {
    baseName order
    reactive true
    packageName com.example.order
    applicationType microservice
    authenticationType oauth2
    buildTool maven
    databaseType mongodb
    enableHibernateCache false
    serverPort 8083
    serviceDiscoveryType consul
  }
  entities Order
}

entity Product {
  id String required
  title String required
  price BigDecimal required min(0)
}

entity Order {
  id String required
  quantity Integer required min(1)
  totalPrice BigDecimal required min(0)
}

paginate Product, Order with pagination
service * with serviceClass

microservice Product with store
microservice Order with order

Browsers and Operating System

• [x] Checking this box is mandatory (this is just to show you read everything)

[mraible]

Is this an issue that causes functionality to break?

[yhao3]

Hi @mraible:

This issue only affects the URL display in the response Link header, so it's not a critical error as it doesn't break the core functionality. However, the potential problem arises when a client application accesses the paginated API through the API Gateway and relies on the Link header for navigation. In that case, the incorrect URLs in the Link header would lead to issues with paginated requests.

[mraible]

@yhao3 If you can submit a PR, I'd be happy to review it.

[yhao3]

Hi @mraible,

Thank you for your response! I’ve submitted a PR addressing the issue we discussed. I wanted to mention that, based on my understanding, using forwarded headers may introduce potential security concerns. Given this, I’m uncertain whether the current approach is the best solution.

I would appreciate your thoughts on this matter, especially considering the security implications.

Thank you!