De nombreux domaines personnalisés pour l'instance AppEngine

Question

Pour notre service de commerce électronique fonctionnant sur AppEngine, nous souhaitons offrir aux clients la possibilité de gérer les magasins sur leurs domaines personnalisés (par exemple: www.mystore.com au lieu de www.enstore.com /Mon magasin). Du point de vue de l'utilisateur, je voudrais qu'ils entrent le nom de domaine qu'ils veulent utiliser dans leur écran de préférences et leur disent comment configurer leur DNS.

Je sais comment vous ajoutez normalement des domaines à une instance AppEngine (via Google Apps), mais je ne suis pas sûr que vous puissiez l'automatiser. Et même si c'est possible, ils apparaîtraient tous (des centaines) sur notre page google apps.

Quelqu'un sait si c'est possible/s'il y a un bon moyen de le faire?

Answer 1

Je ne pense pas qu'il existe un moyen d'ajouter des domaines "par programmation" à une instance AppEngine. Apparemment, les domaines ne peuvent être ajoutés qu'à l'aide de la méthode Google Apps que vous avez décrite. Ceci est confirmé dans ce SO message: How do i get foo.somedomain.com get handled by myapp.appspot.com/foo on appengine

Les seules options qui apparaissent à l'esprit sont les suivantes:

• HTTP Redirection

  De nombreux fournisseurs de DNS prennent en charge la redirection HTTP. Dans ce cas, vos clients pourront configurer mystore.com et www.mystore.com pour rediriger vers www.enstore.com/mystore. Cette méthode présente certains inconvénients évidents qui pourraient ne pas être acceptables. Tout d'abord, avec les redirections 301 et 302, les utilisateurs seront toujours redirigés vers l'URL AppEngine enregistrée: www.enstore.com/mystore, et ils apparaîtront dans leur navigateur. En outre, le choix entre une redirection 301 et 302 peut compliquer le référencement, car il faut se pencher sur la manière dont les moteurs de recherche se comportent avec ces redirections. Par exemple, la plupart des moteurs de recherche n'utilisent pas l'URL d'origine comme source pour les mots clés lorsque vous utilisez une redirection 301. En plus des redirections 301 et 302, certains fournisseurs DNS (tels que DNS Made Easy) fournissent également ce qu'ils appellent une "redirection masquée cachée-iframe". La page s'affichera dans un cadre iFr caché, de sorte que l'URL ne change pas dans les navigateurs de l'utilisateur. Cependant, cela rend le référencement encore plus difficile, et il ne permettra pas aux utilisateurs de mettre en signet des pages internes, ou de les référencer facilement. Comme vous pouvez le voir, cette option n'est pas idéale, mais c'est une option à envisager dans certaines situations. Notez également que pour le moment, la redirection HTTP à l'aide de redirections 301 est la solution de contournement suggérée pour le Naked Domain Issue 777 sur le suiveur de problèmes AppEngine.

• Reverse Proxy

  Une autre option pourrait être de mettre en place un petit serveur quelque part ailleurs, comme un petit Amazon EC2 Instance, et mettre en place un reverse proxy simple. Vous seriez en mesure de mettre en place très facilement, juste en utilisant Apache et mod_proxy (ou diverses autres alternatives). Cela vous permettrait de demander à vos clients de configurer un enregistrement A normal pointant vers cette instance, tandis que le serveur HTTP Apache agirait comme un proxy pour votre AppEngine.

  La directive de configuration fondamentale pour configurer un proxy inverse dans mod_proxy est le ProxyPass.Vous généralement mettre en place avec une ligne comme ceux-ci pour chaque VirtualHost (pour chaque domaine client):

  ProxyPass / http://www.enmystore.com/mystore/

  La configuration du proxy à distance peut être facilement manipulé par votre logiciel back-end.

  Ceci est une solution plus propre qui vous donne beaucoup de contrôle - mais il y a évidemment des coûts pour ces avantages. Tout d'abord, il y a la dépense pour héberger le proxy inverse. Vous ajouteriez également un autre point d'échec, vous devez donc l'ajouter à votre plan de haute disponibilité. De plus, si vous servez certaines pages via SSL, cela peut devenir assez compliqué.

Answer 2

Une autre option est d'avoir chaque client pour vous inscrire Google Apps, puis ajoutez votre application AppEngine à leur application. De cette façon, ils peuvent gérer l'URL. Ils auront besoin d'utiliser un cname pour cela, donc les urls seront limités à quelque chose comme 'store.customer.com' Vous devrez supporter la multitenancy hors de l'en-tête de l'hôte, mais ce n'est pas difficile à faire étant donné que vous déjà un moyen de soutenir multitenancy déjà. Vous voudrez peut-être faire vous-même la configuration pour les deux premiers clients afin de documenter la manière la plus simple de le configurer. L'application de révision de code rietveld fait cela car vous pouvez l'ajouter à votre domaine google apps. Voir http://code.google.com/p/rietveld/wiki/CodeReviewHelp#Using_Code_Reviews_with_Google_Apps pour plus de détails.

L'option préférée est probablement d'offrir votre solution grâce à Google Solutions Marketplace: http://www.google.com/enterprise/enterprise_marketplace/about.html

Answer 3

Nous avons fait quelque chose de similaire à Daniel Vassallo deuxième proposition. Nous avons créé une application python sur le cloud Heroku (il n'y a pas de limite pour la connexion de domaines personnalisés). Cette application utilise les requêtes python 1.2.0 lib pour obtenir la bonne page de votre application de moteur d'application en fonction du domaine de la demande. tout ce que vous devez dire à vos clients est de mettre votre URL d'application Heroku comme CNAME Pour les domaines nus, vous pouvez toujours utiliser wwwizer