Je récupère des données du backend, qui m'indiquent la date d'expiration de l'abonnement utilisateur. Si cette date est dans le passé, je navigue l'utilisateur ailleurs, donc elle ne peut pas se connecter:
if (expirationDate.getTime() < new Date().getTime()) {
navigate('/subscription-expired')
}
Je me demande s'il est sûr de faire une vérification comme cette comparaison sur le client? Cela peut-il être manipulé?
3 Réponses :
Vos utilisateurs pourraient-ils manipuler le code JavaScript ou simplement avoir une date et une heure erronées sur leurs ordinateurs? Bien sûr qu'ils pourraient. Serait-ce si critique? Dans votre cas, vous voulez simplement rediriger l'utilisateur vers une autre page, donc ce ne serait pas critique, mais cela affecterait la confiance dans votre application car elle se comporterait de manière inattendue dans certains cas, et dire que l'abonnement est expiré lorsque ce n'est pas (ou dites qu'il n'est pas expiré quand il l'est).
Cela pourrait être beaucoup plus critique si vous aviez un backend qui faisait confiance au client pour fournir la date actuelle sans la vérifier, car vos données pourraient être falsifiées et vos règles commerciales pourraient être contournées.
Cela dépend du cas d'utilisation, mais en général, vous ne devez pas considérer la new Date() dans le navigateur comme une source de vérité. Votre backend reste le détenteur de la vérité.
Vous ne devez JAMAIS faire confiance au client.
En plus de cela, plus important encore , l'heure du serveur et l'heure de votre client peuvent être différentes.
Alors venez à la question, l'heure de début de votre abonnement est-elle basée sur l'heure du client ou du serveur? (qui devrait être l'heure du serveur, car nous ne devrions pas faire confiance au client)
Le moyen le plus sûr est que votre serveur renvoie si l'abonnement est valide, c'est-à-dire vrai / faux;
Si c'est faux, naviguez ('/ subscription-expired')
En plus de cela, chaque page doit contenir le même chèque.
Les avantages de la vérification des données, de la validation des données et d'autres éléments du côté client sont les suivants:
mais la vérification côté serveur est une obligation , car il y a des utilisateurs non réguliers (qui modifie Js, publie des données avec Postman, bots, intrus) qui peuvent envoyer des requêtes Http sans intervention et la validation de votre code côté client pourrait abuser de votre système .
Le côté client est le champ de bataille de l'ennemi
vous devez valider les données côté serveur afin d'éviter tout abus.
mais son recommandée pour valider les données sur le côté client aussi pour améliorer les performances du système.
par exemple dans votre cas:
côté serveur:
{message:"expired"}côté client:
{message:"expired"} . =>
«Sûr» a plusieurs définitions et aspects. Tout ce qui se trouve du côté client peut être manipulé, donc si c'est votre seul chèque, vous avez des problèmes. Si vous vérifiez cela également côté serveur dans les endroits critiques, vous allez probablement bien.
Sûr? Je sais pas. Fiable? Non.
@RobG Merci beaucoup. Pourquoi ne serait-il pas fiable, pouvez-vous développer?
@userjmillohara essayez d'imaginer ce qui se passe si quelqu'un ouvre cette page avec JavaScript désactivé, il pourra y rester aussi longtemps qu'il le souhaite.
@PatrickRoberts oh, tellement vrai! Mais alors le reste de la page / l'application à laquelle je donne accès ne fonctionnerait pas non plus, car tout est en javascript. Ou est-ce que je me trompe?
Date.prototype.getTime()peut également être manipulé pour renvoyer ce que l'utilisateur souhaite, soit en définissant l'horloge système, soit en exécutant un script pour écraser la méthode avec une fonction définie par l'utilisateur de son choix. Comme les gens l'ont déjà souligné, cette vérification devrait idéalement être effectuée côté serveur lorsque la page est chargée avec une requête HTTP.