Unhosted

Aventures Unhosted

Une traduction approximative du Journal de bord officiel du No Cookie Crew

d’après Unhosted Adventures
by Michiel B. de Jong

11. L’hébergement d’applications

L’hébergement est un moyen de communication à travers l’espace et le temps.

Ce billet de blog me relie à vous. J’écris ce billet depuis un Starbucks de Bukit Bintang, par un samedi pluvieux. Vous le lisez depuis un autre lieu, à une date ultérieure. L’hébergement est juste un moyen qui rend cela possible.

Même lorsque nous consommons du contenu hébergé, nous ne devons pas oublier de concevoir nos applications Internet avec le principhttpse du bout-à-bout (“end-to-end principle”) à l’esprit. Si nous voulons qu’Internet puisse rendre les gens plus autonome, alors il est de notre devoir de modéliser les communications pour quelles se déroulent directement entre les gens. Cela peut remettre en cause quelques hypothèses avec lesquelles vous avez été nourris au cours de l’âge du logiciel hébergé.

TLS n’est pas sûr à moins qu’il soit combiné avec un hébergement sur site

TLS (anciennement connu sous le protocole SSL, technologie derrière les adresses URL https://), signifie Transport Layer Security. Il établit un tunnel sécurisé entre le client et le serveur. Des personnes tiers sont en mesure de voir que ce tunnel existe, et de voir, de manière plutôt approximative, le nombre des données qui transitent par celui-ci, la direction de ces données, et les trames temporelles -(“timing patterns”)_, mais elles ne sont pas en mesure de voir le contenu non crypté qui y circule.

Au-dessus de TLS, le Web utilise une infrastructure de clé publique (ICP) (“Public Key Infrastructure (PKI)”)_basée sur les autorités de certification _(CAs). Ce système possède ses propres lacunes par sa centralisation du pouvoir, mais là n’est pas mon propos.

Pour faire simple, l’architecture de sécurité client-serveur est en soi une approche dépassée de la sécurité. Elle part de l’hypothèse que le serveur se trouve sous le contrôle physique de la personne ou de l’organisation qui publie le contenu. Ceci était probablement vrai pour 90% des premiers sites Web, il y a 20 ans, mais de nos jours, ce pourcentage est probablement plus proche des 10% (voire moins). Cela signifie que, dans le modèle de communication bout-à-bout, nous devrions considérer les serveurs plutôt comme des sauts ou étapes intermédiaires, et non pas comme des points de terminaison.

Le problème reste raisonnablement limité sur les serveurs en colocation, là où le data-center en charge de l’hébergement de votre serveur ne possède pas le mot de passe root de celui-ci. Dans ce cas, la moindre intrusion devrait au mois être détectable, à condition bien sûr que votre serveur en colocation soit muni de bons capteurs de type “case open” et alertes similaires.

Mais aujourd’hui les offres d’hébergement baptisées Infrastructure-en-tant-que-Service (“Infrastructure-as-a-Service” - IaaS) proposent des serveurs virtualisés, et non plus physiques. Ceci est plutôt positif car cela permet au fournisseur de l’IaaS d’agir sur votre serveur pour l’équilibrage de charge et le redimensionnement direct, mais cela signifie aussi que le système hôte a accès à votre clé TLS privée.

Dans une compagnie IaaS de confiance, seuls les administrateurs systèmes sous serment sysadmin (“sysadmin oath”) et leurs supérieurs auront accès à votre serveur. Les bons managers au sein de ces sociétés IaaS n’utiliseront leur accès que pour accorder les accès nécessaires aux administrateurs système nouvellement embauchés, et (en dehors peut-être de quelques gouvernements d’États-nations), vraisemblablement, seulement si on leur présentent des motifs fondés.

Il est facile de reconnaître les administrateurs système : ils détournent leurs regards d’un geste résolu lorsque vous tapez votre mot de passe en leur présence. Même si c’est le mot de passe que vous venez juste de leur demander de réinitialiser. C’est dans les gènes d’un administrateur systeme professionnel d’être très rigoureux sur la sécurité et la vie privée. Pourtant, les sites hébergés par le biais de TLS ne peuvent plus, à l’ère du Web 2.0 et «du Cloud», être raisonnablement qualifiés comme sécurisés de bout-à-bout, étant donné que les parties communicantes (Alice et Bob, comme nous les appelons souvent) n’ont pas de canal sécurisé entre eux.

Alors, où en sommes-nous ? Jetons un œil plus spécifiquement sur l’hébergement d’applications.

Attendez, héberger une application web Unhosted, n’est-ce pas une contradiction ? :)

Oui, bien sûr, être très précis, nous aurions appelé «applications web statique uniquement ‘applications web Unhosted, car ce que nous entendons est« applications web dont la fonctionnalité n’est pas produit par le code qui s’exécute côté serveur, même si la source les fichiers de l’application sont toujours accueillis comme du contenu statique. Mais cela n’a tout simplement pas l’air aussi intrigante. ;)

Le web n’a aucun moyen de la signature des applications web. Lorsque vous hébergez une application web unhosted («statique uniquement), nous venons de servir chacun des fichiers qui composent l’application sur un site Web, et la seule façon de savoir si vous voyez l’application web que le développeur a voulu que vous voyiez , est si le serveur est sous le contrôle physique du développeur. Cela ne se produit pas souvent, bien sûr (en particulier avec les développeurs nomades!), Donc dans la plupart des cas, nous devons faire des compromis un peu sur la sécurité.

Dans la pratique, la sécurité est toujours relative, et à moins que vous mettez en miroir les applications que vous utilisez, et d’héberger vous-même dans votre LAN, dans presque tous les cas, nous devons faire confiance au moins une partie intermédiaire: l’hébergeur application. Il ya une seule exception à cela: les systèmes RevProTun comme Pagekite.

RevProTun et Pagekite

Si vous avez un FreedomBox dans votre maison, ou si vous autrement exécuter un serveur qui est toujours actif dans un endroit qui vous contrôlent physiquement, alors vous pouvez mettre les applications Web que vous publiez sur Unhosted là, hébergé sur un simple serveur statique avec TLS. Vous pouvez utiliser un script pour ce nodejs comme celui que nous avons décrit dans l’épisode 3: la configuration de votre serveur personnel. Une fois que vous avez un site TLS est activé sur localhost, vous pouvez publier votre localhost dans le monde en utilisant un service RevProTun. Un bon exemple, amis personnels ainsi que les principaux moteurs derrière le développement de RevProTun, sont Pagekite. Vous ouvrez un compte avec eux tunnel, installer leur application client dans un endroit où il peut «voir» le service localhost vous souhaitez publier, et il va commencer à générer du trafic à partir du monde extérieur à lui, fonctionne comme un tunnel proxy inverse à partir de votre URL accessible au public à votre place couru TLS sécurisées statiques service d’hébergement.

RevProTun est une partie importante de la façon dont nous voulons ajouter Web indépendant d’hébergement pour FreedomBox. Ce sont encore les plans futurs pour lesquels nous avons toujours du mal à trouver du temps, mais nous sommes déterminés à faire une «liberté compatible avec la maison d’hébergement” solution de ce genre disponible dans un format qui peut également être utilisé par les utilisateurs finaux qui ne veulent tout savoir les modalités précises de proxy inverse tunnels travail. Si vous voulez en savoir plus sur eux, un bon endroit pour commencer est question FOSDEM Bjarni sur Pagekite.

Comment travailler origines

Chaque application Web doit être hébergé sur son propre «origine», ce qui signifie sa propre combinaison unique de schéma, l’hôte et le port.

La raison de ceci est que votre navigateur Bouclier applications les unes des autres, de les mettre chacun dans leur bac à sable propre limitée. Si vous souhaitez héberger deux applications sur la même origine, votre navigateur permettrait à ces applications d’accéder uns et des autres données (par exemple, les données qu’ils stockent dans localStorage), et alors les choses deviennent généralement juste un grand désordre. Donc, ne jamais essayer de le faire. Lors de l’hébergement des applications, accueillir chacun sur sa propre origine.

Cela signifie également que, même si dropbox.js et GitHub sont d’excellents outils pour les développeurs d’applications Web Unhosted, vous ne voulez pas publier d’applications web Unhosted directement sur https://dl.dropbox.com/, ou héberger plus d’un application sur chaque http://username.github.com/, sauf peut-être si elles sont des applications qui ne gèrent pas de données utilisateur (pour courte durée et jeux html5 autonomes, par exemple, cette considération de sécurité peut être moins important).

Ainsi, supposons que vous avez votre nom de domaine Indie Web et vous souhaitez publier des applications web Unhosted au monde. Pour l’hébergement http (sans TLS), ce n’est pas si difficile à faire. Rappelez-vous l’origine est définie par schéma, l’hôte et le port. Le schéma d’origine de chaque application sera toujours «http», mais vous pouvez pointer hôtes du sous-domaine que beaucoup de votre adresse IP que vous voulez, surtout si vous utilisez un CNAME wild-card. Ensuite, vous pouvez simplement utiliser http://app1.example.com/, http://app2.example.com/, etc origines que pour les applications que vous accueillent.

Si vous voulez le faire correctement cependant, et obtenir au moins le montant de la garantie que nous pouvons malgré votre serveur sans doute être hébergé sur l’infrastructure IaaS insécurité, alors vous devriez toujours accueillir des applications sur https. Ce qui met en jeu les limites de votre TLS dont les origines cert vont travailler. Sauf si vous possédez un certificat wild-card, vous aurez probablement seulement deux hôtes, probablement “something.example.com” et sa société mère, “example.com”.

Mais heureusement, les origines sont définis par schéma, l’hôte et le port. Cela signifie que vous pouvez héberger des dizaines de milliers d’applications utilisant le certificat même simplement utiliser origines comme “https://apps.yourdomain.com:42001/”, “https://apps.yourdomain.com:42002/”, etcetera .

Utilisation SNI pour accueillir plusieurs TLS cert

Cinq ou dix ans SNI n’existait pas encore, et vous avez dû obtenir un dédié adresse IPv4 pour chaque TLS cert. Jusqu’à récemment, je pensais que c’était encore le cas, mais comme Bjarni m’a expliqué l’autre jour, c’est maintenant un problème résolu. Utilisation SNI, vous pouvez héberger autant de TLS certs sur un serveur virtuel que vous le souhaitez, sans avoir à demander supplémentaires adresses IPv4 et de payer le supplément pour eux. Je n’ai pas passé à moi-même encore, puisque j’ai déjà publié mes Unhosted web apps applications tout au long de 5apps. Je ne avoir deux adresses IPv4 sur mon serveur, l’un et l’autre pour nodejs apache, et que votre serveur aura besoin de deux adresses IP pour faire STUN dans quelques épisodes à partir de maintenant (oui, nous allons jouer avec PeerConnections bientôt), mais en général, la SNI est une bonne chose à savoir quand vous hébergez des applications.

5apps

Il ya un très cool Berlin start-up, encore une fois, aussi amis personnels, appelés 5apps. Ils se spécialisent dans l’hébergement application pour les applications Web Unhosted. Vous pouvez avoir vu leur mentionnés sur notre page outils, et la plupart de nos applications proposées sont hébergés sur 5apps. Ils viennent de lancer un soutien pour https accueillir la semaine dernière (en utilisant leur joker TLS CERT pour apps.com * .5), et le déploiement de votre application à leur hébergement vous donne un certain nombre d’avantages par rapport à la maison-cuire votre hébergement propre application. Ils seront automatiquement générer un manifeste appcache pour votre application (plus à ce sujet ci-dessous), redimensionner l’icône de votre favicon pour les formats différents pour les navigateurs ainsi que pour les appareils iPad par exemple, et de générer tous les formats de fichiers différents pour soumettre votre application à différents sites d’examen et les magasins app (plus à ce sujet la semaine prochaine).

En plus de cela, ils offrent un certain nombre de choses qui «font votre application belle”, comme la détection compatibilité du navigateur, un widget commentaires des utilisateurs et minification JavaScript. Statique hébergement est un marché mature, vous pouvez trouver différentes sociétés qui se spécialisent dans celui-ci. Mais l’avantage de 5apps plus, par exemple, Amazon S3 est que 5apps se spécialisent notamment dans l’hébergement de vos applications web Unhosted. Et comme avec Pagekite, je peux personnellement confirmer que ce sont des gens sympas, qui se soucient de nouveau la décentralisation du web. :)

Par souci d’exhaustivité, permettez-moi de mentionner que AppCloudy fournir un produit similaire à 5apps, et il ya probablement quelques autres. StackMob et Tiggzy proposons également l’hébergement html5 application comme une activité secondaire à leur service backend pour application mobile native. Je mettrai à jour cette section que l’évolution du marché (conseils bienvenus!).

Mise en miroir et l’emballage.

Depuis les premiers jours de l’Internet, les sites Web importants, surtout si elles contiennent de gros fichiers téléchargeables, ont été mis en miroir. Une application web est statique unhosted seulement, de sorte qu’il peut être sérialisé comme une arborescence de dossiers contenant des fichiers. Cette arborescence de dossiers peut être emballé comme un répertoire FTP, un dépôt git, un fichier zip, un fichier zip avec une extension ‘. Crx »(tel qu’il est utilisé par les extensions Chrome), ou un bittorrent par exemple. Si vous le transporter sur un ou plusieurs de ces médias, alors il peut facilement être mis en miroir par plus d’un hébergeur application.

Nous appelons une application web statique seule qui est en cours d’un miroir à l’autre de telle sorte une «application web emballé».

Il ya un aspect fascinant dans le concept de ces applications web emballés: ils sont robustes contre les attaques sur notre système DNS.

Parfois, les gouvernements bloquer les sites Web. Probablement dans presque tous les cas, cela se fait par des gens qui pensent qu’ils font la bonne chose: ils ont vraiment pense honnêtement que Facebook est mauvais pour le Vietnam, ou que Wikileaks est mauvais pour les Etats-Unis, ou que ThePirateBay est mauvais pour les Pays-Bas, et que une telle censure est finalement dans l’intérêt du peuple qui les a installés comme des employés du gouvernement.

Ou peut-être qu’ils pense honnêtement que les intérêts du communisme, ou les intérêts de la sécurité nationale ou les intérêts de l’industrie du divertissement sont plus importants que les considérations relatives à la liberté de communication.

Quelles que soient les raisons de ces actions, et quel que soit le jugement moral sur l’opportunité Facebook, Wikileaks et ThePirateBay sont des sites Web mal, à partir d’un principe de conception technologique de la “kill-passer résilience», ce serait bien si nous avions un moyen de publier des applications web Unhosted de manière décentralisée.

Il serait également juste être gentil, d’un point de vue pratique d’avoir une copie locale d’un grand nombre d’informations que nous avons souvent regarder en ligne. Je vous écris ceci en ce moment dans un endroit sans wifi, et jusqu’à présent je n’ai fait cinq notes de choses que je devrais regarder sur MDN tard. Si j’avais une copie locale du MDN, qui me ferait beaucoup moins dépendants de la connectivité.

A titre d’exemple, prenons Wikipedia. Un morceau très important de toute connaissance humaine est là-bas. Vous pouvez télécharger un fichier compressé xml contenant tout le texte (pas les images) de l’édition anglaise. Il est environ 9 giga-octets. Masser un peu ceci, et en ajoutant le code de rendu nécessaire, nous pourrions faire cela en une application web unhosted qui peut être exécuté sur l’hôte local, en utilisant une statique simples d’hébergement script comme ceux que nous avons vus dans les épisodes précédents.

La façon évidente de distribuer un tel fichier multi-Gigabyte serait bittorrent. Alors que cela semble tout à fait réalisable: on met d’énormes applications web Unhosted dans des fichiers torrent, et tout le monde peut collaborer à leur ensemencement. Nous pourrions le faire pour Wikipedia, MDN, Kahn Academy, Open Cours de Yale, discussions de cette année panneau EdgeConf, aucune connaissance vous souhaitez que tous les êtres humains d’avoir accès à. Compte tenu de la façon dont un 1 To pas cher disque dur externe est de nos jours (environ 80 USD), vous pourriez même Unhost l’ensemble du projet Gutenberg, et j’ai encore un peu d’espace libre sur le disque.

Et bien sûr, vous pouvez l’utiliser pour de petites applications aussi bien. Même si applications web cache unhosted eux-mêmes dans votre navigateur lorsque vous les utilisez, il serait agréable d’avoir un serveur d’application, quelque part à l’intérieur de votre réseau local qui héberge seulement des milliers d’applications web Unhosted sur des URL locales, afin que vous puissiez y accéder rapidement sans avoir recours à connectivité.

C’est une idée que j’ai commencé à penser à un il ya quelques semaines, puis Nick découvert qu’il y est un projet qui fait exactement cela! :) C’est ce qu’on appelle Kiwix. Ils utilisent le format de fichier ZIM, qui est optimisé pour le contenu du wiki. Ils fournissent également une application qui détecte et récupère les fichiers ZIM, et les sert sur le port 8000, vous pouvez ouvrir une version en miroir par exemple d’un site web emballés sur le Venezuela sur l’un de vos origines localhost nombreux, par exemple http://127.13 .37.123:8000 / wikipedia_es_venezuela_11_2012 / (rappelez-vous l’espace d’adressage IP localhost est un “/ 8” comme on dit, il couvre toute adresse IP qui commence par “127”., donc il ya là de quoi origines accueillir de nombreuses applications sur).

Conventions app emballés d’hébergement

Il ya quelques conventions que vous devez garder à l’esprit lors de l’écriture d’un serveur web qui héberge le contenu statique. La plupart de ceux qui sont bien connus dans le folklore ingénieur web, et si vous utilisez un logiciel comme Apache ou nœud-statique, alors ce sera tout simplement travailler automatiquement par défaut.

Une application web emballé, peu importe si elle est emballée dans un fichier torrent ou un dépôt de fichier zip ou git, est un dossier contenant des documents et / ou sous-dossiers. Chaque sous-dossier peut contenir des éléments plus de documents et sous-dossiers. Pas de deux éléments en un même dossier peuvent avoir le même nom, les noms sont sensibles à la casse, et même si, en théorie, tous les caractères UTF-8 devraient être autorisés à eux, vous devriez être au courant des séquences d’échappement requis par le format dans lequel vous êtes il emballer. Bien sûr, les documents de cette carte de la structure dossier sur les documents qui doivent être mis à disposition via http, diviser le chemin de l’URL le long des barres obliques, et la cartographie que sur la structure du dossier, en tenant compte à nouveau les séquences d’échappement définies pour les URI et IRI.

L’extension du fichier d’en-tête qui détermine “Content-Type” doit être envoyé. Quelques exemples:

`. Html -> text / html`
`. Js -> application / javascript`
`. Css -> text / css`
`. Png -> image / png`
`. Svg -> image / svg + xml`
`. Jpg, jpeg ou même JPG -..> Image / jpeg`
etcetera

Le serveur doit également définir un en-tête jeu de caractères (généralement UTF-8), puis assurez-vous qu’il est aussi le contenu de chaque document dans ce jeu de caractères.

Pour permettre au navigateur de mettre en cache les fichiers que vous servez, et les récupérer sous condition, vous devez implémenter un support pour ETag et If-None-Match têtes.

Chaque fois qu’un des cartes URL vers un dossier (avec ou sans slash à la fin) au lieu d’un document, si un document index.html existe dans ce dossier, vous devez servir que.

Si le document demandé n’existe pas, mais en existe un dont le chemin d’accès complet ne diffère que dans le cas (par exemple toto / bar.html a été demandé, mais seulement Foo / bar.html existe), puis rediriger vers cela.

En dehors de cela, si une URL cartes à aucun élément existant, tendre le ‘404. Document html ‘à partir du dossier racine s’il existe, ou une page d’erreur 404 standard, et dans ce cas, bien sûr envoyer un état 404 au lieu de de 200 état.

En outre la mise en œuvre d’un soutien Byte gammes est agréable à avoir, mais pas indispensable.

La mise en cache et le principe de bout-en-bout

Appcache est un moyen pour une application web pour raconter un navigateur pour les parties de cache pro-active de celui-ci. Il est encore une technologie relativement nouvelle, et si vous voulez savoir comment il a obtenu son surnom de «appdouche cachebag ‘, vous devriez vraiment regarder au moins les 10 premières minutes de cette vidéo:

(Afficher http://www.youtube.com/embed/Oic22dQMRXQ)

Une bonne chose à propos de appcache est que, comme le cache du navigateur http, il fonctionne de bout en bout. Le Web des documents a été conçu avec la mise en cache des requêtes GET à l’esprit. Un grand nombre d’applications hébergées des applications web en cache le contenu produit par leurs serveurs web utilisant quelque chose comme le calmar ou de vernis, derrière une couche https déchargement. Souvent, ce sera sous-traitée à un réseau CDN. Après cela, en théorie, les chercheurs pensaient que la multidiffusion deviendrait gros sur l’Internet, mais cela n’a pas vraiment le cas, du moins pas pour le contenu Web. Au lieu de cela, les fournisseurs de contenu comme YouTube et CDN comme Akamai étendu leurs tentacules jusque dans les pôles d’échanges où ils échangent du trafic avec les FAI. Dans un sens, nous avons l’épine dorsale de multidiffusion que le monde universitaire a essayé de se développer, mais il est maintenant la propriété privée des entreprises comme les deux que je viens de mentionner.

Donc, une fois le contenu atteint le FAI, il sera souvent mis en cache à nouveau par le FAI, avant sa livraison au dernier kilomètre. Rien de tout cela fonctionne lorsque vous utilisez end-to-end encryption, cependant. Trafic multicast est un peu comme la déduplication contenu adressable par le contenu, seulement plus difficile en raison des contraintes de temps. Et comme la règle de base va, sur 1) end-to-end encryption, 2) de multidiffusion (/ déduplication), et 3) donner un sens, vous ne pouvez en choisir deux. :)

Cela signifie que le https, toute demande qui manque cache sur votre appareil, devra faire l’aller-retour tout le chemin à l’hébergeur application. Miroir peut réduire la distance entre l’hébergeur application et l’utilisateur, mais à chaque fois que la distance provoque le chargement des pages pour être perceptible (par exemple, plusieurs dixièmes de seconde), la chose que vous voulez utiliser est appcache.

La discussion appcache

Tout d’abord, lorsque vous utilisez appcache vous ne devez mettre en cache le “shell” de votre application entière, donc toute sa mise en page et la fonctionnalité, mais pas n’importe quel contenu, il peut comporter (ce qui est également expliqué dans la vidéo ci-dessus). Pour la mise en cache de contenu qui peut être pertinent de cette session, mais déjà remplacé la prochaine fois que l’utilisateur utilise l’application, vous voudrez peut-être mettre en place votre propre système de mise en cache personnalisé dans votre application, en utilisant par exemple PouchDB ou Lawnchair.

Comme cela est également mentionné dans la vidéo, Mozilla et Google collaborent pour «fixer appcache». Il y aura probablement une API plus puissant avec moins de surprises.

Le résultat de l’utilisation appcache si, une fois qu’on s’habitue aux changements déployés ne se présentent pas sur la première actualisation, est incroyable. Vos applications seront tout fonctionne, même s’il n’y a pas de connexion wifi. Et s’il ya une connexion wifi, puis elles vont se charger très rapidement, beaucoup plus rapidement, bien sûr que si vous ne les cache.

Conclusion

Désolé si cet épisode était un peu long, mais je pense que cela couvre la plupart des sujets que vous devez garder à l’esprit au sujet de l’hébergement application. Une des belles choses de web-apps Unhosted, c’est qu’ils sont si faciles à l’hôte, vous n’avez pas besoin de mettre en place un backend avec les serveurs de bases de données et cetera. Ceci les rend également très pas cher à l’hôte, par rapport à des applications web hébergé (dans le sens de contenu web «dynamique», par opposition à des contenus web «statique»).

Applications web Unhosted sont également plus faciles à reproduire pour les kill-passer résilience, et ils sont très bien comme une alternative multi-plateforme pour applications smartphone indigènes et Applications tablettes indigènes.

La semaine prochaine, nous allons mettre ensemble ce que nous avons discuté de liaison et d’hébergement, et de parler de la façon d’applications web Unhosted, le web devient lui-même un App Store. Rendez-vous donc! :)

commentaires bienvenus!