Puis-je convertir un serveur HTTP en serveur HTTPS ?

serveur hébergé sans service dédié - Quelle est cette techno ?

Le problème exposé dans ce sujet a été résolu.

Bonjour !

Je viens pour un problème qui aurait pu être résolu en utilisant un serveur d’hébergement web, mais comme j’ai fini mon sujet de stage en 8 semaines au lieu de 16, mon tuteur a dit "non, on va complexifier le truc"… Moi qui comptait profiter de mes vacances… :'( tant pis :´D

J’ai développé un site web pour déployer un modèle d’IA, qui a en particulier besoin d’accéder à la caméra. Tout fonctionne bien quand je le met sur mon propre serveur, hébergé par o2switch, donc plus de web ou autre à faire maintenant, juste du serveur !
mon tuteur m’a demandé d’utiliser un truc qu’on a au bureau : Une board de développement utilisant une puce FPGA Microchip PolarFire avec ISA RISC-V. Le fait que ce soit une Rolls n’est pas important ici. Ce qui est important, c’est qu’il y a tout ce qu’il faut pour faire fonctionner un serveur… http : Depuis le client, impossible de forcer une connexion sécurisée, ce qui empêche le fonctionnement de mon site web (caméra…)
J’ai passé mon week-end à fouiller la mémoire de la board pour comprendre comment faire fonctionner le serveur. J’ai trouvé, mais je bute sur cette connexion sécurisée. Le nom même de l’exemple me crie que c’est pas possible dans l’état : "iioHTTPserver", j’ai pas le 's’ de "Secure". ce nom ne donne rien sur Google, ça me suggère "iishttpserver" donc bof.
Peut-être que identifier la techno utilisée par le serveur sera une meilleure piste ? Malheureusement la doc ne me donne pas les infos, juste une succession d’instructions pour faire fonctionner le serveur. C’est justement ce qui m’a pris du temps pour mettre mes propres fichiers HTML dessus et y accéder avec le client. Ça a été des interprétations du code que je voyais, et de l’essai erreur. Du coup là j’aurai bien besoin d’aide pour trouver le nom de la techno. Ensuite je pourrai essayer de chercher des infos pour traficoter tout ça et forcer le HTTPS. Tout fonctionne avec des scripts python : run.py, config.py… J’ai en particulier un script, views.py que j’ai qui me semble le plus intéressant, car c’est le seul qui fait appel à des lib et il gère les chemins des pages, les compositions…

import csv
import glob
import os

from flask import render_template
from flask import jsonify
from app import app

@app.route('/')
def index():
    return render_template("index.html")

Les fichiers html de l’exemple ont aussi un truc qui m’intéresse :

{% extends "base.html" %}

{% block title %}Home
{% endblock %}

{% block body %}
    <div class="jumbotron">
        <h1>Icicle Kit Voltage/Current Analytics</h1>
        <p class="lead">Monitors the Voltage/Current on Icicle Kit</p>
    </div>
{% endblock %}

Dès la ligne 1 ! {% extends "base.html" %} Ça à le même comportement sur lequel je m’interrogeait dans un autre sujet il y a quelques semaines, à savoir faire un entête sur une page à part et l’importer partout !

Est-ce que ces éléments peuvent permettre de trouver la techno qui est utilisée pour faire fonctionner le serveur ?
Autre question qui a un intérêt plus personnel… Est-ce que ce fonctionnement en Python est déployable sur n’importe quel serveur FTP, comme ceux hébergé par o2switch par exemple ? (Je voudrai bien faire ça plutôt qu’apprendre PHP j’avoue, et c’est bien plus limpide qu’un fichier htaccess pour moi) Ou est-ce qu’il faut déployer autre chose sur le serveur, à trop bas niveau pour que les hébergeurs laissent faire ? … Enfin faudrait demander directement au service client, mais pour ça faut que je puisse nommer ce dont je leur parlerai. :/

+0 -0

Est-ce que ces éléments peuvent permettre de trouver la techno qui est utilisée pour faire fonctionner le serveur ?

On peut voir des appels à Flask qui est un server web python, je suppose que c’est la techno utilisé, même si je n’ai pas compris le paragraphe sur ton système embarqué. Flask a besoin d’un programme de server web qui communique avec lui au travers WSGI, qui va gérer le côté système du serveur (ouvrir les ports, chiffrer les données —> support du https …). Je suppose que c’est le rôle de "iioHTTPserver".

Dès la ligne 1 ! {% extends "base.html" %} Ça à le même comportement sur lequel je m’interrogeait dans un autre sujet il y a quelques semaines, à savoir faire un entête sur une page à part et l’importer partout !

Effectivement, il s’agit du moteur de template dont on parlait dans l'autre sujet, Jinja. Flask fait appelle à Jinja pour générer les pages avant de les envoyer au client.

Pour passer en https moi j’ai fait le choix de mettre un server Caddy en proxy qui gère ça par défaut. Mais pour le faire manuellement, je sais juste que tu vas avoir besoin d’un certificat que tu peu avoir en mettant en oeuvre Let’s encrypt. Cependant si ton serveur "iioHTTPserver" n’a pas de fonctionnalité SSL/TLS, ça va devenir compliqué.

+0 -0

Je ne comprends pas. Flask supporte HTTPS sans problème.

Ton WSGI doit supporter HTTPS si tu veux l’utiliser (car c’est à lui de gérer l’HTTPS si tu utilises un WSGI).

Si tu n’utilises pas de WSGI:

https://kracekumar.com/post/54437887454/ssl-for-flask-local-development/ (L’article n’est pas idéal mais illustre les étapes importantes).

Mais oui, la clé du problème est dans l’étude des possibilités du WSGI que tu utilises. Tu peux peut-être également en changer ? Je n’ai pas compris cette histoire d’hébergement web. iioHTTPserver est certainement un truc à vous, car je n’ai aucune correspondance dans GitHub.

+0 -0

Je ne comprends pas. Flask supporte HTTPS sans problème.

Ca j’en doute pas. Au stade où j’en suis, c’est que du code, rien de matériel, donc tout est possible. Mais la démo que j’ai, "iioHTTPserver", ne l’a pas configuré de base. Et moi-même j’avais jamais été amené à toucher à ça, donc découverte !
Cette "démo" est un exemple d’utilisation de la board, certainement pas un truc courant. Il est courant, quand t’as un kit pour programmer une puce et faire des tests dessus (du moins courant pour le peu que j’ai vu en tant qu’étudiant) qu’elles soient livrées avec divers exemples d’utilisations - plus ou moins bien documentés.
"iioHTTPserver" Est l’exemple qui permet de montrer comment faire tourner un serveur HTTP sur la puce. "HTTPserver" ça va pour comprendre. "iio", je le trouve pas écrit noir sur blanc, mais si ça suit la même logique de nomenclature que ce que j’ai vu jusqu’à maintenant, ça doit être pour "Industrial Input / Output". Donc en gros l’exemple sert à montrer comment faire communiquer la puce avec ce qu’il y a dans l’usine via des requêtes HTTP. (Attention : interprétation de ma part) M’enfin je suis pas sûr que ce soit pertinent… Je veux dire, que ce soit dans l’usine (fermée), ça justifie pas pour moi qu’on se passe d’une couche de sécurisation.

[…] même si je n’ai pas compris le paragraphe sur ton système embarqué.

C’était pour explique que j’étais pas sur un service commercial classique et donc que…

Mais pour le faire manuellement, je sais juste que tu vas avoir besoin d’un certificat que tu peu avoir en mettant en oeuvre Let’s encrypt.

J’ai pas le bouton magique "Let’s Encrypt™ SSL" d’un hébergeur commercial. Mais je reconnais que tous les détails étaient pas nécessaires, puisque dans mon contexte c’est juste un proco qui fait tourner un linux, et je sors pas de l’OS. Et avec ton lien je vois que c’est un service gratuit, et il y a une doc, donc j’ai pas besoin du bouton.

Enfin, entre ça et le fait que je veux juste héberger un site web, je pense pouvoir dire sans trop me tromper qu’il y a rien d’exceptionnel et que la partie "iio" peut être ignorée. Il y a juste des trucs à apprendre.

L’article que tu link m’a l’air très utile, Ache, d’autant plus que je trouve absolument aucune mention du WSGI en parcourant tous les fichiers un à un. Avoir le nom de Flask et SSL m’a aussi permis de googler un peu, et te tomber sur un autre post qui suggère ceci :

from flask import Flask
from flask_sslify import SSLify

app = Flask(__name__)
sslify = SSLify(app)

(J’ai le droit de linker un autre forum ??)

Je vais essayer tout ça dès je retourne au bureau.

Effectivement, il s’agit du moteur de template dont on parlait dans l’autre sujet, Jinja. Flask fait appelle à Jinja pour générer les pages avant de les envoyer au client.

Ah ouai ? trop bien, ça m’a l’air fort intuitif en plus. Si Flask + Jinja, peut m’épargner le PHP et le fichier .htaccess, quand je rentre de mon stage je fait un serveur sur un rasp pour faire mes tests.

En fait, Flask c’est déjà un ensemble de bibliothèques.

Tu as werkzeug, Jinja et click intégrés directement.
Flask, c’est juste une intégration de ces trois trucs ensemble.

+1 -0

dans mon contexte c’est juste un proco qui fait tourner un linux, et je sors pas de l’OS.

tsuruba

Ah voilà une info qui manquait bien, tu fais tourner un linux embarqué. Mais du coup tout va bien, tu devrais pouvoir remplacer ton programme serveur.
Je comprenais pas parce que lorsqu’on me parle de FPGA généralement c’est pas pour s’en servir comme processeur, donc on code pas en python dessus. Mais du coup j’imagine que c’est un FPGA architecturé en RISC-V et intégré avec une mémoire, une puce réseau etc…

(J’ai le droit de linker un autre forum ??)

tsuruba

Oui

Ah ouai ? trop bien, ça m’a l’air fort intuitif en plus. Si Flask + Jinja, peut m’épargner le PHP et le fichier .htaccess, quand je rentre de mon stage je fait un serveur sur un rasp pour faire mes tests.

tsuruba

En fait il faut voir Python avec des frameworks comme Flask/Django/Bottle… comme un remplaçant à PHP : c’est la partie applicative du serveur web. Généralement on préfère garder un serveur web en service système tel que Apache/Nginx/Caddy… car ils ont des fonctionnalités plus avancés, un code plus mature, et ton application n’est généralement pas la seule à être desservie sur la machine.
Donc dans ce cas de figure, tu dois configurer le serveur web pour lui dire où trouver l’application et comment la desservir, et en utilisant Apache ça se fait avec .htaccess, en utilisant Caddy c’est le Caddyfile etc…
Ce n’est pas la techno PHP qui le demande c’est le fonctionnement du serveur web, l’interface entre le service système et le programme applicatif. Et cette interface entre ces deux programmes justement, pour python c’est le WSGI comme pour le PHP c’est le FastCGI.
Le WSGI en résumé c’est simplement la définition de l’interface que le programme a pour pouvoir être appelé depuis un autre. C’est à dire le nom des fonctions d’entrée, les arguments qu’elles prennent et quelles valeurs sont autorisés, et les valeurs de retour possible.

Cependant, vu que Python est un langage très complet, il est possible d’y intégrer directement la programmation système nécessaire au server web, et c’est ce qu’a fait Flask. Il est ainsi possible de le faire tourner le serveur tout seul, mais tu ne profiteras pas des avantages qu’apportent Apache et consorts. C’est pour ça que le lien de Ache ne parle pas de WSGI, puisqu’il utilise Flask directement comme serveur web, il n’y a pas d’interface avec un autre programme.

Je savais que c’était possible de les faire tourner tout seul, mais je ne pensais pas que c’était production-ready, je croyais qu’il fallait toujours les accompagner d’un soft server. Mais je ne suis pas du tout expert web.

+1 -0

Ah voilà une info qui manquait bien, tu fais tourner un linux embarqué. Mais du coup tout va bien, tu devrais pouvoir remplacer ton programme serveur.
Je comprenais pas parce que lorsqu’on me parle de FPGA généralement c’est pas pour s’en servir comme processeur, donc on code pas en python dessus. Mais du coup j’imagine que c’est un FPGA architecturé en RISC-V et intégré avec une mémoire, une puce réseau etc…

C’est effectivement un FPGA avec une architecture RISC-V, et plein de trucs à côté. Mais j’en parle pas car j’en suis encore à essayer de comprendre le rapport entre d’une part une matrice de portes ET/OU and co. et d’autre part une ISA qu’on m’a été présentée comme une alternative à x64, pour pas qu’on me pose une colle à ma soutenance.

Mais ouai, du coup j’ai un peu galéré, j’ai employé les méthodes de Ache avec les certificats auto-généré (du coup le navigateur il me met un gros warning car des pirates essaient de voler mes données X´D ) Mais au moins ça fonctionne !

J’ai un dernier détail à régler qui vient peut-être de Flqsk justement ? est-ce que c’est lui aussi qui gère les liens et les images sur une page ? Car tout fonctionne comme attendu en local, mais dès que c’est sur le serveur Flask, les images sont impossibles à charger, et le seul lien vers une autre page du site est mort. Cette autre page à bien été ajoutée au fichier views.py, ce qui me permet d’y acccéder avec 'https://192. … :432/conditions’ mais le lien, rien à faire. quant aux images la console associée au serveur me donne ""GET /ressources/logo_1.svg HTTP/1.1" 404 -". Tous les fichiers sont bien à leur place, et même les chemins absolus copiés-collés ne suffisent pas. C’est pour ça qu je pense à Flask…

En fait il faut voir Python avec des frameworks comme Flask/Django/Bottle… comme un remplaçant à PHP : c’est la partie applicative du serveur web. Généralement on préfère garder un serveur web en service système tel que Apache/Nginx/Caddy… car ils ont des fonctionnalités plus avancés, un code plus mature, et ton application n’est généralement pas la seule à être desservie sur la machine. Donc dans ce cas de figure, tu dois configurer le serveur web pour lui dire où trouver l’application et comment la desservir, et en utilisant Apache ça se fait avec .htaccess, en utilisant Caddy c’est le Caddyfile etc… Ce n’est pas la techno PHP qui le demande c’est le fonctionnement du serveur web, l’interface entre le service système et le programme applicatif. Et cette interface entre ces deux programmes justement, pour python c’est le WSGI comme pour le PHP c’est le FastCGI.

OK je comprends mieux, et donc comme les hébergeurs gèrent plusieurs clients, ils peuvent pas se permettre de laisser chaque client choisir individuellement Apache, Caddy…
Bon j’ai fouillé l’interface cPanel fournie par l’hébereur, et il y a une partie qui parle d’applications python. Ils ont peut-être mis en place des trucs supplémentaires pour depuis Apache faire tourner un environnement Python…

Tu as werkzeug, Jinja et click intégrés directement [dans Flask].

C’est pour ça alors qu’en parcourant mes fichiers je ne trouvais pas de mention du WSGI ? Car Flask le gère en interne avec werkzeug ??

+0 -0

Mais ouai, du coup j’ai un peu galéré, j’ai employé les méthodes de Ache avec les certificats auto-généré (du coup le navigateur il me met un gros warning car des pirates essaient de voler mes données X´D ) Mais au moins ça fonctionne !

Alors si ça marche avec un certificat autogénéré, il n’y a aucune raison que ça ne marche pas avec un certificat généré avec Let’s encrypt.

C’est pour ça alors qu’en parcourant mes fichiers je ne trouvais pas de mention du WSGI ? Car Flask le gère en interne avec werkzeug ??

Oui :) ! Mais du coup, c’est un serveur de développement. Je te laisse parcourir la page Serving WSGI Applications de Werkzeug (c’est vraiment moche l’allemand :-° ).

J’attire ton attention sur le Warning de la page:

Do not use the development server when deploying to production. It is intended for use only during local development. It is not designed to be particularly efficient, stable, or secure.

GET /ressources/logo_1.svg HTTP/1.1" 404 -". Tous les fichiers sont bien à leur place, et même les chemins absolus copiés-collés ne suffisent pas. C’est pour ça qu je pense à Flask…

404 c’est que les fichiers ne sont pas bien à leur place. :p
Flask gère ça bien sûr. Il doit y avoir un truc que tu ne fais pas bien. Sans plus d’info, impossible de t’aider.

/ressources/logo_1.svg ça signifie que l’image doit être dans un dossier ressources à la racine (la racine étant l’endroit où tu as ton dossier python). Avec le code on pourra certainement plus t’aider mais soit assurer que c’est toi qui utilise mal quelque chose pas Flask qui bug.

+1 -0

Do not use the development server when deploying to production. It is intended for use only during local development. It is not designed to be particularly efficient, stable, or secure.

Je ferai attention. de toute manière pour déployer un truc j’ai toujours l’hébergeur, parce que bon déployer un site sur un serveur chez moi, sur ma box… Je sais pas le rendre accessible hors de mon réseau local, je sais pas y associer une url, et il y a des entreprises dont c’est le métier. :’D

404 c’est que les fichiers ne sont pas bien à leur place. :p

Mais justement, c’est là qu’est l’os, car quand je parcours mon arbo à coup de $cd je trouve les choses là où je les attends. Et ce, peu importe que je donne un chemin relatif à mon fichier html, ou absolu depuis la racine de la mémoire de la board.

/ressources/logo_1.svg ça signifie que l’image doit être dans un dossier ressources à la racine (la racine étant l’endroit où tu as ton dossier python).

Le "dossier python" c’est là où python est installé, ou là où il y a les fichiers python pour faire tourner le serveur ? C’est vrai que j’ai pas essayé cette option. :/

Avec le code on pourra certainement plus t’aider mais soit assurer que c’est toi qui utilise mal quelque chose pas Flask qui bug.

Oui t’en fait pas, autant j’aime râler sur les lib JS et JS itself, autant python et ses librairies je suis pas de mauvaise foi (surtout Flask, entre l’ancienneté, le nombre d’utilisateurs sur GitHub, et le fait qu’il soit toujours maintenu, c’est pas moi qui vais trouver un bug X’D )
Le code il est simple, j’ai fini par tout virer. C’est un truc que je fait quand ça marche pas, je vire tout pour me concentrer sur ce qui fait autre chose que ce à quoi je m’attends. là mon fichier est réduit à :

<html lang="fr">
    <head>
        <meta charset="utf-8"/>
        <title>stage IA web</title>
        <!-- JS -->
            <!-- API -->
            <script src="https://docs.opencv.org/master/opencv.js" type="text/javascript"></script>

            <!-- Scripts personnels -->
            <script src="../static/js/webcam.js"></script>
            <script src="../static/js/prod.js"></script>
            <script src="../static/js/model.js"></script>

        
        <!-- CSS -->
        <link rel="stylesheet" href="../static/css/collect.css">
        <link rel="stylesheet" href="../static/css/prod.css">
    </head>
    <body>

        <main>
            <img src="ressources page/logo_1.svg" alt="logo">
        </main>
    </body>
</html>

Bon, pour ma défense, j’ai pas pensé à indiquer le chemin vers l’image à partir des fichiers python du serveur parce que les scripts JS sont indiqués relativement au html et ça fonctionne.

  • iiohttpserver/
    • app/
      • static/
        • css/
          • collect.css
        • js/
          • webcam.js
      • templates/
        • ressources page/
          • logo_1.svg
        • prod.html
        • conditions.html
      • __init__.py
      • views.py
    • run.py
    • config.py

(Arbo partielle pour pas trop flood)

+0 -0
            <script src="../static/js/model.js"></script>

Je ne sais pas à quoi tu t’attends mais ça ne marche pas comme tu penses que ça marche. ^^"

Quand on mets ../ au début d’une URL (ou même ./) c’est simplement supprimé. Y a pas de retour arrière comme dans un système de fichier.

Tu peux simplement les supprimer ça marchera avec Flask.

Dans ton cas, à partir de cette ligne:

            <img src="ressources page/logo_1.svg" alt="logo">

Il te faudrait un dossier ressources page au même niveau que ton dossier static, c’est à dire dans le dossier app. À l’intérieur il te faut le fichier logo_1.svg.

Tu manques un peu de pratique HTML. Ça viendra avec le temps.

+0 -1

Je ne sais pas à quoi tu t’attends mais ça ne marche pas comme tu penses que ça marche. ^^"

Quand on mets ../ au début d’une URL (ou même ./) c’est simplement supprimé. Y a pas de retour arrière comme dans un système de fichier.

ache

Euh, si, c’est parfaitement valide de mettre des .. et ça marche très bien (c’est interprété par le navigateur), ça permet de remonter d’un cran dans le chemin de l’URL.

Euh, si, c’est parfaitement valide de mettre des .. et ça marche très bien (c’est interprété par le navigateur), ça permet de remonter d’un cran dans le chemin de l’URL.

Effectivement, j’en fait que depuis ~2 ans, et pas tous les jours. Mais je confirme que ../ avait toujours fonctionné jusqu’à maintenant, pour aller chercher des ressources à des adresses relatives au fichier HTML.
Dans ce cas, si ça ne fonctionne pas, je pense que c’est du fait de Flask, car j’ai tenté deux choses naïvement :

  • changer mes liens vers d’autres pages du site : au lieu d’avoir "chemin/vers/conditions.html" j’ai "/conditions" pour que ça corresponde à la ligne @app.route('/conditions') du fichier views.py; -j’ai mis le dossier ressources1 dans le dossier static pour avoir un chemin d’accès de la même forme que pour les fichiers JS et CSS.

Tout fonctionne ! Je ne peux qu’en déduire que Flask impose ce comportement, peut-être pour des processus internes ? Ou par s’assurer que peu importe comment on accède à une page, elle ait tout le temps la même URL (ip/conditions systématiquement, et pas ip/templates/conditions.html par exemple, comme j’aurai pu avoir quand je n’utilisais pas Flask). Du coup c’est pas vraiment un problème, il faut juste le savoir et c’est bon, donc

Tu manques un peu de pratique HTML. Ça viendra avec le temps.

Oui complètement. ^^

J’ai aussi supprimé les ../ pour voir, effectivement ça fonctionne sans, comme si la racine était marquée par le fichier views.py, et qu’il était impossible de remonter.

Maintenant, si je comprend bien tout ce que j’ait jusqu’à maintenant, Utiliser Flask, ça revient à communiquer avec un programme Python via des commandes qui sont passées par URL (https://ip = commande pour la page de base, htpps://ip/conditions = commande pour une autre page…) qui renvoie un seul fichier html qu’il a monté à partir des templates, et éventuellement les fichiers JS / images… Et tout ça se met en place en remplaçant le système par défaut qui me semble laisser le client se balader dans les différents fichiers du serveur (là ip/templates/conditions.html me fait l’erreur 404, alors que ça fonctionne sur mon serveur 'normal’.) Je me trompe ?

1 j’ai eu une confusion entre ce dont je me souvenais en écrivant mes précédentes réponses chez moi et ce que j’ai fait au bureau : J’avais remplacé partout ressources page par ressources, au cas où l’espace était la cause de mes soucis : c’était pas le cas, mais je ne suis pas revenu en arrière. désolé pour la confusion.

OK je comprends mieux, et donc comme les hébergeurs gèrent plusieurs clients, ils peuvent pas se permettre de laisser chaque client choisir individuellement Apache, Caddy…

tsuruba

Mouais, y’aurais des solutions pour faire tourner plusieurs types de serveur. Ces structures ont plusieurs machines, et même sur une machine, y’a de la virtualisation ou de la containerization. La plupart arrive à vendre des VPS, sur lesquels tu fais ce que tu veux, c’est bien que c’est pas la technique qui bloque.
Je pense que c’est surtout que lorsqu’on loue un hébergeur (en milieu pro) c’est pas pour se taper les tâches de configuration de la machine et de maintenance/disponibilité de la machine. Alors on délègue en se payant ce service auprès des hébergeurs, et ça nous permet de nous concentrer sur notre application, qui est vraiment notre produit. Les hébergeurs ne proposent donc pas ces choix car ce n’est pas le besoin.

Bon j’ai fouillé l’interface cPanel fournie par l’hébereur, et il y a une partie qui parle d’applications python. Ils ont peut-être mis en place des trucs supplémentaires pour depuis Apache faire tourner un environnement Python…

tsuruba

Oui Apache supporte WSGI.

Mais justement, c’est là qu’est l’os, car quand je parcours mon arbo à coup de $cd je trouve les choses là où je les attends. Et ce, peu importe que je donne un chemin relatif à mon fichier html, ou absolu depuis la racine de la mémoire de la board.

tsuruba

Ce ne sont pas des chemins de ton système de fichier. Ce sont des chemins que le client va demander à ton serveur web. Ton serveur web va les interprêter pour trouver la ressource correspondante. Ce sont les "routes". Je sais pas comment fonctionne flask à ce niveau là mais généralement les routes sont explicitement décrites dans un fichier ou dans le code. Comme Flask est un framework qui se veut très simple et straightforward, il est possible que les routes soient un mirroir de l’arborescence de fichier du dossier app. Mais c’est Flask qui aura routé tout ça.

En bref, je pense que tu devrais lire la doc de flask et surtout faire le getting started avec les exemples d’applications minimales pour comprendre comment ça fonctionne.

EDIT : Ah voilà t’as vu que Flask décrit les routes par le décorateur @app.route('truc'). Fais quand même le getting started de Flask !

  • j’ai mis le dossier ressources1 dans le dossier static pour avoir un chemin d’accès de la même forme que pour les fichiers JS et CSS.

De toute façon c’est plutôt là que ça aurait toujours dû être.

Tout fonctionne ! Je ne peux qu’en déduire que Flask impose ce comportement, peut-être pour des processus internes ?

Flask n’impose pas ça, il a juste suivi ce que le code lui a décrit. Mais tu peux le modifier. C’est juste que tu as récupéré quelque chose que tu ne comprenais pas.

+0 -0

EDIT : Ah voilà t’as vu que Flask décrit les routes par le décorateur @app.route(’truc’). Fais quand même le getting started de Flask !

Eh bien mon sujet de stage étant fini - jusqu’à ce que mon tuteur me donne une autre tâche - je vais ça, plutôt que de faire mes propres projets sur mon temps de travail. Maintenant que t’en parle, je me dit que c’est peut-être ce que j’aurai dû faire dès que tu m’a dit que ça tournait avec Flask. ^^

Merci à tout le monde pour l’aide ! :D

Je ne sais pas à quoi tu t’attends mais ça ne marche pas comme tu penses que ça marche. ^^"

Quand on mets ../ au début d’une URL (ou même ./) c’est simplement supprimé. Y a pas de retour arrière comme dans un système de fichier.

ache

Euh, si, c’est parfaitement valide de mettre des .. et ça marche très bien (c’est interprété par le navigateur), ça permet de remonter d’un cran dans le chemin de l’URL.

entwanne

J’ai pas dis que .. n’était pas interprété. J’ai dis qu’au début d’une URL c’était supprimé par le navigateur. Je confirme que c’est bien le cas, c’est le processus de normalisation qui fait ça.

Bien-sûr, si ton URL possède déjà un chemin, alors l’URL, puisque relative, va être la concaténation (la fusion) du chemin courant avec le chemin relatif. Du coup, le .. n’étant pas au début, elle est interprété.

Bref, j’ai l’impression que vous le faite exprès. L’idée c’est que le .. n’est pas relative au système de fichier. Tu ne peux pas remonter le système de fichier hors de ta racine avec ... J’ai l’impression que l’OP fait la confusion alors je lui ai fait la remarque.

Je n’ai pas vraiment le temps de répondre plus malheureusement.

+0 -0

Oui j’avais pas compris que la racine à prendre en compte était pas celle du système, mais maintenant c’est bon. Le serveur va prendre en compte une autre racine (je dirai le dossier app car si je pars du principe que je suis déjà dans static alors ressources n’est pas trouvé), et pas possible de remonter plus haut, d’où "l’annulation" du ../ au début dans ce cas précis, qui n’est pas celui que je connaissais jusqu’à maintenant. C’est bon maintenant. :)

Le serveur Flask va plutôt avoir un « système de fichiers » virtuel qui lui est propre et qui n’est pas spécialement liée à celui du système ou à un répertoire particulier.
Il s’agit juste d’un ensemble de routes (chemins) que Flask sait associer à des ressources et peut donc renvoyer lorsqu’on les lui demande par des requêtes HTTP. Mais ces ressources sont complètement décorellées du disque (il peut s’agir de pages générées à la volée par exemple) même si Flask dispose d’outils pour mapper des routes à un répertoire static (et donc rendre accessibles les fichiers de ce répertoire).

Maintenant, les .. dans une URL fonctionnent de la même manière que pour un système de fichiers : ça permet de remonter jusqu’à la racine (mais pas au-delà, ce qui n’aurait pas de sens). Mais Flask recevra lui des requêtes HTTP et devra identifier les ressources pointées par les chemins.

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte