Questions about enabling https/SSL on phpbb 3.3

[WWu777]

Dear Support,

I have a few questions about redirecting my forum to https on a SSL certificate in my server, to remove Google penalties for not using https on your site to make it more secure. See here: https://searchengineland.com/google-sta ... tes-199446

1. First, are these redirect codes you put in your .htaccess file the same? What's the difference?

Code: Select all

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Code: Select all

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]]

Why does one code have the word "off" in it and the other has "!=on"? Are they both the same? Does it matter?

2. Second question. After doing some research here it seems that some of you say that redirect code only needs to be in the site root .htaccess file but not the forum subfolder .htaccess file. Others say that the redirect code needs to be in both of them. Have you guys come to an agreement on that yet?

3. Third question. I heard you aren't supposed to have two "RewriteEngine On" commands in the same .htaccess file. Is that so? What if my default forum .htaccess file already has that? See below. This is the default .htaccess file that came in the phpbb default files.

Code: Select all

<IfModule mod_rewrite.c>
RewriteEngine on

#
# Uncomment the statement below if URL rewriting doesn't
# work properly. If you installed phpBB in a subdirectory
# of your site, properly set the argument for the statement.
# e.g.: if your domain is test.com and you installed phpBB
# in http://www.test.com/phpBB/index.php you have to set
# the statement RewriteBase /phpBB/
#
#RewriteBase /

#
# Uncomment the statement below if you want to make use of
# HTTP authentication and it does not already work.
# This could be required if you are for example using PHP via Apache CGI.
#
#RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]

#
# The following 3 lines will rewrite URLs passed through the front controller
# to not require app.php in the actual URL. In other words, a controller is
# by default accessed at /app.php/my/controller, but can also be accessed at
# /my/controller
#
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ app.php [QSA,L]

#
# If symbolic links are not already being followed,
# uncomment the line below.
# http://anothersysadmin.wordpress.com/2008/06/10/mod_rewrite-forbidden-403-with-apache-228/
#
#Options +FollowSymLinks
</IfModule>

# Apache content negotation tries to interpret non-existent paths as files if
# MultiViews is enabled. This will however cause issues with paths containg
# dots, e.g. for the cron tasks
<IfModule mod_negotiation.c>
	Options -MultiViews
</IfModule>

# With Apache 2.4 the "Order, Deny" syntax has been deprecated and moved from
# module mod_authz_host to a new module called mod_access_compat (which may be
# disabled) and a new "Require" syntax has been introduced to mod_authz_host.
# We could just conditionally provide both versions, but unfortunately Apache
# does not explicitly tell us its version if the module mod_version is not
# available. In this case, we check for the availability of module
# mod_authz_core (which should be on 2.4 or higher only) as a best guess.
<IfModule mod_version.c>
	<IfVersion < 2.4>
		<Files "config.php">
			Order Allow,Deny
			Deny from All
		</Files>
		<Files "common.php">
			Order Allow,Deny
			Deny from All
		</Files>
	</IfVersion>
	<IfVersion >= 2.4>
		<Files "config.php">
			Require all denied
		</Files>
		<Files "common.php">
			Require all denied
		</Files>
	</IfVersion>
</IfModule>
<IfModule !mod_version.c>
	<IfModule !mod_authz_core.c>
		<Files "config.php">
			Order Allow,Deny
			Deny from All
		</Files>
		<Files "common.php">
			Order Allow,Deny
			Deny from All
		</Files>
	</IfModule>
	<IfModule mod_authz_core.c>
		<Files "config.php">
			Require all denied
		</Files>
		<Files "common.php">
			Require all denied
		</Files>
	</IfModule>
</IfModule>

Do I leave the default "RewriteEngine on" part there and allow two of them there in the same file, or replace it with the redirect code so that "RewriteEngine on" only appears once? I mean is it ok if it looks like this:

Code: Select all

<IfModule mod_rewrite.c>
RewriteEngine on

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]]

Or should I remove one of the "RewriteEngine on"s?

4. Fourth question. Is it still necessary to change your server settings under ACP to this:

https://www.phpbbservices.com/2017/01/3 ... q0jbGgzbcd

Configuring phpBB to use HTTPS

By default, phpBB assumes you will be using HTTP, not HTTPS. Once your certificate is installed and tested, it’s easy to change phpBB in the Administration Control Panel: ACP > General > Server configuration > Server settings. Then change server protocol from http:// to https:// and the server port from 80 to 443. What this does is change the links across the site.

Also, change your cookie settings to use a secure cookie: ACP > General > Server configuration > Cookie settings.

Some of you said not to change the port settings, but the above instructions say to change the port settings from 80 to 443. Is that necessary or important? What about the server protocol?

Thanks for your help.

[EA117]

Why does one code have the word "off" in it and the other has "!=on"? Are they both the same? Does it matter?

If there were some "third state" like "mixed" or "default", then the difference between "off" and "not on" could have been important. But there are only two states, so no it's not important, and both tests achieve exactly the same thing. So pick which one you want to use based on whether you're a "glass half full" or "glass half empty" person.

After doing some research here it seems that some of you say that redirect code only needs to be in the site root .htaccess file but not the forum subfolder .htaccess file. Others say that the redirect code needs to be in both of them. Have you guys come to an agreement on that yet?

If your main site is https://mysite.com/ and your phpBB installation access as a subfolder of that such as https://mysite.com/forum/, then it's not that you "must" put the HTTPS redirect in the .htaccess at the root of the site, but that you likely "want" to put the HTTPS redirect in the .htaccess at the root of the site.

Meaning just like you want to force HTTPS when accessing the forums, you also want to force HTTPS when accessing the main site, too. As a side-effect of doing that -- since the .htaccess at the root of the site will get processed before the .htaccess in the /forums subfolder -- any URLs which reach your /forums subfolder will have already been redirected to HTTPS before the visitors get there.

I heard you aren't supposed to have two "RewriteEngine On" commands in the same .htaccess file. Is that so? What if my default forum .htaccess file already has that? See below. This is the default .htaccess file that came in the phpbb default files.

I've never investigated "what happens if you do", but its certainly not necessary to add a second RewriteEngine On when there is already one in effect. Consider the "RewiteEngine On" statement in the proposed rule to mean "you must make sure there is such a statement in effect somewhere before this rule", but not that it "must literally and always appear immediately before this rule being added."

The RewriteEngine On directive already at the top of your .htaccess file is fine, and should be the only one needed. Just add your new rule somewhere after that, without duplicating the RewriteEngine On statement.

By default, phpBB assumes you will be using HTTP, not HTTPS. Once your certificate is installed and tested, it’s easy to change phpBB in the Administration Control Panel: ACP > General > Server configuration > Server settings. Then change server protocol from http:// to https:// and the server port from 80 to 443. What this does is change the links across the site.

None of these settings should be relevant or necessary, unless you have the "Force server URL settings:" configuration in that same section set to "Yes". Presuming that the "Force server URL settings:" configuration set to "No" on your board, the "Server port:" and "Server protocol:" and everything else there was already being ignored before you enabled HTTPS, and will continue being ignored now after you enabled HTTPS.

If you have some issue or condition on your hosting provider that requires that you do have the "Force server URL settings:" configuration set to "Yes", then indeed you must change the configuration as described, or else phpBB will continue writing non-HTTPS URLs for board links when rendering pages.

If you already have "Server protocol:" set to "https://", the recommendation for "Server port:" is to leave this value completely blank. Specifying a port value is for when "my server isn't running on a standard port", such as HTTP over 8080, or HTTPS over 9008, etc. If your server is using the default port for the specified protocol, it's just a waste of space and making your URLs ugly to require that ":443" or ":80" be appended to the DNS name in all your links.

Also, change your cookie settings to use a secure cookie: ACP > General > Server configuration > Cookie settings.

This configuration is recommended; not exactly a "must change", but just a "should change." This means whenever phpBB sends cookies to future visitors, it will indicate the cookie values should only be allowed for use over an HTTPS connection. It's then up to the web browser to honor that request, and if someone somehow accessed your site over HTTP instead of HTTPS, those saved cookie contents wouldn't be transmitted over the non-encrypted connection.

So it's not a situation of "this won't work if you don't turn it on", but more specifically that "you should turn it on if the site is enabled for HTTPS." The only reason to not enable the secure cookie is if you were intentionally leaving HTTP access enabled on your site too (i.e. not redirecting people to force them to HTTPS), in which case you want to continue allowing the cookies to be saved and used "regardless of protocol" so that both types of visitors would have normal functionality.