2017-09-19 1 views
0

J'ai suivi les tutoriels Polymer 2 et créé plusieurs applications de test avec un index.html qui charge le composant shell de l'application qui charge ensuite par chargement tous les composants enfant si nécessaire. Maintenant, dans ma vraie application, j'ai un SPA et un backend Rest et j'ai besoin que l'utilisateur se connecte d'abord avec un TSP (Token Service Provider) externe pour accéder à la plupart des interfaces backends. Le backend connaît le TSP et chaque fois qu'un appel REST est fait qui nécessite un utilisateur authentifié, le backend redirige par défaut le client vers la page de connexion du TSP (s'il n'est pas déjà connecté). La page de connexion redirige ensuite vers mon application. Le problème est que mon shell d'application Polymer actuel charge déjà trop de choses et a besoin de beaucoup de temps pour se charger juste alors pour découvrir que l'utilisateur n'est pas encore connecté et doit être redirigé vers le TSP.Polymère 2 avec connexion externe

Quelle est l'approche générale pour gérer ce scénario de connexion externe? Dois-je avoir une page de démarrage réduite qui ne fait rien d'autre que de rediriger vers la page de connexion? Comment puis-je charger l'application réelle lorsque l'utilisateur est redirigé à partir de la connexion? Comment tout cela se conjugue-t-il avec les travailleurs des services et ce genre de choses?

Mise à jour

quelques plus d'infos sur l'environnement:

côté client: polymère 2 avec les OIDC-Client.js (OpenID Connect (OIDC) et le support du protocole OAuth2 pour basé sur le navigateur Applications JavaScript)

Côté serveur: ASP.NET Core 2.0 avec service de fichiers statiques pour Polymer et une interface REST pour accéder à une base de données. Par exemple en cours d'exécution sur le port 5000.

Fournisseur de services de marque: mon service personnalisé, construit sur IdentityServer4 (cadre OpenID Connect et OAuth 2.0 pour ASP.NET Core). Par exemple, sur le port 5001.

Le client oidc est le composant de l'application Polymer qui peut détecter si l'utilisateur est connecté. Dans le cas contraire, il redirige vers le serveur IdentityServer pour le masque de connexion et après une connexion réussie, l'utilisateur est redirigé vers l'application Polymer qui pourrait alors charger tous les contenus/composants accessibles pour l'utilisateur donné.

+0

Vous ne donnez pas suffisamment d'informations sur l'environnement que vous utilisez. quelle langue utilisez-vous back-end? Est-ce une page de connexion externe ou est-ce dans la même base de code? Vous aurez besoin d'être plus précis si vous voulez de l'aide ici. – user544262772

+0

@ user544262772 oui, voir ma mise à jour. – NicolasR

+0

Je ne suis vraiment pas familier avec ces technologies, j'utilise php backend pour contrôler mon architecture reposante avec la session pour gérer l'auth. Aussi j'utilise la page de connexion directement intégrée dans le shell (disons dans la liste des pages de fer) donc ma page n'est pas rafraîchissante, j'ai une variable d'état dans mon application qui dit si l'utilisateur est connecté ou non, s'il n'est pas enregistré Je montre juste la page de connexion et le formulaire envoie un https ajax pour mettre à jour le back-end de la session. – user544262772

Répondre

0

Après plusieurs tests, je pense que j'ai trouvé une solution:

l'idée est simplement de charger l'application en deux étapes.

Etape 1: index.html qui ne contient rien, sauf OIDC-Client.js pour l'authentification externe et les méta-informations, favicon et trucs icône de l'écran d'accueil qui est contenu dans le défaut polymère index.html. Peut-être une petite animation d'attente mais pas d'éléments visuels, des composants web, pas de polymère! Cela devrait charger le plus rapidement possible et vérifier seulement l'état d'authentification. Si l'utilisateur n'est pas authentifié, il est redirigé vers la page de connexion externe. Si elle est déjà authentifiée, elle est redirigée vers l'étape 2.

Étape 2: start.html qui était auparavant l'index par défaut Polymer.html. J'ai mis le favicon et l'écran d'accueil parce que c'est maintenant à l'étape 1. Ce fichier charge le shell de l'application des composants Web.Si un appel REST dans l'application aboutit à 401 (Non autorisé), il faut vérifier si l'utilisateur n'est pas authentifié ou s'il n'a tout simplement pas d'autorisations. Dans le premier cas, l'utilisateur est redirigé vers l'étape 1. Pour que cela fonctionne, l'application réelle a également besoin du fichier oidc-client.js!