2016-07-25 1 views
0

Je construis une sorte d'application sociale avec le concept de « amis » où les amis peuvent faire des actions concernant un ou plusieurs de leurs amis, je préférerais ne pas demander à la DB si l'amitié n'existe chaque fois que quelqu'un envoie une sorte de demande d'action. Une idée que j'ai trouvé est qu'une amitié est approuvée une signature numérique sera envoyée à chaque utilisateur qui peut être vérifiée dans le serveur pour chaque demande qui devrait coûter moins que demander à la DB. Puis je peux changer la clef asynchrone tous les jours et forcer l'utilisateur à demander une nouvelle signature digitale auquel cas j'approche la db pour tester l'amitié (c'est bon pour la sécurité mais aussi un must si les utilisateurs veulent annuler des amitiés) .Donner une signature numérique après une demande d'ami à utiliser après pour prouver l'amitié dans les applications sociales?

Ce que je demande est si c'est une idée terrible? Peut-être que je ne vois pas quelque chose. Ou tout lien vers n'importe quelle information sur ces types de scénarios serait génial.

+0

J'ai lu quelques informations sur l'utilisation des méthodes de cryptographie au lieu des appels db. Je n'ai toujours rien trouvé concernant mon utilisation. J'ai cependant vu qu'il pourrait être préférable d'envoyer une limite de temps dans la signature d'amitié qui représente jusqu'à quand la signature est valide au lieu de changer ma clé de chiffrement. –

Répondre

1

L'idée de distribuer une signature numérique peut être faite, bien que je ne sache pas si cela serait vraiment plus rapide que d'interroger la base de données, vu que les bases de données doivent être incroyablement rapides.

permet de passer avec l'idée qu'il est en effet une bonne idée. Vous auriez besoin d'un jeton de toutes sortes qui contient les informations sur qui sont vos amis et qui doit avoir été validé par le serveur. Cela, pour moi, semble être quelque chose que vous pourriez utiliser pour un JSON Webtoken (JWT).

Here is the basics on JWTs.

JWTs ont trois parties: les en-tête, la charge utile et signature. L'en-tête définit la durée de validité du jeton et la charge utile peut contenir la liste des amis (ou ID des amis). La signature est un hachage du tout, signé avec la clé privée du serveur, vérifiant ainsi que le serveur a approuvé ce jeton comme valide jusqu'au temps X. Le tout est encodé avant d'être envoyé.

Vous pouvez ensuite envoyer le JWT dans un en-tête HTTP de quelque sorte, sans doute l'en-tête Authorization. Le serveur pourrait alors rapidement décoder le JWT (il existe des bibliothèques pour cela dans beaucoup de langues, les JWT sont un très bon standard) et donc pas besoin d'interroger la base de données. La taille de la JWT doit être envoyée cependant, et donc je ne suis pas sûr que vous gagnerez réellement n'importe quelle vitesse de ceci.

+0

Merci. Je pense que l'utilisation de JWT me sera bénéfique. Une raison est que je peux séparer les serveurs qui gèrent le chat et d'autres actions entre amis des serveurs qui gèrent l'émission d'amitiés. De cette façon, je peux redimensionner ma base de données en conséquence. Je peux faire la même chose pour les sessions en utilisant jwt alors je peux ignorer le db tous ensemble dans ces serveurs. –