Comment déployer votre application sécurisée Vue.js sur AWS –
Cet article a été publié à l'origine sur le blog des développeurs Okta . Merci de soutenir les partenaires qui rendent SitePoint possible.
L'écriture d'une application Vue est intuitive, simple et rapide. Avec de faibles barrières à l'entrée, une approche basée sur les composants et des fonctionnalités intégrées telles que le rechargement à chaud et le Webpack, Vue vous permet de vous concentrer sur le développement de votre application plutôt que sur votre environnement de développement et vos processus de construction. Mais que se passe-t-il lorsque vous êtes prêt à déployer votre application en production? Les choix peuvent être sans fin et parfois peu intuitifs.
En tant qu'architecte de solutions certifiées AWS, on me demande souvent comment déployer des applications Vue sur AWS. Dans ce tutoriel, je vais vous guider dans la création d'une petite application Vue sécurisée et la déployer sur Amazon Web Services (AWS). Si vous n’avez jamais utilisé AWS, ne vous inquiétez pas! Je vais vous décrire chaque étape en commençant par la création d'un compte AWS.
À propos d'AWS
Amazon Web Services (AWS) est une plateforme cloud qui fournit de nombreux services cloud à la demande . Ces services incluent le cloud computing, le stockage de fichiers, les bases de données relationnelles, un réseau de distribution de contenu et bien d’autres encore. AWS a vu le jour non pas comme une offre de vente au détail, mais plutôt comme la réponse interne d’Amazon à la complexité croissante de l’infrastructure chargée d’alimenter Amazon.com et de ses opérations de commerce électronique. Amazon a rapidement réalisé que son infrastructure basée sur le cloud était une solution convaincante et économique et l’a ouverte au public en 2006.
Au moment de la rédaction de cet article, AWS vaut environ 250 milliards de dollars ( oui, c'est un B pour BILLION) et utilisé par des milliers d'entreprises et de développeurs dans le monde entier.
Ce que vous allez construire
Je vais vous aider à créer une petite application Vue avec un serveur Express REST. Vous allez sécuriser votre application en utilisant OpenID Connect (OIDC) d’Okta qui permet l’authentification et l’autorisation des utilisateurs avec seulement quelques lignes de code.
Vous allez commencer par construire l’interface Vue et la déployer sur Amazon S3. Ensuite, vous utiliserez Amazon CloudFront pour distribuer vos serveurs frontaux View à des serveurs de périphérie dans le monde entier. Enfin, vous allez créer un serveur API Express et le déployer avec sans serveur . Ce serveur d'API contiendra une méthode d'extraction de «données sécurisées» (quelques données factices) nécessitant un jeton d'accès valide du client à récupérer.
Cet article a pour but de vous montrer comment exploiter plusieurs services AWS plutôt que que de créer une seule instance EC2 pour servir votre application. Avec cette approche basée sur les services, vous disposez d'une échelle illimitée, d'une maintenance nulle et d'un moyen rentable de déployer des applications dans le cloud.
Qu'est-ce que Okta?
Okta est un service cloud permettant aux développeurs de gérer les utilisateurs authentification et connectez-les avec une ou plusieurs applications. L'API Okta vous permet de:
Inscrivez-vous pour un compte de développeur gratuit et, une fois terminé, revenez pour en savoir plus sur le déploiement d'une application Vue sur AWS.
Bootstrap Frontend
Vous allez d'abord construire l'interface Front sur votre application sécurisée et la déployer sur Amazon S3 et Amazon CloudFront. Amazon S3 (Simple Storage Service) est un stockage de fichiers hautement redondant, basé sur des objets, à la fois puissant et . Dans le cadre de cet article, nous allons nous concentrer sur l'une des meilleures fonctionnalités de S3: Hébergement de sites Web statiques.
Pour démarrer rapidement, vous pouvez utiliser la fonctionnalité d'échafaudage de vue-cli . application en cours d'exécution rapidement. Pour cet article, vous pouvez utiliser le modèle de Webpack qui inclut le rechargement à chaud, l'extraction CSS, le linting et les outils de génération intégrés.
Pour installer vue-cli
exécutez:
npm install -g vue-cli@2.9.6
Ensuite, initialisez votre projet. Lorsque vous exécutez la commande suivante vue init
acceptez toutes les valeurs par défaut.
vue init webpack secure-app-client
cd ./secure-app-client
npm run dev
La méthode init devrait également installer les dépendances de votre application. Si, pour quelque raison que ce soit, vous ne pouvez pas les installer via npm install
. Enfin, ouvrez votre navigateur préféré et accédez à http: // localhost: 8080
. Vous devriez voir le frontal prendre vie!
À propos des applications à une seule page
Lorsque vous créez une application avec Vue, vous développez une application à une seule page (ou «SPA»). ”). Les SPA présentent de nombreux avantages par rapport aux applications traditionnelles multi-pages, rendues par serveur. Il est important de comprendre la différence entre les applications SPA et les applications Web multi-pages, en particulier en matière de déploiement.
Une application SPA est souvent appelée «application statique» ou «site Web statique». que votre application compile tout son code en actifs statiques (HTML, JS et CSS). Avec ces actifs statiques, aucun serveur Web spécialisé n'est requis pour servir l'application à vos utilisateurs.
Les applications Web traditionnelles nécessitent un serveur Web spécialisé pour rendre chaque demande à un client. Pour chacune de ces requêtes, l'intégralité de la charge utile d'une page (y compris les ressources statiques) est transférée.
Inversement, au sein d'un SPA, il n'y a qu'une demande initiale pour les fichiers statiques, Lorsque vos utilisateurs naviguent dans votre application, les demandes adressées aux pages suivantes sont résolues localement et ne nécessitent pas d'appel HTTP vers un serveur.
Vue-router et création d'itinéraires supplémentaires [19659005] Le composant d'un SPA requis pour réécrire dynamiquement la page en cours est généralement appelé «routeur». Le routeur calcule par programme les parties de la page qui doivent muter en fonction du chemin dans l'URL.
Vue possède un routeur officiel qui porte bien son nom vue-router . Depuis que vous avez utilisé le bootstrap vue-cli, votre application a cette dépendance et un fichier de routeur défini ( ./ src / router / index.js
). Avant de pouvoir définir des routes supplémentaires, nous devons créer les pages (ou composants) que vous souhaitez que le routeur rende. Créez les fichiers suivants dans votre projet:
Page d'accueil: ./src / components / home.vue
Allez à la page sécurisée
Page sécurisée (pas encore sécurisée…) ./src / components / secure.vue
Page sécurisée
Retourner
À l'aide de vue-router vous pouvez informer l'application du rendu de chaque page en fonction du chemin.
Modifiez ./ src / router / index.js
pour correspondre à la page. extrait de code suivant:
import Vue de 'vue'
importer le routeur depuis 'vue-router'
importer la page d'accueil de '@ / components / home'
importation sécurisée de '@ / components / secure'
Vue.use (routeur)
laisser routeur = nouveau routeur ({
routes: [
{
path: '/',
name: 'Home',
component: Home
},
{
path: '/secure',
name: 'Secure',
component: Secure
}
]
})
routeur par défaut d'exportation
Essayez-le! Retournez à votre navigateur et vous devriez voir le nouvel écran d'accueil. Si vous cliquez sur le lien "Aller à la page sécurisée", vous remarquerez que la page (et l'URL) changent, mais aucune demande n'a été envoyée à un serveur!
Comprendre l'historique des hachages
vous avez peut-être vu que l'URL est différente de celle attendue (avez-vous remarqué le "# /" au début du chemin?)
http: // localhost: 8080 / # /
et http: // localhost: 8080 / # / secure
La raison pour laquelle l'URL ressemble est que le mode par défaut de vue-routeur est mode de hachage . Le mode Hash simule un nouveau changement d'URL sans demander au navigateur de recharger la page. Ce comportement permet aux SPA de naviguer dans les pages sans forcer votre navigateur à effectuer des requêtes HTTP supplémentaires. Vue-routeur écoute les changements dans la partie hachage de l'URL (tout après le «#») et répond en conséquence en fonction des itinéraires configurés.
Vous pouvez changer le mode de vue-routeur pour tirer parti du mode historique ce qui donnera à votre application de «jolies URL» comme:
http: // localhost: 8080 / secure
Cela présente toutefois un inconvénient majeur, surtout lorsque vous effectuez un déploiement. Étant donné que votre SPA est compilé en une ressource statique, il n’ya qu’un seul point d’entrée index.html
. Si vous essayez d'accéder à une page qui n'est pas index.html
page (c'est-à-dire http: // localhost: 8080 / secure
), le serveur Web renvoie une erreur 404. Pourquoi ? Le navigateur envoie une requête GET / secure
au serveur et tente de résoudre le problème avec le système de fichiers "/ secure" (et le fichier n’existe pas). Il fonctionne lorsque vous naviguez vers / secure
à partir de la page d'accueil car vue-router empêche le comportement par défaut des navigateurs et indique à l'instance du routeur de se déclencher dans n'importe quel mode.
prendre des mesures supplémentaires pour vous assurer que l'actualisation des pages fonctionne correctement. Vous pouvez en savoir plus sur Mode historique HTML5 . Pour vous simplifier la tâche, je vous montrerai une astuce simple pour vous assurer que votre actualisation fonctionne avec AWS CloudFront.
Activez le mode historique en modifiant ./ router / index.js
avec le paramètre suivant.
laisser routeur = nouveau routeur ({
mode: 'histoire',
})
Remarque: Le serveur de développement ( npm run dev
) réécrit automatiquement l'URL vers index.html
pour vous. Ainsi, le comportement que vous voyez localement est la manière dont il devrait fonctionner en production.
Construire votre application à une seule page
Maintenant que vous avez un frontend simple de deux pages travaillant en local, il est temps de créer votre application et de la déployer sur AWS!
Comme vous avez utilisé l'échafaudage vue-cli, vous n'avez besoin que d'un seul appel au script de génération inclus. À partir de la racine de votre projet, exécutez npm run build
et webpack compilera votre application dans le répertoire ./ dist
cible. Si le serveur de développement est toujours en cours d'exécution sur votre console, vous pouvez appuyer sur CTRL + C.
Si vous ouvrez le dossier ./ dist
et que vous devriez voir les résultats du processus de génération:
. /index.html
– C'est le point d'entrée de votre SPA. C'est un document HTML minifié avec des liens vers les applications CSS et JS../ static
– Ce dossier contient toutes vos ressources statiques compilées (JS et CSS)
Au cours de la construction, vous avez peut-être remarqué ce qui suit notification: Astuce: les fichiers créés sont destinés à être servis sur un serveur HTTP. Ouverture index.html sur le fichier: // ne fonctionnera pas . Si vous voulez tester votre application nouvellement compilée localement, vous pouvez utiliser serve
(installez via npm install -g serve
). Exécutez serve ./dist
et vous afficherez une URL à charger dans votre navigateur.
Cela vous permet également de vous familiariser avec le principal problème du mode historique avec vue-router. . Après avoir exécuté serve ./dist
cliquez sur "Aller à la page sécurisée". Vous devriez voir une erreur 404.
Premiers pas avec AWS
Vous aurez besoin d'un compte AWS pour continuer au-delà de ce point. Si vous avez déjà un compte AWS, vous pouvez passer à l’avance. Si vous ne le faites pas, c'est un processus simple qui ne prend que quelques minutes.
- Accédez à la page d'accueil d'Amazon Web Services
- Cliquez sur Inscrivez-vous (ou si vous vous êtes connecté AWS a récemment choisi Se connecter à la console )
- Si vous y êtes invité, vous pouvez sélectionner «Personnel» pour le type de compte
- Remplissez les informations requises, ajoutez un mode de paiement et vérifiez votre numéro de téléphone [19659067] Après la création de votre compte, vous devriez recevoir un email de confirmation
- Connectez-vous!
Remarque: Amazon vous demande de saisir un mode de paiement avant de pouvoir créer votre compte. Tous les services décrits dans cet article sont couverts par . AWS Free Tier vous donne 12 mois d’abonnement.
Hébergez votre application sur Amazon S3
Votre SPA ne comprenant que des actifs statiques, nous pouvons Exploitez Amazon S3 (Simple Storage Service) pour stocker et servir vos fichiers.
Pour commencer, vous devez créer un compartiment. Les compartiments sont une unité logique de stockage dans S3 et vous pouvez avoir jusqu'à 100 compartiments par compte AWS par défaut (si vous étudiez pour l'examen AWS Certified Solutions Architect, vous devez le savoir!). Chaque compartiment peut avoir sa propre configuration et contenir un nombre illimité de fichiers et de dossiers imbriqués.
Après vous être connecté à votre console AWS, accédez à la console S3 (vous pouvez le faire dans la recherche des services AWS pour «S3»). Cliquez sur "Créer un seau" et entrez un nom de seau. Important : Les noms de compartiment sont uniques sur l'ensemble de la plateforme AWS. J'ai choisi bparise-secure-app-client
pour cet article, mais vous devrez peut-être faire preuve de créativité avec votre nom!
Vous devriez maintenant voir votre seau listé. Ensuite, configurons-le pour l'hébergement statique de sites Web.
- Cliquez sur votre nom Bucket, puis choisissez l'onglet "Propriétés".
- Cliquez sur "Hébergement statique de sites Web"
- Choisissez "Utiliser ce compartiment pour héberger un site Web" et ajoutez «index.html» comme document d'index. Cliquez sur «Enregistrer».
En haut de la case d'hébergement de site Web statique, vous devriez voir une URL pour «Endpoint». Il s'agit de l'URL accessible au public pour afficher votre site Web statique. Ouvrez le lien dans une nouvelle fenêtre du navigateur et vous devriez voir ceci:
Stratégies d'accès refusées et S3 Bucket
Oui, vous devriez voir une erreur 403 interdite! Par défaut, les autorisations de compartiment S3 sont refusent tout . Pour accéder au contenu de votre compartiment, vous devez définir explicitement qui peut accéder à votre compartiment. Ces autorisations de compartiment sont appelées une stratégie de compartiment.
Pour ajouter une stratégie de compartiment, cliquez sur l'onglet «Autorisations» et cliquez sur le bouton «Stratégie de compartiment» en haut. La politique suivante permet à quiconque de lire un fichier dans votre compartiment. Assurez-vous de remplacer «VOTRE-NOM DE GODET» par votre nom de seau actuel.
{
"Version": "2012-10-17",
"Déclaration": [
{
"Sid": "PublicReadAccess",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::YOUR-BUCKET-NAME/*"
}
]
}
Les stratégies de compartiment peuvent être assez complexes et puissantes. Mais, les principaux éléments de la politique dont vous devez être conscient sont:
"Effect": "Allow"
"Principal": "*"
– Qui couvre la police (“* ”Implique tout le monde)" Action ":" s3: GetObject "
– L'action autorisée (s3: GetObject permet un accès en lecture seule à tous les objets de votre compartiment)" Resource ":" arn: aws : s3 ::: YOUR-BUCKET-NAME / * "
– Quel est le seau et les objets concernés par la stratégie.
Cliquez sur" Enregistrer "dans l'éditeur de stratégie de compartiment. Vous devriez remarquer qu'une nouvelle erreur s'affiche si vous configurez correctement la stratégie:
Cet avertissement est un bon conseil et une règle de base pour tous les compartiments S3. Cependant, comme notre compartiment est exclusivement utilisé pour héberger un site Web statique, nous n’avons pas à nous soucier de quiconque accède à un fichier dans le compartiment qu’il ne devrait pas.
Revenez à votre navigateur et actualisez le noeud final. Vous devriez maintenant voir une erreur 404 Not Found. Cette erreur est beaucoup plus facile à résoudre car vous n'avez pas encore de fichiers dans votre compartiment.
Déploiement sur AWS avec aws-cli
Maintenant que vous avez une seau créé et autorisations correctement définies, il est temps de télécharger vos ressources statiques. Bien que vous puissiez le faire manuellement via l’interface à l’aide du bouton «Upload», j’estime que l’utilisation de aws-cli est plus efficace.
Installer asw-cli
est différent sur votre système d'exploitation. Choisissez-en un:
- Windows: https://aws.amazon.com/cli/
- Mac/linux run
pip install awscli
Après avoir installé aws-cli
vous devrez générer des clés dans AWS pour pouvoir effectuer des actions via l'interface de ligne de commande.
- Choisissez votre nom de compte dans la barre de navigation, puis choisissez Mes informations d'identification de sécurité. (Si vous voyez un avertissement sur l'accès aux informations d'identification de sécurité pour votre compte AWS, choisissez Continuer pour les informations d'identification de sécurité.)
- Développez la section Clés d'accès (ID de clé d'accès et clé d'accès secrète).
- Choisissez Créer une nouvelle clé d'accès. Un avertissement explique que vous ne disposez que de cette seule opportunité pour afficher ou télécharger la clé d'accès secrète.
- Si vous choisissez Afficher la clé d'accès, vous pouvez copier l'ID de clé d'accès et la clé secrète depuis la fenêtre de votre navigateur et les coller ailleurs.
- Si vous choisissez Télécharger le fichier clé, vous recevez un fichier nommée
rootkey.csv
qui contient l'ID de la clé d'accès et la clé secrète. Enregistrez le fichier dans un endroit sûr.
Remarque: Si vous avez un compte AWS existant ou n'utilisez pas les informations d'identification racine. Vous pouvez afficher et générer vos clés dans IAM.
Maintenant que vous avez votre clé d'accès et votre clé d'accès secrète, vous devez configurer le cli. Dans votre console, exécutez aws configure
et collez vos clés.
$ aws configure
ID de clé d'accès AWS [None]: VOTRE CLÉ
Clé d'accès secrète AWS [None]: VOTRE SECRET
Nom de région par défaut [None]: us-east-1
Format de sortie par défaut [None]: ENTER
Maintenant, vous pouvez utiliser le aws-cli
pour synchroniser votre dossier ./ dist
sur votre nouveau compartiment. La synchronisation diffère de ce que contient le dossier ./ dist
avec ce qui se trouve dans le compartiment et ne télécharge que les modifications requises.
aws s3 sync ./dist s3: // nom-de-votre-compartiment
Retournez à votre point de terminaison de compartiment S3 et vous devriez voir votre site hébergé sur S3!
Pour plus de commodité, ajoutez l'entrée de script suivante à package.json
pour pouvoir exécuter npm run deploy
lorsque vous souhaitez synchroniser vos fichiers.
"scripts": {
"deploy": "aws s3 sync ./dist s3: // nom-de-votre-compartiment"
}
Distribuez votre application avec Amazon CloudFront CDN
L'hébergement Web statique Amazon S3 a une latence extrêmement faible si vous vous trouvez près de la région dans laquelle votre compartiment est hébergé. Mais vous voulez vous assurer que tous les utilisateurs peuvent accéder rapidement à votre site peu importe où ils se trouvent. Pour accélérer la livraison de votre site, vous pouvez utiliser AWS CloudFront CDN.
CloudFront est un réseau de distribution de contenu (CDN) mondial qui fournit du contenu (sites Web, fichiers, vidéos, etc.) aux utilisateurs du monde entier. Au moment de la rédaction de cet article, CloudFront prend en charge plus de 50 emplacements d'extrémité:
La configuration d'une distribution CloudFront prend quelques minutes maintenant que vos fichiers sont stockés dans S3. ] Allez à Accueil CloudFront
Le processus peut prendre n'importe où de 5 à 15 minutes pour provisionner complètement votre distribution.
Pendant que vous attendez, vous devez configurer votre distribution pour gérer le mode d'historique de View-Router. Cliquez sur l'ID de votre nouvelle distribution et cliquez sur l'onglet "Page d'erreur". Ajoutez les pages d'erreur suivantes.
Ces configurations de page d'erreur indiquent à CloudFront de répondre à n'importe quel 404/403 avec ./ index.html
. Voila!
Cliquez sur l'onglet "Général" et vous devriez voir une entrée pour "Nom de domaine". Le nom de domaine est l'URL accessible au public pour votre distribution. Une fois le statut de votre nouvelle distribution déployé, collez-le dans votre navigateur.
Vérifiez que le mode d'historique fonctionne en naviguant sur la page sécurisée et en actualisant votre navigateur.
Ajouter une authentification avec Okta
utilisez Okta, vous devez d'abord avoir un compte développeur Okta. Si vous n'en avez pas, vous pouvez créer un compte gratuit . Une fois connecté, cliquez sur «Applications» dans la barre de navigation, puis sur le bouton «Ajouter une application». Assurez-vous de sélectionner «Single-Page App» comme plate-forme et cliquez sur Suivant.
Vous devrez ajouter votre URL CloudFront à la fois aux URI de base et aux URI de redirection de connexion, sinon Okta ne vous autorisera pas. Vos paramètres d'application doivent ressembler à ceci (sauf pour votre URL CloudFront).
Remarque: Veillez à utiliser HTTPS lorsque vous entrez votre URL CloudFront.
Prenez note de votre “ID client” au bas de l'onglet “Général” car vous en aurez besoin pour configurer votre application.
Ajoutez une authentification sécurisée à votre application
Okta a un composant Vue pratique à gérer tout le lourd travail d'intégration à leurs services. Pour installer le SDK Okta Vue, exécutez la commande suivante:
npm i @ okta / okta-vue @ 1.0.1
Ouvrez src / router / index.js
et modifiez-le pour qu'il ressemble au code suivant. Veillez également à remplacer {clientId}
et {yourOktaDomain}
par le vôtre!
importation Vue de 'vue'
importer le routeur depuis 'vue-router'
importer la page d'accueil de '@ / components / home'
importation sécurisée de '@ / components / secure'
importer Auth depuis '@ okta / okta-vue'
Vue.use (Auth, {
émetteur: 'https: // {yourOktaDomain} / oauth2 / default',
id_client: '{clientId}',
redirect_uri: window.location.origin + '/ implicit / callback',
scope: 'openid profile email'
})
Vue.use (routeur)
laisser routeur = nouveau routeur ({
mode: 'histoire',
routes: [
{
path: '/',
name: 'Home',
component: Home
},
{
path: '/implicit/callback',
component: Auth.handleCallback()
},
{
path: '/secure',
name: 'Secure',
component: Secure,
meta: {
requiresAuth: true
}
}
]
})
router.beforeEach (Vue.prototype. $ auth.authRedirectGuard ())
routeur par défaut d'exportation
Ensuite, verrouillez la route / secure
aux seuls utilisateurs authentifiés. Vue SDK d'Okta est livré avec la méthode auth.authRedirectGuard ()
qui inspecte les métadonnées de vos routes pour la clé requiresAuth
et redirige les utilisateurs non authentifiés vers le flux d'authentification d'Okta.
change à App.vue
Connexion
Bienvenue {{activeUser.email}} - Déconnexion
Dans votre terminal, redémarrez le serveur de développement via npm run dev
. Onglet vers votre navigateur et ouvrez http: // localhost: 8080
. Si vous cliquez sur «Connexion» ou «Accéder à la page sécurisée» (la route protégée / secure
), vous devriez obtenir le flux d'authentification d'Okta.
En cliquant sur l'un de ces éléments, vous serez connecté et vous pourrez accéder à la page sécurisée.
Construire un serveur Secure Express REST
Enfin, nous allons construire un serveur Express pour répondre aux demandes de / hello
et / secure-data
. Le / secure-data
sera protégé et nécessitera un jeton d'authentification du client. Ce jeton est disponible via $ auth.getUser ()
grâce au SDK Vue d’Okta.
Pour commencer, créez un nouveau répertoire pour votre serveur.
mkdir secure-app-server
cd-app-serveur sécurisé
npm init -y
Installez ensuite les dépendances requises.
npm install -s express cors body-parser @ okta / jwt-verifier
Ensuite, créez un fichier qui définira l'application. Copiez le code suivant dans app.js
et remplacez {clientId}
et {yourOktaDomain}
par le vôtre.
const express = require ('express')
const cors = require ('cors')
const bodyParser = require ('analyseur de corps')
const OktaJwtVerifier = require ('@ okta / jwt-verifier')
const oktaJwtVerifier = new OktaJwtVerifier ({
clientId: '{clientId}',
émetteur: 'https: // {yourOktaDomain} / oauth2 / default'
})
laissez app = express ()
app.use (cors ())
app.use (bodyParser.json ())
// vérifie le middleware de jeton JWT
Const authRequired = () => {
return (req, res, next) => {
// demande une requête pour avoir un en-tête d'autorisation
if (! req.headers.authorization) {
retourne ensuite (nouvelle erreur ('l'en-tête d'autorisation est obligatoire'))
}
let parts = req.headers.authorization.trim (). split ('')
let accessToken = parts.pop ()
oktaJwtVerifier.verifyAccessToken (accessToken)
.then (jwt => {
req.user = {
uid: jwt.claims.uid,
email: jwt.claims.sub
}
prochain()
})
.catch (next) // jwt n'a pas vérifié!
}
}
// voie publique accessible à tous
app.get ('/ hello', (req, res) => {
retourne res.json ({
message: 'Bonjour tout le monde!'
})
})
// route utilise le middleware authRequired pour le sécuriser
app.get ('/ secure-data', authRequired (), (req, res) => {
retourne res.json ({
secret: 'La réponse est toujours "A"!'
})
})
module.exports = app
Créez un dernier fichier qui charge l'application et écoute sur le port 8081. Créez ./ index.js
et copiez le code suivant.
const app = require ('./ app')
app.listen (8081, () => {
console.log ('écoute sur 8081')
})
Démarrez le serveur en exécutant node ./
dans votre console. Onglet vers votre navigateur et ouvrez http: // localhost: 8081 / hello
. Vous devriez voir notre charge utile JSON. Mais, le chargement de http: // localhost: 8081 / secure-data
devrait entraîner une erreur.
Appelez le point de terminaison de l'API sécurisé à partir de votre Vue.js Frontend
en cours d'exécution, retournez à votre client et installez axios pour pouvoir appeler le point de terminaison / secure-data
.
npm i axios
Modifiez ./ src / components / secure.vue
pour qu'il récupère le jeton d'accès du kit SDK Okta Vue et envoie la demande à l'API.
Page sécurisée
Données de GET / secure-data:
{{data}}Retour Revenez à votre navigateur et rechargez votre application Web. Accédez à
http: // localhost: 8080 / secure
et vous devriez voir les résultats de l'appel de l'API.
Configurer Serverless et déployer l'API Express
Serverless est une infrastructure d'automatisation Open Source AWS Lambda et API Gateway qui vous permet de déployer votre application dans une infrastructure sans serveur sur AWS. Le terme «sans serveur» (à ne pas confondre avec le logiciel Serverless) est utilisé pour décrire une application exécutée dans le cloud qui n'exige pas que le développeur fournisse des serveurs dédiés pour exécuter le code.
Utilisations sans serveur AWS Lambda et AWS API Gateway pour exécuter votre API express 100% dans le cloud en utilisant uniquement des services gérés. AWS Lambda est un service qui vous permet d'exécuter du code dans le cloud sans provisionner ni gérer les serveurs. De plus, AWS API Gateway est un service permettant aux développeurs de créer, publier, mettre à jour, surveiller et sécuriser les API à grande échelle. En combinant ces deux services, vous disposez d'une plate-forme robuste pour héberger une API sécurisée.
Pour démarrer avec Serverless, installez-le globalement.
npm install -g sans serveur
Ensuite, vous devez créer une configuration sans serveur dans votre application serveur. Utilisez la commande suivante à partir de votre projet
./ secure-app-server
.serverless create --template aws-nodejs --name secure-app-server
Ouvrez
serverless.yml
et modifiez-le pour qu'il ressemble au fichier ci-dessous. Lorsque vous créez une configuration sans serveur, celle-ci contient beaucoup de code et de commentaires standard. La structure suivante est tout ce dont vous avez besoin pour déployer l'application.service: secure-app-server fournisseur: nom: aws runtime: nodejs8.10 stage: dev les fonctions: api: gestionnaire: handler.handler événements: - http: chemin: "{proxy +}" méthode: ANY cors: vrai
La spécification
du fournisseur
informe Serverless que votre application exécute NodeJS et cible le déploiement sur AWS. Les fonctionsdéfinissent un gestionnaire unique qui doit gérer toutes les requêtes HTTP et leur transmettre votre application.
Pour terminer la configuration sans serveur, modifiez
handler.js
dans le code suivant. Il utilise aws-serverless-express qui est un joli petit paquet qui transmet toutes les requêtes API à une application express locale.'use strict'; const awsServerlessExpress = require ('aws-serverless-express') const app = require ('./ app') const server = awsServerlessExpress.createServer (app) exports.handler = (événement, contexte) => {awsServerlessExpress.proxy (serveur, événement, contexte)}
Enfin, vous devriez être prêt à déployer votre application via Serverless. Exécutez la commande suivante:
deploy sans serveur
Ce processus prendra quelques minutes pour provisionner initialement la pile. Une fois terminée, vous devriez voir une entrée
endpoints
sous «Service Information» (votre URL sera légèrement différente de la mienne). [19659198] points finaux:
TOUT – https://YOUR_END_POINT.amazonaws.com/dev/{proxy+}
Pour le tester, naviguez vers
https://YOUR_END_POINT.amazonaws.com/dev/hello
et vous devriez voir notre message hello world. Attempting to go tohttps://YOUR_END_POINT.amazonaws.com/dev/secure
should result in an error.Change Frontend Vue to Use Production API
Up until this point, your frontend app has been configured to call the API hosted locally on
http://localhost:8081
. For production, you need this to be your Serverless Endpoint. Open./src/components/secure.vue
and replacebaseURL
with your endpoint withinmounted()
.baseURL: 'https://YOUR_END_POINT.amazonaws.com/dev',
Finally, build your app and deploy it to CloudFront.
npm run build npm run deploy
Navigate to your CloudFront URL, and you should have a working app! Congratulations on a job well done!
If your CloudFront URL failed to pull the latest version of your web app, you might need to invalidate the CDN cache. Go to your distribution, click on the Invalidations tab. Click Create Invalidation and invalidate paths “/*”. It will take a few minutes, but once it’s complete, you should be able to pull in the latest version.
Final Thoughts
Amazon Web Services is a robust platform that can pretty much do anything. But, it has a relatively steep learning curve and might not be right for all cloud beginners. Nonetheless, I encourage you to dig more into what AWS provides and find the right balance for your development needs.
You can find the full source code for this tutorial at: https://github.com/oktadeveloper/okta-secure-vue-aws-client-example and https://github.com/oktadeveloper/okta-secure-vue-aws-server-example.
Here are a few other articles I’d recommend to learn more about user authentication with common SPA frameworks.
Please be sure to follow @oktadev on Twitter to get notified when more articles like this are published.
Source link