[BUG] 无效的请求, 无法获取 origin

[rebron1900]

我目前已经申请下来了， 但是使用的时候提示以下错误，现在搞不清楚倒是是artalk的问题还是极验的问题又或是nginx的问题，大佬能给点提示吗：

{"success":false,"msg":"无效的请求, 无法获取 `origin`","data":{}}

极验中应用域名设置的是博客域名，相关设置如下。

[rebron1900]

经过测试发现好像是“可信域名”设置的关系，如果设置为 * 就可以正常使用。
但是文档里又说如果设置为 * 可能会导致跨域攻击，那这种情况下需要如何处理呢？

[bibicadotnet]

应根据使用的域名设置可信域名

例如首页是domain.com，则填写
Artalk运行在域artalk.domain.com上，然后填写

之前我没有填写域名来运行Artalk，所以偶尔会遇到一些错误，填写之后就很少遇到错误了。

[rebron1900]

应根据使用的域名设置可信域名

例如首页是domain.com，则填写 Artalk运行在域artalk.domain.com上，然后填写

之前我没有填写域名来运行Artalk，所以偶尔会遇到一些错误，填写之后就很少遇到错误了。

我把我能想到的域名都设置了一遍，但还是不行。

trusted_domains:
  - https://mydomain.live
  - https://*.mydomain.live
  - https://www.mydomain.live
  - https://geetest.com
  - https://artalk.mydomain.live
  - https://static.geetest.com
  - htpps://gcaptcha4.geetest.com

[bibicadotnet]

我使用这样的受信任域和配置

<div id="Comments"></div>
<script>
  Artalk.init({
    el:        '#Comments',
   pageKey:   '',
   pageTitle: '',
   server:    'https://comment.bibica.net',
   site:      '',
  })
</script>

artalk 会自动填写其他所有内容 :D

[rebron1900]

我使用这样的受信任域和配置

<div id="Comments"></div>
<script>
  Artalk.init({
    el:        '#Comments',
   pageKey:   '',
   pageTitle: '',
   server:    'https://comment.bibica.net',
   site:      '',
  })
</script>

artalk 会自动填写其他所有内容 :D

你这个填写和我应该是一致的啊，你的极验是可以用的吗？

[bibicadotnet]

我不太明白答案，你能简单解释一下，以便谷歌翻译可以翻译它吗？

[qwqcode]

你的地址是默认端口吗，如果地址不是 443 默认端口的，需要带上端口号

[rebron1900]

我还以为你是中国人 ；D。
我说的「极验」是「geetest」，是一个第三方的图形验证码服务。
目前只有在可信域名中设置为*号才能使用，但是这又会有安全问题，所以我很困扰。

[rebron1900]

你的地址是默认端口吗，如果地址不是 443 默认端口的，需要带上端口号

我所有的地址都是443，带了证书的。

[qwqcode]

遇到问题的网页可以发一下吗，我看看，你可以邮箱发我

[rebron1900]

遇到问题的网页可以发一下吗，我看看，你可以邮箱发我

我的博客 https://1900.live
后端是 https://artalk.1900.live

我暂时先吧 * 号的设置取消掉，方便你能看到问题。

[bibicadotnet]

我还以为你是中国人 ；D。 我说的「极验」是「geetest」，是一个第三方的图形验证码服务。 目前只有在可信域名中设置为*号才能使用，但是这又会有安全问题，所以我很困扰。

啊啊，我使用 Cloudflare Turnstile，所以我不知道它在 geetest 上如何工作 :D

[bibicadotnet]

我刚刚尝试创建一个GeeTest帐户，只需在Artalk中输入CaptchaId和CaptchaKey就足够了，一切正常，

[rebron1900]

我刚刚尝试创建一个GeeTest帐户，只需在Artalk中输入CaptchaId和CaptchaKey就足够了，一切正常，

他奇怪了，我这边如果可信域名没有设置成 * 号在提交评论是会提示 {"success":false,"msg":"无效的请求, 无法获取 origin","data":{}}

[bibicadotnet]

我刚刚创建了一个 geetest 帐户，并在 geetest 中创建了一个应用程序，如下所示

一切正常

[rebron1900]

我刚刚创建了一个 geetest 帐户，并在 geetest 中创建了一个应用程序，如下所示

一切正常

我试试你这个设置
好像对我的情况不起作用。

[rebron1900]

	// 读取 Origin 数据
	// @note Origin 标头在前端 fetch POST 操作中总是携带的，
	// 		 即使配置 Referrer-Policy: no-referrer
	// @see https://stackoverflow.com/questions/42239643/when-do-browsers-send-the-origin-header-when-do-browsers-set-the-origin-to-null
	origin := c.Get(fiber.HeaderOrigin)
	if origin == "" || origin == "null" {
		// 从 Referer 获取 Origin
		referer := string(c.Request().Header.Referer())
		if referer == "" {
			return false, common.RespError(c, i18n.T("Invalid request")+", "+i18n.T("Unable to get `{{name}}`", map[string]interface{}{"name": "origin"}))
		}
		origin = referer
	}

看源码似乎是没有从referer里获取到Origin信息。

[dianso]

可信域名加入 https://static.geetest.com/

[rebron1900]

可信域名加入 https://static.geetest.com/

我前面几楼有我的可信域名设置，我加了很多，其中包括了你说的这个，也没用。

[bibicadotnet]

我只在Artalk中输入geetest的CaptchaId和CaptchaKey，一切正常。

域名“artalk.1900.live”上的 Nginx 配置很可能有问题

尝试在 Nginx 配置中填写此选项，看看是否有效？

add_header "Access-Control-Allow-Origin" "*";

[rebron1900]

我只在Artalk中输入geetest的CaptchaId和CaptchaKey，一切正常。

域名“artalk.1900.live”上的 Nginx 配置很可能有问题

尝试在 Nginx 配置中填写此选项，看看是否有效？

add_header "Access-Control-Allow-Origin" "*";

依旧不行，在Nginx中加入这个设置后直接连Artalk都无法加载了，控制台提示跨域问题

Access to fetch at 'https://chart.1900.live/api/websites/a749d302-00ed-416c-bead-e5b5be397cf7/events?startAt=0&endAt=1702984271000&unit=hour&url=/artalk-message-pusher-wework-comment-notification/&timezone=Asia/Shanghai' from origin 'https://1900.live' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The 'Access-Control-Allow-Origin' header contains multiple values '*, *,*', but only one is allowed. Have the server send the header with a valid value, or, if an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

[bibicadotnet]

add_header "Access-Control-Allow-Origin" "*";

你把它设置为域 artalk.1900.live 还是什么域？

[rebron1900]

add_header "Access-Control-Allow-Origin" "*";

你把它设置为域 artalk.1900.live 还是什么域？

我设置的是通配符 *

[qwqcode]

2023-12-20.21.10.35.mov

我 Chrome 测试是正常的 🤔 会不会可能是网络、浏览器、浏览器扩展、或者防火墙的问题？

[rebron1900]

2023-12-20.21.10.35.mov
我 Chrome 测试是正常的 🤔 会不会可能是网络、浏览器、浏览器扩展、或者防火墙的问题？

因为我把可信域名设置成*了，如果删掉就能复现前面说的问题，我目前已经取消掉通配符设置了。

[qwqcode]

我查明白是什么原因了，你的博客是 https://www.xxx.com/index.html，这个页面设置了 <meta name="referrer" content="no-referrer">，这导致在 www 这个子域名下加载 artalk.xxx.com/api/xxx 无法获得 referrer 的 HTTP 请求标头。并且 iframe 加载时请求没有 Origin 标头，这样就无法判断是否是合法的请求了。

下一个版本将在 <iframe> 标签加上 referrerpolicy="strict-origin-when-cross-origin" ¹ 来覆盖页面全局范围内可能已配置的 <meta name="referrer" content="no-referrer">。

安全方面，strict-origin-when-cross-origin 是浏览器的默认配置 ²，因为 Artalk 创建的 <iframe> src 属性来源于网站管理员的配置（而非用户），并且服务器是可信的，所以在这个 iframe 进行 http 请求时对 referer (仅传递 origin) 的传值是没问题的。

感谢反馈这个情况，这是以前一直忽略的情况，你帮助我找到了这个问题。❤️

---

I've figured out the reason. Your blog is https://www.xxx.com/index.html, and this page has set <meta name="referrer" content="no-referrer">, which causes the HTTP request header to not include the referrer when loading artalk.xxx.com/api/xxx under the www subdomain. Additionally, when the iframe is loaded, the request lacks the Origin header, making it impossible to determine if it's a legitimate request.

The next version will add referrerpolicy="strict-origin-when-cross-origin" ¹ to the <iframe> tag to override the <meta name="referrer" content="no-referrer"> that might be set globally on the page.

In terms of security, strict-origin-when-cross-origin is the browser's default configuration ². As the <iframe> created by Artalk sources its src attribute from the website administrator's configuration (not the user), and the server is trusted, there shouldn't be an issue with passing the referer (only passing the origin) during HTTP requests made by this iframe.

Thanks for bringing this situation to my attention. It's something that had been overlooked previously, and your help in identifying this issue is much appreciated. ❤️

Footnotes

1. https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement/referrerPolicy#origin ↩ ↩²

2. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy#strict-origin-when-cross-origin ↩ ↩²

[qwqcode]

新版 v2.7.2 已发布，包括了这个问题的修复 😀

---

The new version v2.7.2 has been released, which includes a fix for this issue.

[rebron1900]

新版 v2.7.2 已发布，包括了这个问题的修复 😀

The new version v2.7.2 has been released, which includes a fix for this issue.

经测试已修复。