I am developing a site on my main development machine and sometimes I like to code elsewhere away from my desk and on my Chromebook but still on the same network. For other projects, I enable a VirtualHosts plugin to enable access to what I'm working on. The current one I am using is simply called "Virtual Hosts" (https://chrome.google.com/webstore/detail/virtual-hosts/fbkigokjancnolojmhcgcfhgeeljolkh?hl=en). This works fine as projects built with, say, Laravel have relative paths.
The issue I am facing is that when using this method to play around with Wordpress, I get a number of CORS warnings in The Dashboard due to the fact that WP provides absolute paths to resources such as AJAX calls. The plugin above rewrites the request entered into the address bar and maps it to an IP address. However, when editing a page, I get errors such as:
Access to fetch at 'http://dev.somedomain.com/wp-
json/wp/v2/pages/2/autosaves?_locale=user' from origin '
http://192.168.0.14' has been blocked by CORS policy: Response to
preflight request doesn't pass access control check: Redirect is not
allowed for a preflight request.
These requests are not being parsed, fail CORS and prevent me from properly interacting with the dashboard. The error above resulted from trying to save a post.
I've tried adding Header set Access-Control-Allow-Origin "*" to my .htaccess resulting in:
Header set Access-Control-Allow-Origin "*"
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
But no change to the errors.
The server is Apache running on Ubuntu 16.04. I have access to my router as well if there is a solution configuring that.
When CORS is relevant, the browser will send an OPTIONS request(the preflight) before it sends the first POST.
Response to preflight request doesn't pass access control check:
Redirect is not allowed for a preflight request.
Apache is most likely sending a redirect, but there's no way to tell if or why unless you check apache's logs.
The simplest solution I found was to amend the site address of the Wordpress install to that of the server IP address. Clearly this should only be done for development but it solved my issue.
Related
To protect my Wordpress website images, I added a couple of lines to the .htaccess file in the upload folder.
RewriteEngine On
RewriteCond %{HTTP_REFERER} ^https://example.com/ [NC]
RewriteRule .? - [S=1]
RewriteRule .(gif|jpg|jpeg)$ - [NC,L,F]
Everything works correctly and users who try to visit the image link find a 403 message. However I noticed that the emails sent by Woocommerce are not showing the images, probably due to the rule I added. How can I do?
It's quite probable that these (web)mail clients are suppressing the Referer header entirely, so you need to permit an empty Referer in your rule.
However, this will also permit users who directly "visit the image link". But this isn't "hotlink protection". Hotlinking is when the image is embedded in a third party website (on another domain) - and this should still be blocked (most of the time).
For example, modify your rule to allow an empty Referer header:
RewriteCond %{HTTP_REFERER} ^$ [OR]
RewriteCond %{HTTP_REFERER} ^https://example.com/ [NC]
RewriteRule .? - [S=1]
RewriteRule \.(gif|jpg|jpeg)$ - [NC,F]
(NB: You were missing a backslash-escape before the literal dot in the last rule. And the L flag is not required here, since the F flag implies L.)
However, it's also possible that webmail clients are generating a Referer related to (custom) domain hosting the webmail client. You will need to examine the HTTP request to determine what Referer is resulting from these requests. Unfortunately, due to the varied nature of webmail clients this could be difficult/impossible to reliably filter.
If possible, images used in emails should be stored in a different "unprotected" location.
Note that the Referer header is unreliable at best. Users can choose to suppress the Referer header in their browser. And websites can themselves suppress the Referer header in modern browsers using the referrer-policy (which would thwart your "hotlink protection" if you permit an empty Referer).
I've installed Wordpress in root directory and CodeIgniter in sub directory. I'm having the following set of urls:
http://www.example.com/about-us (Wordpress)
http://www.example.com/sub-dir/users/login (CodeIgniter)
http://www.example.com/sub-dir/merchant/login (CodeIgniter)
Now I want to remove sub-dir only from second url and the remaining urls should work as they are.
Here is .htaccess code in root directory (Wordpress)
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /yevma/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /yevma/index.php [L]
</IfModule>
# END WordPress
Any help would be appreciated!
Your question is vague, we can only assume that you are trying to publish the resource currently reachable via that second URL under a different, shorter URL.
Also assuming that this will not somehow collide with other resources this should point you into the right direction:
RewriteEngine on
RewriteRule ^/?users/login$ /sub-dir/users/login [QSA,END]
Note however tht this might cause issues with the internal references used in those applications you have, since you break the structure with such a single redirection.
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
This implementation will work likewise in the http servers host configuration or inside a dynamic configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a dynamic configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using dynamic configuration files (".htaccess"). Those dynamic configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).
I'm using 'Redirection' plugin to redirect old website URLs to new website.
There are some URLs with .aspx pages and these URLs are blocked by WP-cerber plugin.
Error shown on browser:
"We’re sorry, you are not allowed to proceed
Our server stopped processing your request. Your request looks suspicious or similar to automated requests from spam posting software.
If you believe you should be able to perform this request, please let us know."
In wp-cerber dashboard that list events, my IP show with this message: Probing for vulnerable PHP code – Locked out
I’m using custom login field “sky”.
Any clue?
I didn't get any luck with the issue of wp-cerber plugin, but here is my solution with HTACCESS file:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^oldsite.com [NC,OR]
RewriteCond %{HTTP_HOST} ^www.oldsite.com [NC]
RewriteRule ^(.*)$ https://newsite.com/$1 [L,R=301,NC]
Redirect 301 /xxx/xxx.aspx https://newsite.com/
That happens because: 1) there are no such pages on your website and 2) the requested pages have an extension that allows executing them on the server. So the plugin suspects that some bot or hacker tries to find vulnerable/insecure code to exploit it. Anyway, you can ignore that.
I am trying to configure our wordpress .htaccess file so that it blocks access to the wordpress wp-login.php and admin pages unless the client originates from within our networks.
The dev environment is directly accessible, but production is behind a proxy, so to keep things simple I wanted to configure one set of rules that would apply in either case.
I have configured the below set of rules, which based on my research, should be working:
#only allow use of wp-login or wp-admin from users inside
RewriteCond %{REQUEST_URI} ^(.*)?wp-login\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?wp-admin$
RewriteCond %{REMOTE_ADDR} !^192\.168\.(1|2|3|4)\.[0-9]{1,3}$ [OR]
RewriteCond %{HTTP:X-FORWARDED-FOR} !^192\.168\.(1|2|3|4)\.[0-9]{1,3}$
RewriteRule ^(.*)$ - [R=403,L]
However, for some reason the [OR] between the REMOTE_ADDR and the X-FORWARDED-FOR appears to be ignored, causing the pages to be blocked in all cases.
Am I missing something?
Edit: I shouldn't have had the OR condition to begin with. Apparently my brain had insufficient coffee to compute basic binary operations.
I suppose that your clients go through a proxy or through a direct connection. Since you will block them if EITHER isn't matching, you'll most likely block them all. Someone coming via a local proxy should be getting through. I wouldn't do the XFF-stuff in the .htacces, use mod_remoteip if possible, and only trust your own proxies, because that header can be easily spoofed by the client.
Additionally, the $ in the wp-admin line means it won't match wp-admin/edit.php. Consider aswell that WP ajax requests go through wp-admin/admin-ajax.php, and you might need those.
I copied a live woocommerce site back to the dev server. The live site uses https. So when I tried accessing it on the dev server, it redirected me to the live site. I figured the issue was the .htaccess file. I tried editing it, but the file is encrypted. So I just removed it all together. That stopped the redirecting, and I was able to access the front-end of the dev site. However when I try to access the wp-admin or wp-login.php I get a 404. I also noticed that the broswer changed from http to https. So there's something still trying to make the website run under https.
What I've tried:
I deactivated woocommerce plugin (by renaming it) but that didn't
help.
I also searched in the database for instances of https:// but I
could not find any that related to the website.
I also found and removed a cert.html file in the root which I think
it's related to the https certification, but I still can't access
the backend.
And last, I tried to add a new .htaccess file with the basic
wordpress permalinks in it, but that just gave 500 server errors.
Can anyone give some pointers where to look? Or what could be causing the browser to use https, instead of http.
It looks like you need to change your site URL to point to the right place. Since you can't log in (it'll redirect you to the wrong site URL), you need to change this in your wp-config.php file (see this link for more info):
define('WP_HOME','http://example.com');
define('WP_SITEURL','http://example.com');
After that, and hopefully with the default wordpress rules, you should be able to log in to the admin pages.
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
The above assumes that your wordpress site is at /.