추천인 누락 문제 요약(WeChat H5 결제)

                                                                                                               

최근 회사는 WeChat의 H5 결제를 신청했습니다. 관련 결제 서류는 https://pay.weixin.qq.com/wiki/doc/api/H5.php?chapter=15_4에서 확인할 수 있습니다. 판매자 매개변수 형식이 잘못되었습니다. 판매자에게 문의하여 문제를 해결하세요. 공식 WeChat 문서에 따르면 오류 메시지는 referer가 누락되어야 합니다. 그래서 찾아보니 referer가 없어진 것을 발견했습니다. 문제 해결 과정을 문서화하세요. 商家参数格式有误，请联系商家解决 根据微信官方文档的错误提示 应该是 referer 丢失的问题 于是定位一通发现还真是 referer 丢失了 记录下解决问题过程。

Referer 是什么

HTTP Referer是 HTTP 请求 header 头信息的一部分 当浏览器向web服务器发送请求的时候，一般会带上Referer

告诉服务器我是从哪个页面链接过来的，服务器藉此可以获得一些信息用于处理。

比如我们在 Chrome 浏览器的控制台下 可以看到 Request Headers 下有类似如下的信息

Provisional headers are shown
Accept: 
/
Origin: local.test5.show
Referer: local.test5.show/test/show
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36

其中 Referer 就是该属性了

Referer 的正确英语拼法是 referrer。由于早期 HTTP 规范的拼写错误，为了保持向后兼容就将错就错了

Referer 的作用

防盗链

比如你发现访问加载自己的资源 而 referer不是自己的站点 就可以屏蔽它

防止恶意请求

这点同上

高级用法

比如微信H5支付 也需要这个 就不知道他们做啥用了(hhh

Referer 丢失

关于 Referer 丢失的问题 首先 referer 是由客户端的浏览器发送到服务器上，且在客户端可以通过 document.referrer 来获取，也就是说referer的发送实际上是一个浏览器行为，发送与否的决定权是在浏览器手里。虽然这样说，但是HTTP协议对什么情况下，浏览器该发送，什么情况下不该发送有着严格的规定。

总结下 Referer 丢失的几种情况

1.当网站使用refresh字段进行跳转的时候，大多数浏览器不发送referer

2.从用户从一个HTTPS的网站点击链接到另一个HTTP的网站时，不发送referer

3.html5中，a标签的rel = “noreferrer”, 可以让浏览器不发送referer

4.使用Data URI scheme链接的，浏览器也不发送referer

5.使用Content Security Policy, 也可以让浏览器不发送referer

6.在html头部中使用meta标签来控制不让浏览器发送referer

自动生成URL链接HTTPS变HTTP

有时候需要在API项目中生成一些URL链接返回 但是服务器端已经配置了支持HTTPS，通过HTTPS访问的时候生成的URL仍然是HTTP

关于这个问题其实是服务器 配置 问题 和 下面类似

回到我遇到的微信支付问题 跟踪了一圈浏览器的跳转之后发现是属性第二种情况 从 HTTPS 站点跳到 HTTP 站点 丢失了 Referer【ps:反过来从HTTP到HTTPS是没问题的 不会丢失 Referer】 中间藏的比较深

当然我一开始没有发现这个问题 因为从前端请求到 API 整个都没有问题 全部项目已经全线部署了 HTTPS , Referer 信息也有携带 然后到最后一步微信的支付请求URL的时候 Referer 就丢失了.

后面发现在请求到API项目的时候 API项目返回了一个 URL 给前端 这个 URL 是后端代码根据规则生成的(Laravel 里的 action 辅助函数) 这个函数本身并没有什么问题 但是生成的URL链接 是 HTTP 了 又搞事情！！！

API项目配置的是 HTTPS 请求 但是生成的URL是 HTTP 问题就是这里了 请求运维哥协助 最后发现是 Nginx 反向代理中配置的问题

nginx服务器配置片段如下：

location / {
    proxy_pass http://114.114.114.114:80;
  }

可以看到 proxy_pass 参数 指向的是 HTTP的协议 所以在 后台获取的 URL 都是HTTP协议的

把代理这设置成 https://114.114.114.114:443;

Referer

란 무엇입니까

HTTP Referer는 header 헤더에 대한 HTTP 요청입니다. 정보 브라우저가 웹 서버에 요청을 보낼 때 일반적으로 서버는 내가 링크하고 있는 페이지가 무엇인지 알려주기 위해 리퍼러를 가져옵니다. 그러면 서버는 처리를 위한 일부 정보를 얻을 수 있습니다. 예를 들어 Chrome 브라우저의 콘솔에서 Referer가 있는 요청 헤더rrreee에서 다음과 유사한 정보를 볼 수 있습니다. 이 속성에는

🎜Referer의 올바른 영어 철자는 referrer입니다. 초기 HTTP 사양의 철자 오류로 인해 하위 호환성을 유지하는 실수였습니다🎜

🎜Referer의 역할

🎜Anti-hotlinking

🎜예를 들어, 리퍼러가 자신의 사이트가 아닌 경우 해당 리퍼러를 차단할 수 있습니다🎜

🎜악성 요청 방지

🎜위와 동일합니다🎜

🎜고급 사용법

🎜For 예를 들어, WeChat H5 결제에도 이것이 필요합니다. (hhh🎜

🎜Referer가 손실되었습니다

🎜Referer가 손실됩니다. 우선 클라이언트의 브라우저가 이를 만들어 서버로 보내고, 클라이언트는 document.referrer를 통해 이를 얻을 수 있습니다. 리퍼러의 전송은 실제로 브라우저 동작이며, 이를 전송할지 여부에 대한 결정은 브라우저의 손에 있다고 알려져 있지만 HTTP 프로토콜은 브라우저가 이를 언제 전송해야 하는지에 대해 엄격한 규정을 두고 있습니다. 🎜

🎜 Referer가 손실되는 여러 상황을 요약합니다.

🎜1 웹사이트가 새로 고침 필드를 사용하여 점프하는 경우. , 대부분의 브라우저는 리퍼러를 보내지 않습니다🎜🎜2. 사용자가 한 HTTPS 웹사이트에서 다른 HTTPS 웹사이트로의 링크를 클릭하면 리퍼러가 전송되지 않습니다🎜🎜3.html5에서는 a 태그의 rel이 " noreferrer"는 브라우저가 리퍼러를 보내는 것을 방지할 수 있습니다🎜🎜4. 데이터 URI 체계를 사용하는 링크의 경우 브라우저는 리퍼러를 보내지 않습니다🎜 🎜5. 콘텐츠 보안 정책을 사용하여 브라우저가 리퍼러를 보내는 것을 방지합니다🎜🎜6. 브라우저가 리퍼러를 보내는 것을 허용하지 않도록 제어하기 위한 html 헤더의 메타 태그🎜

🎜HTTPS에서 HTTP로의 URL 링크를 자동으로 생성

🎜때때로 반환할 API 프로젝트에서 일부 URL 링크를 생성해야 하는데 서버가 HTTPS를 지원하도록 구성되어 있어 HTTPS를 통해 접속할 때 생성된 URL은 여전히 ​​HTTP입니다🎜 🎜이 문제는 실제로 서버구성입니다. >. 문제는 다음과 유사합니다. 🎜🎜제가 겪은 WeChat 결제 문제로 돌아가서 잠시 브라우저 점프를 추적해 본 결과, 두 번째 경우는 HTTPS 사이트에서 점프하는 경우였습니다. , 해당 사이트에서 리퍼러가 손실되었습니다. [ps: HTTP에서 HTTPS로 역방향으로 이동하면 문제가 없으며 리퍼러도 손실되지 않습니다.] 중간 깊숙이 숨겨져 있습니다🎜🎜물론 처음에는 이 문제를 인지하지 못했습니다. API에 대한 프론트 엔드 요청에는 문제가 없었습니다. 모든 프로젝트가 전반적으로 HTTPS를 배포했으며 Referer 정보도 전달됩니다. 그러나 마지막 단계에서 WeChat 결제 요청 URL에 도달하면 Referer가 손실됩니다. 🎜🎜 나중에 API 프로젝트를 요청할 때 API 프로젝트가 프런트 엔드에 URL을 반환한 것을 발견했습니다. 이 URL은 규칙(Laravel의 작업 도우미 기능)에 따라 백엔드 코드가 생성됩니다. 기능 자체는 작동하지만 생성된 URL 링크는 HTTP이므로 다시 문제가 발생합니다! ! ! 🎜🎜API 프로젝트가 HTTPS 요청으로 구성되어 있는데 생성된 URL이 HTTP입니다. 운영 및 유지보수 형제에게 도움을 요청했는데 결국 Nginx 역방향 프록시 🎜🎜nginx에 구성된 문제라는 것을 알게 되었습니다. 서버 구성 조각은 다음과 같습니다. 🎜rrreee🎜proxy_pass 매개변수가 HTTP 프로토콜을 가리키므로 백그라운드에서 얻은 URL은 모두 HTTP 프로토콜입니다. 프록시를 https://114.114.114.114:443으로 설정합니다. ; 그러면 문제가 해결됩니다. 권장사항: "🎜WeChat 개발 튜토리얼🎜"🎜                                                     

위 내용은 추천인 누락 문제 요약(WeChat H5 결제)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!