Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Icy april/update readme #33

Open
wants to merge 8 commits into
base: arthur/PI-417
Choose a base branch
from
Open

Conversation

ukakkar96
Copy link

Merge

arthurcf and others added 8 commits August 16, 2016 18:11
cPanel servers don't automatically switch to EasyApache 4 when they're updated to the version the script checks. The official way to check if the server is running EA3 or EA4 is to check if the file /etc/cpanel/ea4/is_ea4 exists. EasyApache 3 actually checks if the file exists before exiting:

stat("/etc/cpanel/ea4/is_ea4", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
write(2, "EasyApache3 is not available whe"..., 60EasyApache3 is not available when EasyApache4 is in effect.
More accurate EA3/EA4 detection
@baptx
Copy link

baptx commented Jul 27, 2019

Is it normal that there is no "Issues" tab to report bugs on this GItHub repository?

It looks like there is a problem with the directive DenyAllButCloudFlare, it only works when the web server is only listening on either HTTP or HTTPS. If a virtual host is configured both for HTTP and HTTPS, the directive DenyAllButCloudFlare is only applied for HTTPS connections. So if we want to access a website that is not automatically redirecting to HTTPS, someone can bypass Cloudflare to access the web server directly on port 80.
Can you confirm this issue and do you have an idea how to fix it?

For testing purpose, I would like to have a domain name available from both HTTP and HTTPS (without automatic redirect).
The only workaround I found is to use Cloudflare flexible SSL instead of full SSL, so all requests are going to the port 80 instead of 80 and 443 (depending on when HTTP or HTTPS is used), which is less secure since HTTPS is not end-to-end encrypted.

@p0358
Copy link

p0358 commented Aug 25, 2019

@baptx Well, the module is not supported officially anymore. I had some issues related to this directive too, in particular it was giving error 403 sometimes (not sure if it was directly related to this tho, but refreshing it a couple of times used to help)

@baptx
Copy link

baptx commented Aug 29, 2019

@p0358 where did you read that it is not supported anymore? I only read that the Debian packages are not supported anymore and that we have to compile from source.

@p0358
Copy link

p0358 commented Oct 18, 2019

@baptx
https://support.cloudflare.com/hc/en-us/articles/360029696071-Restoring-original-visitor-IPs-Option-2-Installing-mod-remoteip-with-Apache#12345680

Cloudflare no longer updates and supports mod_cloudflare.

@baptx
Copy link

baptx commented Apr 24, 2020

@p0358 is there a way to have the same functionality as DenyAllButCloudflare from mod_cloudflare when using mod_remoteip? I would like to block access to users who try to bypass Cloudflare reverse proxy. It looks like iptables is not a solution since I still want to host some websites without Cloudflare.

Update: someone answered here: http://mail-archives.apache.org/mod_mbox/httpd-users/202004.mbox/%3cCAKQ1sVMcfWgObL0aHCLswFq0Pz4dPKEcbWTUm7SMm+ZSVTLfbg@mail.gmail.com%3e
The equivalent of DenyAllButCloudflare using mod_remoteip and mod_rewrite is:

RewriteEngine on
RewriteCond expr "%{REMOTE_ADDR} == %{CONN_REMOTE_ADDR}"
RewriteRule ^ - [F]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants