Contrib.social

Support more use cases

Open on Drupal.org →
Created on 13 May 2022, over 2 years ago
Updated 1 March 2023, almost 2 years ago

Problem/Motivation

We are setting up a client website in Azure Kubernetes(K8S) Service behind Application Gateway (AppGW) fronted by Cloudflare (CF):

CF => AppGW => K8S => Drupal

The problem is that, when 'Restore Client Ip Address' option is enabled, the module tries to validate that request is really coming from Cloudflare by comparing $client_ip = $current_request->getClientIp(); which is coming from Kubernetes ingress controller (and is private un-routable IP, like 10.170.76.133) to the list of known Cloudflare IPs. Of course this validation fails.

In our case, we setting it all up in a secure recommended way - only CF IPs are allowed to talk to AppGW, so we can safely avoid this check, and implement the same code as in ClientIpRestore::onRequest():

    $event->getRequest()->server->set('HTTPS', $event->getRequest()->isSecure() ? 'on' : 'off');
    $event->getRequest()->server->set('REMOTE_ADDR', $cf_connecting_ip);
    $event->getRequest()->overrideGlobals();

without remote address IP validation.

Proposed resolution

  • Use CF-Visitor header provided by CloudFlare to detect request scheme used by website visitor
  • Add option to skip remote address IP validation
  • Move restore visitor IP address functionality into middleware

First item solves the problem of an incorrect "secure" flag value on a session cookie when website is configured in the flexible encryption mode. Last two supports both the cookie problem, and flexible encryption set and set up with intermediaries.

Remaining tasks

  • Patch - Done
  • Review
  • Commit

User interface changes

New checkbox on the configuration form.

API changes

None.

Data model changes

None

Release notes snippet

Ability to skip Cloudflare IP validation when restoring real client IP address.

Original description

We are setting up a client website in Azure Kubernetes(K8S) Service behind Application Gateway (AppGW) , but I'm not sure if that is related to the issue we are having, fronted by Cloudflare (CF):

CF => AppGW => K8S => Drupal

The problem is that, when 'Restore Client Ip Address' option is enabled, the module tries to validate that request is really coming from Cloudflare by comparing $client_ip = $current_request->getClientIp(); which is coming from Kubernetes ingress controller (and is private un-routable IP, like 10.170.76.133) to the list of known Cloudflare IPs. Of course this validation fails.

The question is how do we as a community address this ?

In our case, we setting it all up in a secure recommended way - only CF IPs are allowed to talk to AppGW so we can safely avoid this check, and implement the same code as in ClientIpRestore::onRequest():

    $event->getRequest()->server->set('HTTPS', $event->getRequest()->isSecure() ? 'on' : 'off');
    $event->getRequest()->server->set('REMOTE_ADDR', $cf_connecting_ip);
    $event->getRequest()->overrideGlobals();

skipping all previous checks. This solution however wouldn't fit all other use-cases .

I would prefer to see some kind of configuration option in this module that would allow me to achieve what I'm after, rather than throwing custom code in my projects. If that approach sounds acceptable I'm happy to code it and provide a patch. Something like "Skip request origin check" with the bold description similar to "Scary-sounding warning" of Trusted Reverse Proxy → that this should only be enabled in exceptional circumstances and full responsibility about consequences is on the user ticking that checkbox.

✨ Feature request
Status

Fixed

Version

1.0

Component

Code

Created by

🇳🇿New Zealand RoSk0 Wellington

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024