web-dev-qa-db-fra.com

Routage vers des composants angulaires lorsque l'application est un contenu statique hébergé dans S3

Je développe actuellement une application avec une interface Angular4. Mon objectif en production est de faire en sorte que l'interface soit servie en tant que contenu statique à partir d'un compartiment AWS S3.

Tout fonctionne à une exception près, ce qui constitue en réalité un problème majeur pour l'application. Lorsque les utilisateurs s'inscrivent, ils reçoivent un courrier électronique avec un lien permettant de vérifier leurs adresses électroniques. Le format du lien est le suivant:

https://myhostname.com/user/userguid?token=tokenvalue

Comme le client est servi en tant que contenu statique, seule la page index.html existe réellement. Un clic sur ce lien génère donc un 404.

Après quelques recherches, j’ai pris les mesures suivantes. Dans S3, j'ai la règle de routage suivante.

<RoutingRules>
  <RoutingRule>
    <Condition>
      <HttpErrorCodeReturnedEquals>404</HttpErrorCodeReturnedEquals>
    </Condition>
    <Redirect>
      <HostName>myhostname.com</HostName>
      <ReplaceKeyPrefixWith>#!/</ReplaceKeyPrefixWith>
    </Redirect>
  </RoutingRule>
</RoutingRules>

J'ai également une règle CloudFront qui redirige toutes les erreurs 404 vers index.html.

Désormais, lorsque quelqu'un accède à myhostname.com/user/userguid?token=tokenvalue, l'URL est ré-écrit sur myhostname.com/#!/user/userguid?token=tokenvalue, mais l'utilisateur est redirigé vers son adresse./home (aussi appelé index.html).

Quel (s) changement (s) puis-je apporter à mon application Angular pour prendre la valeur du hachage/fragment et le diriger vers ce composant (plutôt que de simplement rediriger, ce qui renverra l'utilisateur à index.html)?

Notez qu'en développement, lorsque l'interface est desservie via 'npm start', cela fonctionne parfaitement. Merci a tous.

angularamazon-s3
14
Zack Allen

Voici la solution finale. Les principaux accessoires à Edmundo.

Lors de la configuration du compartiment S3, sous Hébergement de sites Web statiques -> Propriétés, le document Index et le document Erreur doivent tous deux être 'index.html'. ASSUREZ-VOUS QUE LES RÈGLES DE REDIRECTION SONT BLANCHES!

Dans CloudFlare, une fois la distribution activée et en ligne, accédez à Pages d'erreur et créez une réponse d'erreur personnalisée. Pour toute erreur 404, redirigez vers /index.html et renvoyez un code d'état 200 OK.

Ça fonctionne super bien!

24
Zack Allen

Zack, l'approche que vous avez choisie (le document Index et le document Error doivent tous deux être 'index.html') est malheureusement une mauvaise approche. 

Ce qui va arriver, c’est que vos utilisateurs obtiendront un 404, puis seront redirigés. Cela nuira à votre référencement, Chrome vous pénalisera car il pensera que votre site est du phishing et le support Safari est aléatoire.

La meilleure option consiste à:

  1. Supprimer la redirection de la page d'erreur vers index.html, 
  2. Placez Cloudfront devant le seau S3
  3. Définissez un code de réponse d'erreur personnalisé dans le nuage qui redirige vers /index.html et (LE PLUS IMPORTANT!) Donne un code de réponse de 200 Http

 enter image description here

J'espère que cela pourra aider

20
Robbie Mills

Vous devez créer les paramètres de réponse d’erreur personnalisée CloudFront pour LES DEUX ERREURS 404 et 403.

J'ai un blog post } complet sur ce sujet, ainsi que d'autres astuces d'installation angulaires AWS (telles que HTTPS gratuit).

1
rynop

Vous n'êtes pas obligé de remplacer le préfixe par #!, sauf si vous utilisez LocationHashStrategy, ce qui, à mon avis, ne vous convient pas. Alors supprimez:

<ReplaceKeyPrefixWith>#!/</ReplaceKeyPrefixWith>

Et ça devrait marcher.

0
Edmundo Rodrigues