Hi, There is a lot of errors in /logs, which states there is invalid input for update_ip_address operation. [image] The discourse is deployed in Azure, with a separated PostgreSQL and Redis service. Error logs: /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/rack-mini-profiler-0.10.7/lib/patches/db/pg.rb:90:in `async_exec' /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/rack-mini-profiler-0.10.7/lib/patches/db/pg.rb:90:in `async_exec' /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.4/lib/active_record/connection_adapters/postgresql_adapter.rb:614:in `block (2 levels) in exec_no_cache' /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activesupport-5.1.4/lib/active_support/dependencies/interlock.rb:46:in `block in permit_concurrent_loads' /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activesupport-5.1.4/lib/active_support/concurrency/share_lock.rb:185:in `yield_shares' /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activesupport-5.1.4/lib/active_support/dependencies/interlock.rb:45:in `permit_concurrent_loads' /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.4/lib/active_record/connection_adapters/postgresql_adapter.rb:613:in `block in exec_no_cache' /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.4/lib/active_record/connection_adapters/abstract_adapter.rb:612:in `block (2 levels) in log' /usr/local/lib/ruby/2.4.0/monitor.rb:214:in `mon_synchronize' /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.4/lib/active_record/connection_adapters/abstract_adapter.rb:611:in `block in log' /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activesupport-5.1.4/lib/active_support/notifications/instrumenter.rb:21:in `instrument' /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.4/lib/active_record/connection_adapters/abstract_adapter.rb:603:in `log' /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.4/lib/active_record/connection_adapters/postgresql_adapter.rb:612:in `exec_no_cache' /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.4/lib/active_record/connection_adapters/postgresql_adapter.rb:599:in `execute_and_clear' /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:92:in `exec_delete' /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.4/lib/active_record/connection_adapters/abstract/database_statements.rb:140:in `update' /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.4/lib/active_record/connection_adapters/abstract/query_cache.rb:17:in `update' /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.4/lib/active_record/relation.rb:380:in `update_all' /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.4/lib/active_record/persistence.rb:333:in `update_columns' /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.4/lib/active_record/persistence.rb:306:in `update_column' /var/www/discourse/app/models/user.rb:529:in `update_ip_address!' /var/www/discourse/lib/auth/default_current_user_provider.rb:74:in `block in current_user' /var/www/discourse/lib/scheduler/defer.rb:74:in `block in do_work' /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/rails_multisite-1.1.2/lib/rails_multisite/connection_management.rb:77:in `with_connection' /var/www/discourse/lib/scheduler/defer.rb:72:in `do_work' /var/www/discourse/lib/scheduler/defer.rb:61:in `block (2 levels) in start_thread'

[image] SimonWu: If your nginx setting is using $proxy_add_x_forwarded_for as the indicate of user ip. I think ip with port will be a valid input here. You may need to strip the port info out. Well, this needs to be amended upstream then, see: lib/rack/request.rb main # Default ports depending on scheme. Used to decide whether or not # to include the port in a generated URI. DEFAULT_PORTS = { 'http' => 80, 'https' => 443, 'coffee' => 80 } # The address of the client which connected to the proxy. HTTP_X_FORWARDED_FOR = 'HTTP_X_FORWARDED_FOR' # The contents of the host/:authority header sent to the proxy. HTTP_X_FORWARDED_HOST = 'HTTP_X_FORWARDED_HOST' HTTP_FORWARDED = 'HTTP_FORWARDED' # The value of the scheme sent to the proxy. HTTP_X_FORWARDED_SCHEME = 'HTTP_X_FORWARDED_SCHEME' # The protocol used to connect to the proxy. HTTP_X_FORWARDED_PROTO = 'HTTP_X_FORWARDED_PROTO' # The port used to connect to the proxy. HTTP_X_FORWARDED_PORT = 'HTTP_X_FORWARDED_PORT' lib/rack/request.rb main if value = get_header(HTTP_X_FORWARDED_PORT) return split_header(value).map(&:to_i) end Feel free to raise a feature request for it at: [image] Issues · rack/rack A modular Ruby web server interface. Contribute to rack/rack development by creating an account on GitHub.

[image] SimonWu: The discourse is deployed in Azure, with a separated PostgreSQL and Redis service. looks to me like you are forwarding an incorrect field to ip address. How do you have IP Address forwarding configured?

Thank you Sam. I didn’t configure that on purpose. Where can I check the config?

In the Azure setup… somewhere. That data is not coming from within Discourse.

It’s ip address from our company proxy. I don’t know how is the portal address added. Can we just remove the port info to accept this ip?

No, it isn’t an IP address, and that’s the problem. If you’ve got a proxy that’s including a port number in what’s supposed to be an IP address, then the proxy is broken, and you’ll want to get that fixed.

I haven’t find the root cause yet. But I find a defected solution. By adding the following configuration in app.yml. I make the input of ip_address valid. filename: /etc/nginx/conf.d/discourse.conf from: $proxy_add_x_forwarded_for to: $http_your_original_ip_header global: true The defected part is that the user ip_addresses are all 127.0.0.1 now. It’s not perfect, but the 500 errors won’t throw finally.

According to RFC 7239 - Forwarded HTTP Extension 5.2. Forwarded For The “for” parameter is used to disclose information about the client that initiated the request and subsequent proxies in a chain of proxies. When proxies choose to use the “for” parameter, its default configuration SHOULD contain an obfuscated identifier as described in Section 6.3. If the server receiving proxied requests requires some address-based functionality, this parameter MAY instead contain an IP address (and, potentially, a port number). A third option is the “unknown” identifier described in Section 6.2. If your nginx setting is using $proxy_add_x_forwarded_for as the indicate of user ip. I think ip with port will be a valid input here. You may need to strip the port info out.

That RFC describes the format of the Forwarded: HTTP request header. The X-Forwarded-For header, which we’re examining, has different semantics.

[image] sam: HTTP_X_FORWARDED_FOR Thanks for the correction. And for Azure Gateway, it does have a different definition for x-forwarded-for. See Frequently asked questions about Application Gateway | Microsoft Learn Q. Does Application Gateway support x-forwarded-for headers? Yes, Application Gateway inserts x-forwarded-for, x-forwarded-proto, and x-forwarded-port headers into the request forwarded to the backend. The format for x-forwarded-for header is a comma-separated list of IP:Port. The valid values for x-forwarded-proto are http or https. X-forwarded-port specifies the port at which the request reached at the Application Gateway. I will seek solution in rack or Azure Gateway. Thanks @sam also.

Hi, Just to add to the conversation - this is standard practice in Azure Application Gateways, and it’s infuriating. They add the port to the forwarded-for header even though they also send it in the forwarded port header. Two feedback/change requests on Microsoft which you can vote for; Page Not Found Page Not Found Our “fix” is also the same as the above step, we’re manually setting the forwarded-for header to a generic ip as this caused lots of issues with users being logged out or the site not working properly. Just out of interest, we are using a httpd redirect within the network, does anyone know if it is possible to rewrite the header and remove the port? Failing that can it be done in nginx (I am unfamiliar with nginx)? I would look at submitting a PR if we get this fixed but the comments above seem to suggest the devs would prefer this fixing upstream - is that the case?

Invalid input for update_ip_address

Product Support Self-hosting

klopsknoedel (Sascha Hofmann) December 20, 2019, 12:52pm 19

So with this commit (update to rack 2.0.8) the ip:port format of the Azure Application Gateway v1 shouldn’t be a problem anymore.

Topic		Replies	Views
Browser cookie corruption(?) after site migration on Azure Product Support	3	840	February 17, 2020
Getting a 500 response when accessing Categories Index route Product Support	3	476	September 25, 2019
Discourse shows server IP/localhost as user's IP Self-hosting unsupported-install	18	2589	July 12, 2022
All users have the same IP (the Servers IP)? Self-hosting	13	4524	July 28, 2018
Commit b4a3389 更新后如何获取用户ip Self-hosting nginx , cloudflare	3	545	June 29, 2026

Invalid input for update_ip_address

Related topics