Bonjour

J'essaye l'hébergement de mon site chez scalingo, qui propose de déposer son application chez Github. Je découvre donc le monde de l'open source.

Je vais hascher les mots de passe de mes abonnés, mais comment faire avec celui nécessaire à l'authentification pour l'envoi de mails ? On ne peut l'écrire en dur dans le code source, visible par tous, il faut donc le transmettre crypté à la fonction qui l'utilise. On m'a conseillé divers modules qui s'occupent de ça. Mais ces modules eux aussi sont publics. Comment ça marche, le cryptage par un module auquel tout le monde peut accéder ?

-
Edité par zakod 1 octobre 2022 à 15:39:41

Tu travailles avec quel framework ?

Bonjour fred. Mon appli est écrite avec Bottle.

Il faut que tu crées un fichier d'environnement que tu chargeras avec un module tel que dotenv et où tu appelleras tes variables d'environnement avec os.getenv(...)

Le fichier doit être caché, par exemple nommé .env et tu dois le placer dans ton fichier .gitignore afin de ne pas être pris en compte sur github. Par contre il faudra qu'il soit évidemment dans les fichiers hébergés par scalingo.

Bonjour Fred, et merci. Je crois que tu me permets là de résoudre mon problème ! J'ai vu que ce cas du mot de passe est en exemple dans la doc de dotenv. Scalingo m'a déjà donné l'occasion de rencontrer les variables d'environnement, pour le port du serveur Bottle. Il faudra demain que j'apprenne comment on place des fichiers sur scalingo qui ne sont pas pris en compte sur Github, car pour l'instant, tout ce que je charge vient du repository Github.

Voici le lien de mon site, provisoire, car mon nom de domaine (vaste-programme.fr) est en cours de propagation depuis LWS. Je ne sais pas pourquoi, le bouton pour insérer un lien est inactif.

https://vaste-programme.osc-fr1.scalingo.io/

Et voici mon repository :

https://github.com/Zakod/librerie

-
Edité par zakod 2 octobre 2022 à 12:16:04

Tout à fait, l'équivalent sur un hébergeur au fichier .env est d'y intégrer dans leur service tes variables d'environnement, qui seront pour un de leur serveur Unix l'équivalent à utiliser la commande export.

Tu pourras donc récupérer les valeurs de ces variables de la même façon que localement avec os.getenv

C'est fait ! Ça marche en local, demain je pousse le tout sur Github. Et je n'avais pas encore songé à utiliser gitignore. Je vais y mettre le .env, donc, bien que je pige pas encore comment je vais le trouver vu qu'il est caché ! Et je mettrai aussi la base de données, ce qui règle la question de sa sécurité, enfin je l'espère. 

Et j'ai haché les mots de passe utilisateur.

Merci encore, et bonne soirée à toi !

zakod a écrit:

Je vais y mettre le .env, donc, bien que je pige pas encore comment je vais le trouver vu qu'il est caché !

J'ai pas compris, c'est toi qui crée le .env sur ton local, et quand tu versionnes sur Github, il faut éviter d'y voir ton fichier .env, voilà pourquoi on y ajoute ce nom de fichier dans le fichier .gitignore, lui aussi créer dans tes fichiers locaux.

-
Edité par fred1599 3 octobre 2022 à 11:09:09

J'ai un peu de mal avec le github desktop que j'ai téléchargé. Quand je le démarre, il débute avec un message d'erreur, si je clique sur move and restart, ça plante. alors je clique sur not now, et là, effectivement, je vois les modifs faites dans mon répertoire-clone, que je n'avais d'ailleurs pas encore utilisé, il contenait juste le readme. Maintenant, il contient deux codes sources que j'ai modifiés et que je compte envoyer chez moi à scalingo, et un dossier gitignore que j'ai créé (sans point), et dans lequel il y a le .env, qui oui, est visible.

Je résume pour voir si j'ai bien compris : il faut que je fasse un dossier .gitignore qui lui aussi sera caché, contenant le .env, et les autres fichiers que je souhaite ne pas montrer : la base de données, et un ou deux autres trucs, que je devrai donc retirer du root. Correct ?

Ah ! Et j'ai encore un message, qui concerne .DS_Store : this binary file has changed. Avec un lien pour open file in external programme, et je pige pas de quoi il s'agit.

Dans mon répertoire-clone, j'ai voulu mettre un point devant gitignore. Ça refuse, c'est réservé au système. Pour le .env, j'avais eu "si tu fais ça, il sera caché, "avec demande de confirmation. Mais pour le dossier gitignore, c'est impossible.

_____Edit 14:05

Je crois que j'avais pas bien compris : .gitignore, c'est un fichier, pas un dossier. Et chaque ligne concerne les fichiers à ne pas prendre en compte dans le dépôt. 

Ça donnerait comme contenu de .gitignore :

.env

vaste-programme.db

et autres...

C'est bien ça ?

-
Edité par zakod 3 octobre 2022 à 14:09:44

zakod a écrit:

il faut que je fasse un dossier .gitignore

Non un fichier, pas dossier !

zakod a écrit:

qui lui aussi sera caché, contenant le .env, et les autres fichiers que je souhaite ne pas montrer : la base de données, et un ou deux autres trucs, que je devrai donc retirer du root. Correct ?

oui les noms de fichiers, voir dossier (les dossiers créés par les IDE par exemple).

zakod a écrit:

Ah ! Et j'ai encore un message, qui concerne .DS_Store : this binary file has changed. Avec un lien pour open file in external programme, et je pige pas de quoi il s'agit.

C'est un fichier lié à ton système d'exploitation Mac OS, je ne connais pas ! Mais c'est un fichier caché, donc par définition, à mettre dans .gitignore.

zakod a écrit:

_____Edit 14:05

Je crois que j'avais pas bien compris : .gitignore, c'est un fichier, pas un dossier. Et chaque ligne concerne les fichiers à ne pas prendre en compte dans le dépôt. 

Ça donnerait comme contenu de .gitignore :

.env

vaste-programme.db

et autres...

C'est bien ça ?

-
Edité par zakod il y a environ 1 heure

Oui il me semblait avoir parlé de fichier évitant les mal-entendu 

Bonjour !

Je crois qu'il faut que j'utilise pipenv. Mais je pige pas tout, comme d'habitude. On m'a expliqué sur scalingo qu'il valait mieux utiliser pipenv, pour avoir un fichier Pipfile qui explicite les dépendances, en particulier mon dotenv.

J'ai installé pipenv. Mais après ça, je sais pas ce qu'il faut faire : pipenv arrive après que le projet soit écrit.

Je vais donc écrire mon Pipfile  et mon Pipfile.loc. Je crois que le mieux, c'est de mettre dans le .lock la version de dotenv que j'ai installée, et dans l'autre celle qui est dispo chez scalingo. Correct ?

À part ça, j'ai réussi à placer mes fichiers cachés, au moyen de la console, et à les pousser. Et j'ai maintenant mon vrai nom de domaine, www.vaste-programme.fr (si on tape que vaste-programme.fr, on déboule sur la page lws qui dit bravo, ton nom de domaine vient d'être créé. Il semble qu'il y ait une chose pas réglée au quart de poil chez LWS.

-
Edité par zakod 4 octobre 2022 à 16:53:28

Il n'y a pas de raison particulière à utiliser pipenv si ce n'est parce-que l'on souhaite utiliser une version python spécifique qui n'existe pas sur le cloud ou que l'on utilise plusieurs serveur HTTP dont on souhaite isoler chaque projet.

J'utilise de mon côté virtualenv mais pipenv est très bien, il existe aussi un autre gestionnaire nommé poetry. Le concept, c'est isolé tes modules python, les écrire dans un fichier et avoir la possibilité lors d'un reset de ton projet, d'installer l'ensemble des dépendances nécessaires à la construction de ton projet.

Il doit y avoir pas mal de docs sur le sujet.

Mais je n'ai rien vu amenant à la conclusion qu'il faudra utiliser pipenv sur la documentation officielle scalingo.

Ils préconisent l'usage de Pipfile et de Pifile.lock, qui sont créés par une commande pipenv, qui importe aussi le fichier requirements.txt.

https://github.com/QISKit/qiskit-terra/issues/343

https://doc.scalingo.com/languages/python/start

Je crois que je vais quand-même m'y mettre. Ce que je ne saisis pas très bien, c'est que la plupart des modules que j'importe n'ont pas besoin d'être mentionnés. exemple avec sqlite3, hashlib ou time. Par contre, Bottle, il faut, et dotenv (ou plutôt python-dotenv — là est la source du problème), aussi. Alors comment on fait, par rapport à un module donné, s'il est implicite ou qu'il faut le mettre dans le requirements ? J'ai envie de tout mettre !

Encore un truc que je vois pas très bien, c'est la différence entre les package dev et prod. On doit les  indiquer dans le Pipfile. Je suis tenté de dire que moi, j'ai que du dev, et que la prod me concerne pas. Mais je suis pas sûr. 

Par ailleurs, j'espère avoir compris la différence entre Pipfile et Pipfile.lock. Pipfile, je mets pas forcément la version précise, .lock si. Là encore j'ai une hésitation : les versions précises, ce sont celles que j'ai en local, ou celles qui sont présentes, dispo chez l'hébergeur ?

zakod a écrit:

Encore un truc que je vois pas très bien, c'est la différence entre les package dev et prod. On doit les  indiquer dans le Pipfile. Je suis tenté de dire que moi, j'ai que du dev, et que la prod me concerne pas. Mais je suis pas sûr.

dev -> en cours de développement

prod -> version stable de l'application utilisé par un nombre de clients

Dans la partie dev ( [dev-package] ) en général on y ajoute les modules déjà en prod ( [packages], utile au bon fonctionnement de l'application) + des modules aidant au développement (pylint, pytest, flake8, ...)

zakod a écrit:

Alors comment on fait, par rapport à un module donné, s'il est implicite ou qu'il faut le mettre dans le requirements ?

Tu n'as pas besoin, la commande pip install va installer l'ensemble des dépendances dont tu as besoin pour que le module puisse être utilisé. Mais pour moi c'est pipenv ou requirements.txt et pas pipenv et requirements.txt

Bon. Maintenant que je connais la raison du crash, je vais suivre ton conseil, je laisse tomber Pipfile et Pipfile.lock, je garde mon requirements.txt, et j'y mets juste Bottle. Si c'est python-dotenv qu'il fallait mettre, et si j'ai bien compris, ça a crashé pour cette raison, non pas parce qu'il n'était pas mentionné dans requirements.

dotenv va charger les variables d'environnement se trouvant dans un fichier .env

Le fait de les mettre dans un gestionnaire de variables d'environnement sur Scalingo, fait que cet outil n'est pas utile, car Scalingo exporte et charge ces variables.

C'est quoi le "gestionnaire de variables d'environnement' ? C'est dotenv ? J'utilise un .env pour mettre une constante que je veux cacher.

Sur scalingo comme beaucoup d'autres cloud basé sur un système Unix, tu es dans un environnement où ses variables sont chargées avec la commande export 

Du coup dans ce cas de figure, dotenv n'est utile que pour tes tests locaux.

Oui mais comment je ferais sans dotenv pour cacher une constante, sans utiliser un .env ?

J'ai encore une question ! ça y est, j'ai corrigé et réussi le déploiement. Je voudrais vérifier que justement, tout ce que je voulais cacher, l'est bel et bien. Mais, et ce doit être normal, ma page me permet de voir tous les fichiers, y compris ceux qui sont cachés. J'ai voulu regarder mon repository sans être connecté, mais apparemment, pour accéder aux repositories, il faut être connecté. Comment faire alors pour consulter mon repository comme si j'étais quelqu'un d'autre ?

-
Edité par zakod 6 octobre 2022 à 10:53:16

zakod a écrit:

Oui mais comment je ferais sans dotenv pour cacher une constante, sans utiliser un .env ?

Ce que dit la doc scalingo, mais que propose quasi tous les cloud de ce type, comme heroku par exemple...

To set an environment variable, there are two ways to do it:

In the "Environment" category in your dashboard

...

 je pensais que tu avais fais ce premier choix.

zakod a écrit:

J'ai encore une question ! ça y est, j'ai corrigé et réussi le déploiement. Je voudrais vérifier que justement, tout ce que je voulais cacher, l'est bel et bien. Mais, et ce doit être normal, ma page me permet de voir tous les fichiers, y compris ceux qui sont cachés. J'ai voulu regarder mon repository sans être connecté, mais apparemment, pour accéder aux repositories, il faut être connecté. Comment faire alors pour consulter mon repository comme si j'étais quelqu'un d'autre ? 

Non on le voit bel et bien...

git rm --cached .env

puis tu commit et push

Zut ! J'ai plus qu'à rechanger. Mais comment ça se fait qu'on le voit, puisqu'il devrait être caché ? Pareil pour .gitignore. J'avais quelque chose à faire en ligne de commande avant de le pousser ? Et est-ce qu'on voit les autres fichiers cachés mentionnés dans .gitignore ? c'est les .txt et la base de données.

Je crois que je comprends ce que tu dis sur dotenv. Pour charger ma constante qui se trouve dans le .env, je peux utiliser os.getenv(). 

-
Edité par zakod 6 octobre 2022 à 12:24:33

zakod a écrit:

Zut ! J'ai plus qu'à rechanger. Mais comment ça se fait qu'on le voit, puisqu'il devrait être caché ?

En fait tu as dû tout simplement faire une commande du genre

git add .env

ou

git add .

qui prend en compte tous les fichiers et dossiers modifiés

Une fois qu'il a été pris en compte dans le cache de git, il faut le supprimer afin qu'aux prochaines modifications, git réagisse de nouveau de manière standard (sans prendre en compte les fichiers cachés).

zakod a écrit:

Je crois que je comprends ce que tu dis sur dotenv. Pour charger ma constante qui se trouve dans le .env, je peux utiliser os.getenv().

Non ce n'est pas encore ça je pense... 

Ce que je dis, c'est qu'en configurant dans le dashboard tes variables d'environnement, tu n'as plus besoin de les charger avec dotenv sur ton .env car scalingo le fait pour toi ! Par contre tu dois récupérer leurs valeurs (variables d'environnement) via la ligne os.getenv("...").

Il faut que tu m'expliques ça : configurer les variables d'environnement dans le dashboard. C'est le dashboard github ? Il ne me permet pas de faire grand-chose. Par exemple, la section "recent activity" est vide. Tu te rends compte ? Plus de 100 déploiements (rigole pas, hein !). ¨Par contre, il me propose de créer un nouveau repository, avec "private" coché. Comme je regrette ! Quelqu'un me dit que je devrais rendre privé mon repository. J'ai vu que pour ça, il faut le forker, le cloner, j'ai peur de pas savoir. Mais ça résoudrait bien des problèmes.

Pour ce qui est du .env, je pige toujours pas. Oui, je me souviens avoir fait add, et je crois, commit. Mais je pige pas quand tu dis qu'il faut ensuite le supprimer. J'aurais bien besoin d'un petit tuto pour quand je vais refaire le .env (j'ai changé le mot de passe mail, il faudra donc que je mette un nouveau .env avec.)

Ce qui me fait penser à cette question : je dois pouvoir ajouter une fonction de mise à jour de ce mot de passe. Donc, cette variable d'environnement, est-ce que je peux changer sa valeur par l'appli elle-même ? Avec "export" par exemple ?

-
Edité par zakod 6 octobre 2022 à 14:54:33

Le .env ne te sert qu'en local; sur scalingo, comme l'a dit fred1599, c'est gérer dans le dashboard de scalingo (cf le lien qu'il a donné https://doc.scalingo.com/platform/app/environment )

De ce fait .env peut et doit être supprimé du dépôt comme l'a encore indiqué fred1599 avec la command git --rm --cached .env, puis faire un commit pour prendre en compte cette modification et un push pour la pousser sur le dépôt.

Dans l'application, il faut utiliser os.getenv(..) comme l'indique encore une fois la doc scalingo (os.envrion[..] devrait fonctionner aussi)

zakod a écrit:

Il faut que tu m'expliques ça : configurer les variables d'environnement dans le dashboard. C'est le dashboard github ?

Non Scalingo

zakod a écrit:

Quelqu'un me dit que je devrais rendre privé mon repository. J'ai vu que pour ça, il faut le forker, le cloner, j'ai peur de pas savoir. Mais ça résoudrait bien des problèmes.

Oui le rendre privé aurait été plus simple, cependant tout dépend du besoin et si tu souhaites faire participer la communauté ou pas.

Par contre pas besoin de forker ou cloner quoi que se soit, tes fichiers sont en local, suffit de supprimer ce projet sur github, d'en créer un autre (cette fois privé), de supprimer le remote relié à ton git (git remote remove origin) et d'ajouter l'adresse git de ton nouveau projet privé (git remote add origin ton_url_git).

zakod a écrit:

Pour ce qui est du .env, je pige toujours pas. Oui, je me souviens avoir fait add, et je crois, commit. Mais je pige pas quand tu dis qu'il faut ensuite le supprimer. J'aurais bien besoin d'un petit tuto pour quand je vais refaire le .env (j'ai changé le mot de passe mail, il faudra donc que je mette un nouveau .env avec.)

Ce qui me fait penser à cette question : je dois pouvoir ajouter une fonction de mise à jour de ce mot de passe. Donc, cette variable d'environnement, est-ce que je peux changer sa valeur par l'appli elle-même ? Avec "export" par exemple ?

Le fichier .env est utile quand tu veux charger tes variables d'environnement, hors sur Scalingo, tu n'as pas besoin, car il le fait pour toi, mais on est bien d'accord que localement pour faire tes tests, il faut bien les charger sur ton système, et c'est là qu'entre en jeu .env et dotenv.

Je pense que si tu gardes dotenv dans ton développement tu auras une erreur, c'est pourquoi un bloc try - except devrait résoudre le problème.

Merci les gars. En vous mettant à plusieurs, je vais peut-être finir par comprendre. Pardon d'être aussi dur à la comprenette. J'ai découvert le dashboard scalingo, Environnement, et j'ai percuté tout ce que me disait Fred. J'ai créé ma variable. Et pour la récupérer, ce sera getenv(), et pas besoin de .env. J'ai tout compris, comme à la Matmut. J'ai délété le .env, commit, et maintenant, je galère avec le push, parce qu'il demande le mot de passe et que quand tu lui donnes, tu tombes sur un Tuttle qui dit qu'en 2013 ils sont passés au système métrique sans prévenir, pardon, qu'il faut maintenant un PAT (jeton d'accès personnel). Faut que je vois ce que c'est. Je désepère Pas. Je suis juste à un push du but.

edit 17:14

Ça marche pas ,mais j'aurais dû m'en douter. J'avais essayé de pousser un ou deux trucs avec le desktop bureau, et ça me racontait que j'avais des modifs qui n'avaient pas été commit. Ça date de mes dernières galères avec requirements, setup et Pipfile, etc. Donc c'est logique que la ligne de commande veuille pas non-plus. je crois que je vais faire ce que m'a indiqué Fred : copier mon dépôt dans un dépôt privé.

-
Edité par zakod 6 octobre 2022 à 17:20:10

Le .env ne te sert qu'en local

Bah pas toujours en fait ! Je suis sur du cloud où je n'ai pas de dashboard, mais un système de terminal où j'exécute via un service mon serveur HTTP(S).

Mes variables sont chargées via .env + dotenv et je n'ai aucune différence de développement si ce n'est l'inclusion des modules python de tests, lint etc...

Et pourtant c'est une infrastructure PAAS comme l'est Scalingo, mais j'avoue que ce type de clouds, comme Scalingo, Heroku, etc... ce n'est pas ma tasse de thé.

Cependant cette partie Scalingo simplifie beaucoup pour ceux ayant l'habitude de travailler avec des OS type Windows par exemple, car entrer sans connaître sur un OS type Unix n'est pas toujours simple, et rend la courbe d'apprentissage bien plus lente.

Alors là, par contre, pour moi, la courbe d'apprentissage, ça va ! Entre les gars du support technique, que j'ai un tantinet fatigués, et les gars sur OC, j'emmagasine. Je me rends compte que la ligne de commande c'est sympa. Je vais créer mon dépôt privé comme ça, je laisse tomber le desktop GitHub.

-
Edité par zakod 6 octobre 2022 à 18:20:14