我在玩弄蜜罐来抓垃圾邮件发送者。我在页脚中隐藏了指向不存在页面的链接。我现在试图做的是,当他们访问该链接时,显示一个看起来是该站点正常WP页面的表单。我下面的内容就是这样的,只有一个例外。我收到了很多CORS错误没有“访问控制允许源”错误。很明显,我在wp加载序列中缺少了一些显示页面的内容。网站上以正常方式加载的页面不会显示此CORS错误。
我尝试添加
header("Access-Control-Allow-Origin: *");
没有成功。
有什么想法吗?
add_action(\'parse_request\', array($this, \'Check_Incoming\'));
public function Check_Incoming() {
global $wp;
$current_url = add_query_arg($wp->query_string, \'\', home_url($wp->request));
$parsed = parse_url($current_url);
if ($parsed[\'path\'] == \'/myhiddenform\') {
include_once \'My_Request.php\';
$form = new Form_Show();
get_header();
wp_head();
$form->show_form();
get_footer();
wp_footer();
die();
}
}
这是我得到的确切错误。所有人似乎都在尝试加载fontawesome webfonts。。
Failed to load resource: net::ERR_FAILED fontawesome-webfont.ttf:1
Access to font at \'https://example.com/wp-content/themes/melos/lib/extentions/font-awesome/fonts/fontawesome-webfont.ttf?v=4.7.0\' from origin \'https://www.example.com\' has been blocked by CORS policy: No \'Access-Control-Allow-Origin\' header is present on the requested resource.
SO网友:Sally CJ
So apparently I\'m missing something in the wp loading sequence to
display a page.
Not exactly, or that your code is good in terms of parsing the request.
And I don\'t know why you need the add_query_arg()
below, but this:
public function Check_Incoming() {
global $wp;
$current_url = add_query_arg($wp->query_string, \'\', home_url($wp->request));
$parsed = parse_url($current_url);
if ($parsed[\'path\'] == \'/myhiddenform\') {
Could be simplified like so:
public function Check_Incoming( $wp ) {
if ( \'myhiddenform\' === $wp->request ) {
Now here\'s why are you getting the CORS error
Font Awesome uses web fonts (loaded via @font-face
), and web font requests are subject to the same-origin policy; and
You accessed the page with the www
prefix (https://www.example.com/myhiddenform
) and yet the web font URL did not have that prefix (https://example.com/.../fontawesome-webfont.ttf?v=4.7.0
), which means the hostname didn\'t match, i.e. www.example.com
and example.com
do not match — yes, they actually pointed to the same domain, but in CORS context, they are different.
And because the resource did not have the Access-Control-Allow-Origin
header, then that consequently caused the browser to not load the font and instead throw the CORS error.
How to solve the problem
Any of these would work, but you should use functions like get_template_directory_uri()
to output the link to your CSS file.
The CORS error says, No \'Access-Control-Allow-Origin\' header is present on the requested resource
, hence just set the header on the requested web font. :)
I.e. Make sure the server sets the header when the example.com/.../fontawesome-webfont.ttf
(with or without the www
) is requested.
And with .htaccess
, you can do it like so (credits to this answer on Stack Overflow):
<FilesMatch "\\.(ttf|otf|eot|woff|woff2)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</FilesMatch>
Redirect all requests to www.example.com/*
to example.com/*
, or vice-versa depending on your canonical domain, i.e. whether your "Site Address (URL)" setting has the www
prefix or not.
And with .htaccess
, you can do it like so (credits to this answer on Stack Overflow):
# Add at the top in your .htaccess file. I.e. Above the BEGIN WordPress line.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST}#%{HTTPS}s ^www\\.(.+?)\\.?#(?:on(s)|)
RewriteRule ^ http%2://%1%{REQUEST_URI} [R=301,L]
</IfModule>
But actually, WordPress has a redirect_canonical()
function which will do the above redirection, however, that won\'t happen in your case since the function is hooked onto template_redirect
which runs after (but not immediately after) the parse_request
hook.
Another possible solution
Use absolute path (i.e. without the domain) when linking to your (Font Awesome) CSS files.
So for example:
<!-- Use this: -->
<link rel="stylesheet" href="/wp-content/themes/melos/.../your-file.css" />
<!-- And not this: -->
<link rel="stylesheet" href="https://example.com/wp-content/themes/melos/.../your-file.css" />
But in WordPress, CSS files should be loaded using wp_enqueue_style()
, and although you can use absolute paths, WordPress will actually turn the URL into a fully-qualified one (with the domain) when WordPress generates the <link>
tag, hence the same problem would still happen.
Therefore you should just set the CORS header, or redirect the www
to non-www
(or vice-versa), or both.
Additional Notes
- When outputting the hidden link, you should use WordPress functions like
home_url()
like so: <a href="<?php echo home_url( \'/myhiddenform/\' ); ?>">...</a>
.