이에 대해
1. 현재 접근 방식은 먼저 access_token과 해당 획득 시간을 데이터베이스에 저장하고, 현재 요청 시간과 데이터베이스의 시간 차이가 특정 시간(6000s)을 초과했는지 확인하는 것입니다. ) 그렇다면 access_token을 다시 요청하고 토큰과 시간을 다시 저장하세요. 그렇지 않으면 데이터베이스에 있는 기존 토큰을 직접 사용하여 티켓을 요청하세요.
2. 질문: 1) 티켓 다중 요청이 가능합니까? 타임스? 토큰을 여러 번 요청하지 않으면 괜찮나요?
2) 동일한 토큰으로 티켓을 요청하면 달라지나요? 토큰과 티켓은 어떤 연관이 있나요?
감사합니다!
이에 대해
1. 현재 접근 방식은 먼저 access_token과 해당 획득 시간을 데이터베이스에 저장하고, 현재 요청 시간과 데이터베이스의 시간 차이가 특정 시간(6000s)을 초과했는지 확인하는 것입니다. ) 그렇다면 access_token을 다시 요청하고 토큰과 시간을 다시 저장하세요. 그렇지 않으면 데이터베이스에 있는 기존 토큰을 직접 사용하여 티켓을 요청하세요.
2. 질문: 1) 티켓 다중 요청이 가능합니까? 타임스? 토큰을 여러 번 요청하지 않으면 괜찮나요?
2) 동일한 토큰으로 티켓을 요청하면 달라지나요? 토큰과 티켓은 어떤 연관이 있나요?
감사합니다!
'WeChat 공개 플랫폼 인터페이스 디버깅 도구'에 대한 개인적인 경험을 통해 다음과 같은 결론을 얻었습니다.
1 WeChat 공개 플랫폼 개발 문서에는 다음과 같이 명시되어 있습니다.
WeChat 공개 플랫폼에는 jsapi_ticket 호출 횟수와 빈도에 제한이 있는 것을 볼 수 있습니다. jsapi_ticket을 자주 새로 고치는 것은 권장되지 않지만, 새로 고치지 않으면 작동하지 않습니다. 둘째, 티켓에는 api_ticket이 있습니다. jssdk 구성을 위해 WeChat 쿠폰과 jsapi_ticket을 호출하면 QR 코드 티켓을 교환하는 규칙이 동일합니다.
2. 동일한 access_token이 동일한 티켓 결과를 여러 번 얻습니다. 그러나 WeChat에서는 access_token과 티켓을 전역적으로 캐싱하고 해당 만료 시간을 설정할 것을 권장합니다. 둘의 차이점은 개인적으로 생각합니다.
티켓은 특정 API에 대한 호출 인증서이며 어느 정도 유출되더라도 특정 권한만 포함되어 있습니다. access_token은 공용 계정의 자격 증명을 호출하는 전역적으로 고유한 인터페이스입니다. 공용 계정은 각 인터페이스를 호출할 때 access_token을 사용해야 하며 적절하게 유지되어야 합니다. 티켓은 토큰에 의해 생성된 임시 자격 증명입니다. 다시 획득하면 이전 자격 증명이 무효화됩니다.
요약이 잘못된 경우 지적해주세요.