Compte lié aux actions sur Google, quel champ conserver dans DB?

Question

J'ai testé le lien de compte en utilisant le simulateur. Quel champ dans originalRequest -> data -> user que je peux garder? userId ou accessToken?

J'ai constaté qu'ils sont toujours régénérés lorsque la session expire (ou en basculant le "Statut de test: Actif"), ce qui rend impossible SELECT * FROM User WHERE assistant_client_id = [something].

Je sais que je peux utiliser accessToken pour interroger https://www.googleapis.com/userinfo/v2/me pour "real" (?) Id, mais faire cela pour chaque requête ajoutera du temps supplémentaire (et Assistant n'est pas vraiment patient).

En supposant que accessToken ne sera jamais réutilisé par d'autres, est-ce que je peux le faire?

1. Stockez accessToken dans ma table User.
2. Pour les demandes suivantes, vérifiez en utilisant accessToken.
3. Si aucun match, requête https://www.googleapis.com/userinfo/v2/me pour obtenir l'ID (ou l'email) que je peux utiliser pour interroger ma table, et je mets à jour le accessToken avec la dernière.

Answer 1

Il y a actuellement un bogue avec le champ userId et le simulateur qui utilise le sessionId dans certaines circonstances, mais cela ne devrait être vrai entre les appels dans la plupart des cas sur les appareils réels. Si vous utilisez la liaison de compte, cependant, cette méthode est bien meilleure. Gardez à l'esprit, cependant, que le accessToken est et non un identifiant. C'est une clé temporaire pour un identifiant, comme vous le notez. (Parfois c'est un jeton qui contient un identifiant, mais pas dans votre cas.) Les jetons d'accès sont supposés pour avoir une durée de vie limitée - typiquement une heure. Il y a d'autres cas où vous obtiendrez également un nouveau accessToken, même en moins de temps. Alors que vous pouvez être assuré que si vous voyez le même accessToken deux fois vous parlez au même utilisateur, vous ne pouvez pas supposer que le même utilisateur vous donnera toujours le même accessToken.

Votre méthode est bonne, mais vous devrez également gérer le nettoyage des anciens jetons d'accès. Créez éventuellement un champ de délai d'expiration et supposez que vous pouvez les temporiser au bout d'une heure ou créer un deuxième hachage de votre utilisateur au plus récent accessToken et supprimer un accessToken lorsqu'il est remplacé par un autre.