Résumé du problème du Referer manquant (paiement WeChat H5)

                                                                                                           

Récemment, la société a demandé le paiement H5 de WeChat. Les documents de paiement pertinents peuvent être trouvés ici https://pay.weixin.qq.com/wiki/doc/api/H5.php?chapter=15_4 Après avoir lancé le paiement. , il continue de signaler une erreur Le format des paramètres du marchand est incorrect, veuillez contacter le commerçant pour le résoudre Selon le document officiel WeChat, le message d'erreur devrait être referer manquant. après l'avoir localisé, j'ai découvert que referer était en fait perdu. Documentez le processus de résolution de problèmes. 商家参数格式有误，请联系商家解决 根据微信官方文档的错误提示 应该是 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;

Qu'est-ce que Referer

HTTP Referer est la requête HTTP pour l'en-tête header information Lorsque le navigateur envoie une requête au serveur Web, il amène généralement un référent pour indiquer au serveur de quelle page je crée un lien, afin que le serveur puisse obtenir des informations à traiter. Par exemple, dans la console du navigateur Chrome, nous pouvons voir des informations similaires aux suivantes sous Request Headersrrreeeoù Referer est Cette propriété a

🎜L'orthographe anglaise correcte deReferer estreferrer. En raison de fautes d'orthographe dans les premières spécifications HTTP, ce fut une erreur de maintenir la compatibilité ascendante🎜

🎜Le rôle du référent

🎜Anti-hotlinking

🎜Par exemple, si vous constatez que le référent n'est pas votre propre site, vous pouvez le bloquer🎜

🎜Prévenir les requêtes malveillantes

🎜C'est la même chose que ci-dessus🎜

🎜Utilisation avancée

🎜Pour Par exemple, le paiement WeChat H5 l'exige également. Sachez à quoi ils servent (hhh🎜

🎜Le référent est perdu

🎜À propos du problème de Referer étant perdu. Tout d'abord, le referer est fait par Le navigateur du client l'envoie au serveur, et le client peut l'obtenir via document.referrer. l'envoi du référent est en fait un comportement du navigateur, et la décision de l'envoyer ou non est prise par le navigateur. Bien qu'il soit dit cela, le protocole HTTP a des réglementations strictes sur le moment où le navigateur doit l'envoyer. et quand il ne doit pas l'envoyer. 🎜

🎜 Résumez plusieurs situations où le référent est perdu

🎜1 Lorsqu'un site Web utilise le champ d'actualisation pour sauter. , la plupart des navigateurs n'envoient pas de référent🎜🎜2. D'un utilisateur cliquant sur un lien d'un site Web HTTPS à un autre Lorsqu'un site Web HTTP est utilisé, le référent n'est pas envoyé🎜🎜3. En html5, le rel de la balise a = ". noreferrer" peut empêcher le navigateur d'envoyer le référent🎜🎜4. Pour les liens utilisant le schéma URI de données, le navigateur n'enverra pas le référent🎜 🎜5. Utilisez la politique de sécurité du contenu pour empêcher le navigateur d'envoyer des référents🎜🎜6. Utilisez le balise méta dans l'en-tête HTML pour empêcher le navigateur d'envoyer des référents🎜

🎜Générer automatiquement des liens URL de HTTPS vers HTTP

🎜Parfois, c'est le cas Il est nécessaire de générer des liens URL dans le projet API pour revenir, mais le serveur a été configuré pour prendre en charge HTTPS. Lors d'un accès via HTTPS, l'URL générée est toujours HTTP🎜 🎜À propos de ce problème, il s'agit en fait de laconfigurationdu serveur. >. Le problème est similaire au suivant 🎜🎜Retour au problème de paiement WeChat que j'ai rencontré. Après avoir suivi les sauts du navigateur pendant un certain temps, j'ai découvert qu'il s'agissait d'un attribut du site HTTPS. , le site a perdu le Referer [ps : du HTTP vers HTTPS à l'envers, il n'y a pas de problème et le Referer ne sera pas perdu] Il est caché au plus profond du milieu🎜🎜Bien sûr, je n'ai pas remarqué ce problème au début car il n'y a eu aucun problème depuis la requête frontale vers l'API. Tous les projets ont déployé HTTPS à tous les niveaux, et les informations du référent sont également transmises. Cependant, lorsque l'URL de la demande de paiement WeChat est atteinte lors de la dernière étape, le référent est perdu. .🎜🎜 Plus tard, j'ai découvert que lors de la demande du projet API, le projet API renvoyait une URL au front-end. Cette URL est Le code back-end est généré selon des règles (fonction d'aide à l'action dans Laravel). cette fonction elle-même, mais le lien URL généré est HTTP, ce qui provoque à nouveau des problèmes ! ! ! 🎜🎜Le projet API est configuré avec des requêtes HTTPS mais l'URL générée est HTTP. Le problème est là. J'ai demandé de l'aide au frère d'exploitation et de maintenance et j'ai finalement découvert qu'il s'agissait d'un problème configuré dans le proxy inverse Nginx 🎜🎜nginx. Le fragment de configuration du serveur est le suivant : 🎜rrreee🎜Vous pouvez voir proxy_pass Les paramètres pointent vers le protocole HTTP, donc les URL obtenues en arrière-plan sont toutes des protocoles HTTP. Définissez le proxy sur https://114.114.114.114:443. ; et le problème sera résolu : "🎜Tutoriel de développement WeChat🎜"🎜                                                                 

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!