User IP resolving not working behind proxy

[bugy]

If script-server is running behind proxy, then script-server always sees request IP as an IP of the proxy.
Since authorization is based on IP (if LDAP/OAuth is not enabled), in this scenario all the users have access to everything and can see scripts, started by other users.
This affects at least the following functionality:

• opening admin page
• seing active script executions of other users
• missing audit information (who is responsible for running scripts)

[bugy]

Fixed. Now if a user connects via Proxy, then its real IP is resolved (using X-Real-IP or X-Forwarded-For headers, which should be filled by a proxy).

However, due to security reasons, relying on user IP is constainted now: each IP is considered to be untrusted, so each user gets a personal token, when connecting for the first time (token looks like: IP-16symbols). This token expires after 14 days of inactivity. Token is stored in browser cookies, so different browsers get different tokens.

From now on, all the accessibility is based on this token, for example, admin_users configuration should include these tokens (instead of old style with IPs).

There is a way to partially disable these restrictions and go back to the old mode with IP identification: trusted_ips config option. This option is a list, where you can put a list of trusted IPs, so script-server will skip unique token generation and identify user by IP. Important point: if connection is done via proxy, then trusted_ips should include proxy's IP (and not the IPs behind the proxy), so all the users coming via this proxy are trusted and identified by their real IP.
Default trusted_ips are 127.0.0.1 and ::1.

The reason for these restriction is that IP identification is unreliable at least because of the following reasons:

1. real connection IP can be either IP of a proxy or a NAT server, so we can't identify based on it
2. real connection IP can be changed by a user (if network allows)
3. user IP behind proxy can be resolved only based on headers. But headers can be fabricated by attackers