Question sur le service d'images sur App Engine (2 alternatives)

Question

plan de lancer un site de bandes dessinées qui sert des bandes dessinées (images). J'ai peu d'expérience dans le service/la mise en cache d'images.

donc ce sont mes 2 méthodes J'envisage:

1. Utilisation LinkProperty

class Comic(db.Model) 
    image_link = db.LinkProperty() 
    timestamp = db.DateTimeProperty(auto_now=True) 

Avantages: Les images sont get-ed de l'espace disque lui-même (et l'espace disque est pas cher je le prends?) Je peux facilement mettre en place app.yaml avec une date d'expiration pour mettre en cache le contenu dans le navigateur de l'utilisateur je peux mettre en place memcache pour récupérer les entités plus rapidement (pour le trafic élevé)

2. Utilisation de BlobProperty

J'ai utilisé ce tutoriel, cela a fonctionné plutôt bien. Question subsidiaire: Puis-je dire que l'utilisation de BlobProperty "protège" mes images de la liaison externe? Cela signifie que les gens ne peuvent pas juste un lien directement aux bandes dessinées

J'ai quelques soucis pour la méthode 2.

• Je ne peux évidemment memcache ces entités pour une lecture plus rapide.

Mais:

• Est-ce memcaching images une bonne chose? Mes images sont grandes (100-200kb par image). Je pense que memcache ne permet que jusqu'à 4 Go de données en cache? Ou est-ce 1 Mo par entité memcached, avec des entités illimitées ...

• Que faire si le memcache d'appengine échoue? -> Solution: Je devrais retourner au datastore.

• Comment puis-je mettre en cache ces images dans le navigateur de l'utilisateur? Si je faisais la méthode non. 1, je pourrais simplement ajouter à mon app.yaml la date d'expiration pour le contenu, et les images sont mises en cache côté utilisateur.

aimerait entendre vos pensées. Devrais-je utiliser la méthode 1 ou 2? La méthode 1 semble simple et directe, devrais-je m'en méfier?

[EDITED] Comment résoudre ce dilemme? Dilemme: La dernière chose que je veux faire est d'empêcher les gens d'obtenir le lien direct vers l'image et de le mettre en place.parce que l'utilisateur sera automatiquement dirigé uniquement vers l'image sur mon serveur (et non la publicité/le contenu qui l'entoure si l'utilisateur y avait accédé depuis la page principale elle-même)

Answer 1

En termes de résolution de votre dilemme, je pense qu'il ya deux alternatives:

• vous pourriez causer des images à rendu dans un objet flash qui télécharger les images de votre serveur dans une sorte de format crypté que il savoir comment décoder. Cela impliquerait beaucoup de travail à l'avance.

• vous pouvez avoir un lien valide-unique pour l'image. Chaque fois que vous a généré la page Web avoisinante, le lien vers l'image serait généré de manière aléatoire, et le code de service invaliderait ce lien après lui avoir accordé une seule fois. Si vous avez un site Web très fréquenté, il s'agirait d'un système très gourmand en ressources.

Vraiment, si, vous voulez examiner à quel point le travail, il vaut la peine de forcer les gens à voir des annonces, en particulier quand un bon nombre d'entre eux seront à venir sur votre site via Firefox, et il n'y a presque rien vous pouvez faire pour contourner AdBlock.

En termes de choix entre vos deux méthodes, il y a deux choses à penser. Avec l'option 1, où sont stockées les images en tant que fichiers statiques, vous ne pourrez ajouter de nouvelles images qu'en faisant appcfg.py mettre à jour. L'application AppEngine ne vous permettant pas d'écrire sur le système de fichiers, vous devrez ajouter de nouvelles images à votre code de développement et effectuer un déploiement de code. Cela pourrait être difficile du point de vue de la gestion du site. De plus, le fait de servir les images de memcache ne vous offrira probablement pas de meilleures performances que de les faire servir de fichiers statiques. Votre seconde option, en plaçant les images dans le magasin de données, protège vos images de la liaison uniquement dans la mesure où vous avez le pouvoir de contrôler par la logique si elles sont servies ou non. Le problème que vous rencontrerez est que prendre cette décision est difficile. Rappelez-vous que HTTP est sans état, donc trouver un moyen de distinguer une requête d'un lien externe à votre application et d'une requête interne à votre application va nécessiter une supercherie.

Mon sentiment personnel est que sauter par des cerceaux pour s'assurer que les gens ne peuvent pas voir vos bandes dessinées avec des annonces voit la résolution du prolbem dans le mauvais sens. Si le contenu que vous publiez vaut la peine d'être protégé, les gens accèderont à votre site Web pour en profiter quand même. Grâce aux volumes élevés de trafic, vous compenserez largement ceux qui se connectent directement à votre image, évitant ainsi quelques publicités. N'essayez pas de surpasser vos consommateurs. Offrir un contenu exceptionnel, et vous ferez beaucoup d'argent.

Answer 2

Vous allez utiliser beaucoup de bande passante pour transférer toutes ces images du serveur vers les clients (navigateurs). Rappelez-vous qu'appengine a un nombre maximum de fichiers que vous pouvez télécharger, je pense que c'est 1000, mais il peut avoir augmenté récemment. Et si vous voulez contrôler l'accès aux fichiers, je ne pense pas que vous pouvez utiliser l'option # 1. L'option 2 est bonne, mais votre bande passante et vos coûts de stockage vont être élevés si vous avez beaucoup de contenu. Pour résoudre ce problème, les utilisateurs se tournent généralement vers les réseaux de diffusion de contenu (CDN). Amazon S3 et edgecast.com sont deux CDN prenant en charge les URL d'accès par jeton.C'est-à-dire que vous pouvez générer un jeton dans votre application appengine, que ce soit pour l'adresse IP, l'heure, la géographie et d'autres critères, puis donner votre jeton cdn avec ce jeton au demandeur. Le CDN sert vos images et effectue les vérifications d'accès en fonction du jeton. Cela vous aidera à contrôler l'accès, mais souvenez-vous que s'il y a une volonté, il y a un moyen et vous ne pouvez rien garantir à 100% - mais vous êtes probablement raisonnablement proche. Donc, au lieu de stocker le contenu dans appengine, vous le stockez sur le cdn, et utilisez appengine pour créer des URL avec des jetons pointant vers le contenu du cdn.

Voici quelques liens sur les URLs signés. Je l'ai utilisé ces deux:

http://jets3t.s3.amazonaws.com/toolkit/code-samples.html#signed-urls

http://www.edgecast.com/edgecast_difference.htm - regardez « Content Security »

Answer 3

Votre méthode # 1 est pas pratique: Vous auriez besoin de télécharger une nouvelle version de votre application pour chaque nouvelle bande dessinée.

Votre méthode n ° 2 devrait fonctionner correctement. Il ne protège pas automatiquement vos images contre les liens hypertextes - ils sont toujours diffusés sur une URL comme toute autre image - mais vous pouvez écrire le code que vous voulez dans le gestionnaire de diffusion d'images pour essayer d'empêcher les abus.

Une troisième option, et une variante de # 2, consiste à utiliser le new Blob API. Au lieu de stocker l'image elle-même dans le magasin de données, vous pouvez stocker la clé blob et votre gestionnaire d'image indique simplement à l'infrastructure de blobstore quelle image doit être diffusée.