About this,
1. My current approach is to first store the access_token and the corresponding acquisition time in the database, and check whether the time difference between the current request time and the database has exceeded a certain time (6000s). If so, re-request the access_token and re- Store the token and time, otherwise directly use the existing token in the database to request the ticket;
2. Questions: 1) Is it feasible to request the ticket multiple times? Is it ok as long as the token is not requested multiple times?
2) Will it be different when requesting a ticket with the same token? What is the connection between token and ticket?
Thank you!
About this,
1. My current approach is to first store the access_token and the corresponding acquisition time in the database, and check whether the time difference between the current request time and the database has exceeded a certain time (6000s). If so, re-request the access_token and re- Store the token and time, otherwise directly use the existing token in the database to request the ticket;
2. Questions: 1) Is it feasible to request the ticket multiple times? Is it ok as long as the token is not requested multiple times?
2) Will it be different when requesting a ticket with the same token? What is the connection between token and ticket?
Thank you!
Through personal experience with the "WeChat public platform interface debugging tool", the following conclusions are drawn:
1. The WeChat public platform development document states:
It can be seen that the WeChat public platform has limits on the number and frequency of jsapi_ticket calls. It is not recommended to refresh jsapi_ticket frequently, but it will not work if it is not refreshed. Secondly, the ticket has api_ticket for calling WeChat coupons and jsapi_ticket used for jssdk configuration, which is used to redeem the second ticket. The rules for QR code tickets are the same.
2. The same access_token gets the same ticket result multiple times. However, WeChat recommends caching access_token and ticket globally and setting the corresponding expiration time. As for the difference between the two, I personally think:
ticket is a calling certificate for a certain API. It doesn’t matter if it is leaked to a certain extent, it only contains specific permissions. The access_token is the globally unique interface calling credential of the public account. The public account needs to use the access_token when calling each interface and needs to be kept properly. Ticket is a temporary credential generated by token. If reacquired, the previous credentials will become invalid.
If the summary is wrong, please point it out.