Si le backend est distribué (comme un serveur cloud), il est recommandé d'utiliser la méthode de vérification des jetons dans oauth2.0. Si c'est uniquement pour le développement, vous pouvez utiliser des cookies.
Le processus de connexion oauth est le suivant :

1. Créez une nouvelle table de jetons avec les champs token, user_id, login_at, expire_at

2. L'utilisateur se connecte à l'aide d'un compte et d'un mot de passe

3. Si la connexion réussit, un enregistrement sera inséré dans le jeton de la table de données, tous les jetons précédents de l'utilisateur seront supprimés ou définis pour expirer, et le jeton sera renvoyé au front-end

4. Ajouter un en-tête lors de l'utilisation d'Ajax sur le front-endAuthorization=token

5. Le backend lit l'autorisation dans l'en-tête de la requête et la compare avec la base de données Si elle existe et n'a pas expiré, il est considéré comme un utilisateur légitime, sinon une erreur est renvoyée

1 La connexion de l'utilisateur est généralement cookie + session, même si le serveur n'est pas le même. Ce serait bien si l'un d'eux avait une fonction de transfert de requête. En raison des restrictions de la même politique d'origine, les cookies ne peuvent pas être utilisés lorsque. accéder à un autre nom de domaine.

2 Généralement, il y aura une fonction de résumé sur le front-end pour générer un résumé des données. Bien qu'il soit publié avec les données, le back-end utilise la même fonction de résumé pour générer un résumé des données publiées et compare. avec le récapitulatif des données affichées. Si elles sont cohérentes, cela prouve que les données n'ont pas été modifiées. Mais si l'utilisateur sait quelle fonction de résumé vous utilisez, il peut générer un résumé des données et le publier. Donc, en théorie, il est impossible de juger, mais en pratique, les utilisateurs ordinaires ne le savent pas.

1. JWT, jeton Web JSON.

2. Comment le backend détermine-t-il si les données ont été modifiées ? Qu'est-ce que cela signifie ? La base de données backend ne stocke-t-elle pas les données ?

Vérification des données back-end, ceci est nécessaire pour la sécurité des données lorsque le front-end et le back-end sont séparés.
La méthode habituelle consiste à effectuer le cryptage des signes
Ce que vous devez utiliser est la clé et le secret
Par exemple, la méthode de cryptage de l'API Taobao Signe Taobao

La clé est l'ID utilisateur, le nom est qui vous êtes et le secret représente votre clé. La clé est générée par le serveur et ne peut être utilisée que lors du cryptage du client. Les informations Sercet ne peuvent pas être incluses lors de la transmission des données.
Une fois que le client a chiffré toutes les données de la demande selon des règles spécifiques, le backend obtient que les données soumises sont chiffrées de la même manière, puis compare les paramètres de signe pour voir s'ils sont cohérents, cela signifie que. les données n'ont pas été falsifiées pendant le processus de transmission.
De plus, une détection de validité temporelle est également requise, comme le paramètre d'horodatage, qui exige que l'erreur de temps ne dépasse pas 5 minutes avant et après
Un autre point est que les données sont demandées à plusieurs reprises après la réception du backend. le signe, il fait un cache pour stocker le signe, et le délai d'expiration 5 minutes (correspondant au temps ci-dessus), le même signe indique que cette demande a été demandée à plusieurs reprises, puis rejetée

Fondamentalement, il s'agit du processus visant à garantir la sécurité des données, l'actualité, la prévention des duplications, etc.

sessionStorage ou localStorage enregistre le mot de passe spécial généré par l'arrière-plan lui-même. Chaque demande est transmise par la tête et les données sont vérifiées comme étant légales en arrière-plan