preface
Recently, due to project needs, we need to develop an H5. Then this H5 is embedded in the small program to use, in the small program web-view using H5 is also encountered some problems, mainly cookie sharing problem, there are some strange phenomenon, here simple record, convenient encounter the same problem have a reference
Cookies in applets cannot be carried to interfaces
Influenced by the thinking of Web development, I feel that as long as the cookie is set, the request will be automatically accompanied by cookies. This is also what I thought when I wrote the cookie authentication of the applet, but the fact is that although cookies can be written, they are not automatically brought when requesting the interface. Too young for that.
How do applets request cookies
Since requests cannot be automatically loaded with cookies, there is no choice but to manually store cookies and write them into the request header, making each request loaded with cookies
So every interface request of the applet will have a cookie on it and it will have the same function as the automatic cookie on the Web side
How to use cookies to achieve synchronous authentication in WEB-view H5
In normal thinking, the best way is to get cookies directly from applets in H5. That’s easy, but small programs won’t get you there. Turns out you can’t get cookies in H5. Since they are two separate domains, it can be understood that the applet calls the native ability to make requests, and the applet operates differently from the Web. The H5 in Web-view can not get cookies, but it can also be understood. However, the small program in web-view and wechat directly open H5, because the use of the same browser kernel, so, their cookie, storage can be shared.
But the cookie needs to be shared anyway, so we’ll fix it. There’s no way to do that, so just pass the cookie in the applet as the URL parameter when you jump to the page in the Web-view, and then get the cookie in H5, and then store it in the cookie. Cookie sharing is now complete.
document.cookie = `cookie=${history.location.query.cookie}`;
Copy the code
So that takes care of cookie sharing.
Cookies set using the JS-cookie library do not take effect in web-view
There is a simple package to set cookies, so use it.
yarn add js-cookie
import cookies from 'js-cookie'
cookies.set('key',value)
Copy the code
The cookie is set successfully and h5 is valid when used in a browser. But problems arise when you plug the H5 into a Web-view. Look at the source code of JS-cookie implementation, found that it is more than the process of decoding to ensure that the string does not change, according to the truth is no problem. So we still use the native way to write cookies here. If the old iron who uses this library encounters this problem, we can use the native method first. Please tell me the specific reason
summary
Probably record the small program and web-view shared cookie encountered problems and solutions, is a record of their own, I hope to help you, welcome to like!! Thank you very much!!