1
votes

Lesquels utiliser, Session, Cookies, Données côté serveur?

tout d'abord merci d'avoir pris le temps de lire ceci et de m'aider.

Je crée un SPA via Angular et j'ai besoin de quelque chose comme une session pour "enregistrer" certaines données (utilisateurs, identifiants, paramètres, etc.), mais uniquement pour l'utilisateur connecté. Ma question était: que dois-je utiliser, cookies ou sessions? Ou y a-t-il autre chose qui pourrait me donner les "meilleures pratiques".

J'ai fait des recherches sur ce sujet pendant 2 jours maintenant. Mes résultats sont que le moyen le plus courant de nos jours consiste à utiliser des données côté serveur avec l'identifiant de session crypté dans un cookie.

Existe-t-il un modèle ou quelque chose sur quoi enregistrer côté serveur et où le sauvegarder? Dois-je créer une nouvelle table dans une base de données?

J'espère que vous comprenez ma question. Merci d'avoir pris le temps.

Salutations Nico aka. Myridor


1 commentaires

Le Web moderne utilise le jeton JWT pour authentifier les utilisateurs. Mettez vos informations dans le jeton jwt et stockez-les dans des cookies. Par conséquent, à chaque demande, vous pouvez obtenir le jeton avec la demande elle-même. Pas besoin d'écrire du code supplémentaire pour récupérer le jeton. Les performances de l'application seront élevées même si aucun utilisateur n'est très élevé.


3 Réponses :


0
votes

localStorage et sessionStorage, qui font partie de l'API de stockage Web, sont deux excellents outils pour enregistrer localement des paires clé / valeur.

LocalStorage et sessionStorage offrent tous deux des avantages par rapport à l'utilisation de cookies:

Les données sont enregistrées uniquement localement et ne peuvent pas être lues par le serveur, ce qui élimine le problème de sécurité que présentent les cookies. Il permet d'enregistrer beaucoup plus de données (10 Mo pour la plupart des navigateurs). Il est plus simple à utiliser et la syntaxe est très simple. Il est également pris en charge dans tous les navigateurs modernes, vous pouvez donc l'utiliser aujourd'hui sans problème. Évidemment, comme les données ne peuvent pas être lues sur le serveur, les cookies ont toujours une utilité, notamment en matière d’authentification.

lecture supplémentaire Introduction à localStorage et sessionStorage


0 commentaires

0
votes

Si je vous comprends bien, vos exigences sont:

  • si l'utilisateur est connecté et reste dans le même navigateur, même lors du rechargement de la page entière ou de l'ouverture de plusieurs onglets, les paramètres peuvent être restaurés
  • si l'utilisateur ouvre un autre navigateur pour se connecter ou si l'utilisateur se déconnecte et se connecte sur le premier navigateur, tous les paramètres précédemment créés dans le premier navigateur sont perdus
  • vous n'avez pas besoin de ces paramètres côté serveur ou vous pouvez les transmettre en tant que paramètres dans les requêtes AJAX
  • c'est correct si l'utilisateur lit tous ces paramètres (faites confiance à l'utilisateur pour conserver les données)

Dans ce cas, les technologies de stockage côté client et en particulier les cookies ainsi que LocalStorage sont les bons choix. Vous devez invalider / supprimer les données lors de la connexion (ou lors de la déconnexion ou de l'ouverture de la page sans cookie de connexion valide) pour éviter d'utiliser les anciens paramètres.


0 commentaires

1
votes

Comme vous avez mentionné que vous souhaitez stocker des utilisateurs, des identifiants et des paramètres utilisateur, je pense que vous devriez opter pour le stockage local et non le stockage de session ou les cookies. Parce que session-Storage effacera la mémoire une fois que vous fermez l'onglet / le navigateur. Alors que le stockage local conservera les données cryptées dans la machine locale (non partagées avec le serveur comme dans le cas des cookies) tant que quelqu'un nettoie le navigateur. J'ai expliqué en détail comme suit.

Cookies: La limite de 4K est pour l'ensemble du cookie, y compris le nom, la valeur, la date d'expiration, etc. Pour prendre en charge la plupart des navigateurs, gardez le nom sous 4 000 octets et la taille globale du cookie sous 4 093 octets. Les données sont renvoyées au serveur pour chaque requête HTTP (HTML, images, JavaScript, CSS, etc.) - augmentant la quantité de trafic entre le client et le serveur.Nous pouvons définir l'heure d'expiration pour chaque cookie

sessionStorage: Il est similaire à localStorage. Les modifications ne sont disponibles que par fenêtre (ou onglet dans les navigateurs comme Chrome et Firefox). Les modifications apportées sont enregistrées et disponibles pour la page en cours, ainsi que les futures visites du site dans la même fenêtre. Une fois la fenêtre fermée, le stockage est supprimé Les données ne sont disponibles que dans la fenêtre / l'onglet dans lequel elles ont été définies. Les données ne sont pas persistantes, c'est-à-dire qu'elles seront perdues une fois la fenêtre / l'onglet fermé. Comme localStorage, il fonctionne sur la politique de même origine. Ainsi, les données stockées ne seront disponibles que sur la même origine.

LocalStorage: Fournit une capacité de stockage beaucoup plus grande. La taille disponible est 10 Mo , ce qui représente beaucoup plus d'espace pour travailler qu'un cookie classique. Les données ne sont pas renvoyées au serveur pour chaque requête HTTP (HTML, images, JavaScript, CSS, etc.) - ce qui réduit la quantité de trafic entre le client et le serveur. Les données stockées dans localStorage persistent jusqu'à leur suppression explicite. Les modifications apportées sont enregistrées et disponibles pour toutes les visites actuelles et futures du site. Cela fonctionne sur une politique de même origine. Ainsi, les données stockées ne seront disponibles que sur la même origine.


1 commentaires

une si belle explication, merci beaucoup! Je vais essayer LocalStorage :)