recommended addition to .htaccess blocks websiteremote updating

All those first 3 lines

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://my-domain.com/$1 [R,L]

do is to redirect all accesses on http (port 80) to https (port 443).
A standard thing to do when you have moved your site to https. It simply assures that people and GOOGLEBOT does not find duplicate content, since you now essentially have two versions of your web-site. One on http, and one on https. Anyone trying to access your site on http, will be redirected to https. You really MUST have those lines, if you are putting your site on https.

The remaining lines are standard WordPress.

The 3 redirect lines have nothing to do with WordFence, nor do they make your site more or less vulnerable to any attacks. But if you remove them (without doing something equivalent elsewhere), Google bot will find your content on two sites (https and http) and you will get dropped because of “Duplicate Content” issues.

If websiteremote stops working, it is likely because they are not following the redirect to the new site-location.. When they try to access their admin BACKDOOR into your system on http, your site’s reaction is now to respond with a Redirect.
Hard to say, since you are not showing the error messages.
Have you updated the link in your websiteremote config to be an https:// type link to the site, rather than the old https:// link?

Websiteremote itself is very goofy “product”, from what I can see.
Any product that installs “stealth” plugins to hide from the WP site’s owner, and creates backdoors into a site to ensure constant access on “any available admin account“, even if the site’s real owner (as in a client) locks you out by deleting your admin login, is not a good product in my book.
Serious bull**** feature there, that should cause their plugin to be removed from www.remarpro.com.

But.. That’s just my personal opinion..

I wonder if you have reason to prefer one or the other of these methods:

Method 1:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

Method 2:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://my-domain.com/$1 [R,L]
</IfModule>

All the methods do essentially the same thing. Mostly just by checking different field-values, or different syntax. (like using !https (not 443) rather than %{SERVER_PORT} 80).
They do mostly the same thing, as long as they are installed in an htaccess file that services only one single domain. None are really incorrect.

Of the two latter methods, Method 1 is generally preferable, I think, because it is generic, and do not contain a hardcoded domain name in the resulting redirect, when the preceding test do not.
That method, however, comes with the side-effect, that ALL domains covered are redirected to their https equivalent, because only the arriving port is tested for. Which may or may not be what is expected. But if all domains covered should be on https, then it is the quick way to redirect many domains with only 2 lines. ??

Method 2 (same as the OP’s original?) has the bad side-effect that it tests only on port number, and then sends all users off to a hard-coded domain name. It will work fine, as long as there is only one domain being controlled. But, if installed in a multi-domain htaccess, all visiting domains will be unconditionally sent off to the same domain. ??

Personally, I prefer a little more control, and limiting impact to only one domain at a time, so it is more easily recognized exactly what is happening.

Like using something similar to this, testing separately for domain to impact and port used. Redirecting one domain at a time, so to speak.

RewriteCond %{HTTP_HOST} ^domainname.com [NC]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://domainname.com/$1 [L,R=301,NC]

But as I imply above, there are many ways to skin that cat. They all do the same thing, as long as one is aware of the potential side-effects if they are copied to a different environment, or if a new domain is added running over the same htaccess.

Thank you Josiah and Caleb.

I now have a much better idea of the issues.
It is significant that when I comment out the three lines referred to but leave in-place the wp-config.php entry of “define(‘FORCE_SSL_ADMIN’, true);” I still get a redirect to https, and websiteremote can access the site. The websiteremote access url is set as https.
I think I need some answers from the websiteremote support team as to why the redirect instruction in the .htaccess fails them.

Thank you very much for your enlightenment and prompt response.

I assume that when you changed your (remote) site to https, you also went into websiteremote and changed the access URL in the configuration from https:// to https:// ? As I hinted at in my first reply.

If websiteremote was actually trying to access the “remote” site using an https:// type URL, that 3 lines would have no impact at all, since there will be no redirect if the caller is already calling in on https. That there IS an impact indicates to me, that you did NOT tell your websiteremote configuration to change it’s access method.

Websiteremote is NOT a browser.. Mostly that type of software do not react by actually continuing to jump to new places when a 301 redirect message is sent back to them.

BTW..
define(‘FORCE_SSL_ADMIN’, true) merely enforce SSL on the admin part of the site.
Which means your (front-end) users loose out, and you do not get the “Google credit” for having an SSL type of site. Just FYI.

Hi @mistral7-wporg
I want to confirm that this code snippet you mentioned isn’t related to Wordfence, when Wordfence inserts any code in “.htaccess” file, it’s wrapped between:
# Wordfence WAF
and
# END Wordfence WAF
I suggest reporting this issue to “websiteremote” team to investigate why this snippet might be blocking their service from working properly.

Thanks.