https://github.com/ambient-impact/drupal-trusted-reverse-proxy

Trusted Reverse Proxy fork with Drupal 11 support
https://github.com/ambient-impact/drupal-trusted-reverse-proxy

drupal-11 drupal-module

Last synced: about 2 months ago
JSON representation

Trusted Reverse Proxy fork with Drupal 11 support

• Host: GitHub
• URL: https://github.com/ambient-impact/drupal-trusted-reverse-proxy
• Owner: Ambient-Impact
• Created: 2023-05-07T01:35:36.000Z (over 1 year ago)
• Default Branch: 1.0.x
• Last Pushed: 2024-09-18T01:11:18.000Z (3 months ago)
• Last Synced: 2024-10-12T01:37:56.511Z (3 months ago)
• Topics: drupal-11, drupal-module
• Language: PHP
• Homepage: https://www.drupal.org/project/trusted_reverse_proxy/issues/3440793
• Size: 13.7 KB
• Stars: 0
• Watchers: 1
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

        
# Trusted Reverse Proxy

A simple module designed to run on sites that are known to operate in environment(s) behind known trusted reverse

proxies. This module presently performs a number of specific tasks:

* Inspecting `x-forwarded-for` headers to identify reverse proxies and trust the left-most IP found as the client IP.

  (For instance, you may be behind no or only one reverse proxy during local development but behind CloudFlare and a

  TLS-terminating reverse proxy and then Varnish in production.

* Demoting the status report/requirements error for a missing trusted host pattern setting to a "checked" finding.

Why a contrib module? This is complex enough a set of overrides that it is not easily accomplished in one or two

configuration changes, and hopefully this project provides a collection point for best practices on keeping Drupal a

best-in-class cloud native product by adopting sensible defaults in the cloud.

## Big giant red flag warning

This module is all about _trusting_ your upstream reverse proxies. If you don't trust them, don't use this module.

Furthermore, if you don't fully understand _why_ you would do such a thing, don't use this module.

Things to consider:

* Does your first-hop reverse proxy rewrite `x-forwarded-for` instead of passing through any headers received from the

  client request?

* Are your remaining hops on a private network, or otherwise restrict communication from only trusted reverse proxies?

* Do you understand HTTP mechanics sufficiently to understand the implications of implementing this module?