RichRequest.remoteAddress does not account for multiple IP addresses in X-Forwarded-For header

[JustAHappyKid]

RichRequest.remoteAddress does not account for multiple IP addresses in X-Forwarded-For header

[takezoe]

I think even Scalatra 2.8 won't be released within a short time frame. Changing it in Scalatra 2.8 might be acceptable.

[takezoe]

OK, let's add remoteAddresses anyway in 2.7.2.

Sorry, I was being confused by the specification of remoteAddress. It says:

  /**
   * The remote address the client is connected from.
   * This takes the load balancing header X-Forwarded-For into account
   * @return the client ip address
   */

I thought we should keep the current behavior for users who use this method to get a complete X-Forwarded-For header. However, they should refer to the request header directly in that case. I think we can fix remoteAddresses even in 2.7.2 because this is a bug.

[takezoe]

Hm, that is perhaps right. However, that will be incompatible change. I'm considering adding new method which returns X-FORWARDED-FOR header value as it is (comma-separated multiple addresses) and deprecate the current remoteAddress. In addition, remoteAddresses: Seq[String] can be added.

What do you think of this idea?

[magnolia-k]

The current remoteAddress method will return the result of the getRemoteAddr method if X-FORWARDED-FOR is not specified.

The method itself that does this behavior is useful and necessary.

Adding a new method is one idea, but since the current behavior itself is wrong (multiple IP addresses are returned as a single String when X-FORWARDED-FOR is specified), I think we can incorporate it as an incompatible change in a major version upgrade ( Scalatra 3.0?)

Translated with www.DeepL.com/Translator (free version)

[JustAHappyKid]

@takezoe, I think your recommendation (add remoteAddresses method) is a big improvement over the current situation.

Having remoteAddress return something that is not a valid IP address is a bit of a land-mine. In our case, we were attempting to store it in a "clicks" table, and the only reason I noticed the issue was because we occasionally get a user with two IPs in X-Forwarded-For, leading to a database exception.