Comme mentionné, dans le projet, il existe un système distinct en tant que système d'autorisation. L'approche actuelle est que chaque fois qu'une demande est adressée au système métier, elle sera interceptée par le système métier et l'URL demandée sera transmise à le système d'autorisation pour la vérification et le lancement de la vérification. Si l'utilisateur demandeur dispose de cette autorisation.
Ou vous pouvez également obtenir toutes les autorisations de l'utilisateur à partir du système d'autorisation et les vérifier dans le système d'entreprise
Peu importe la méthode utilisée, on a l'impression qu'elle peut être altérée au milieu, donc cela ne semble pas très dangereux
Je voudrais demander s'il est préférable d'effectuer une vérification des autorisations dans un système distribué Merci, senior
.
Le problème de l’affiche n’a rien à voir avec les autorisations, il s’agit uniquement de la sécurité des appels d’interface. Les méthodes générales sont :
Le contenu est transmis en texte clair, mais un code de contrôle est ajouté. Le code de contrôle est généré par une clé convenue par les deux parties. Le falsificateur ne peut pas générer le code de contrôle correct.
Cryptez et déchiffrez l'intégralité de la transmission à l'aide de la clé convenue.
Demandez le système d'autorisations après vous être connecté et placez le menu d'autorisations renvoyé et d'autres informations dans le cache (utilisez Map ou Nosql pour l'implémenter vous-même, il est recommandé d'utiliser le cluster Nosql. Veuillez noter que si le menu est mis à jour, effacez le d'abord les données Redis de l'utilisateur, puis synchronisez les dernières informations avec Redis, Redis les extrait de la base de données s'il n'y a pas d'informations), puis renvoie le jeton Web Java (y compris l'horodatage, l'identification, etc.).
Https et Spring-Security (autorisations d'interface d'accès, prévention CSRF) sont utilisés pour la sécurité du projet. Chaque interface doit être signée et le jeton doit être horodaté.
C'est un peu le problème résolu par OAuth2.0