liberapay.com
1.0.0
Liberapay est une plate-forme de dons récurrentes. Nous vous aidons à financer les créateurs et les projets que vous appréciez.
Remarque: ce WebApp n'est pas auto-hébercable.
Vous voulez discuter? Rejoignez-nous sur Gitter.
Vous pouvez également publier un message dans notre salon GitHub.
Vous pouvez aider à traduire Liberapay via la weblate. État actuel:
Si vous avez des questions sur la traduction de Liberapay, vous pouvez leur demander dans le salon.
Liberapay a été à l'origine fourchu à partir de Gratipay et a hérité de son pando Web Micro-Framework ( Né Aspen), qui est basé sur le routage du système de fichiers et les simples. Ne vous inquiétez pas, c'est assez simple. Par exemple, pour que Liberapay renvoie un Hello $user, your id is $userid pour les demandes à l'URL /$user/hello , vous n'avez qu'à créer le fichier www/%username/hello.spt avec ceci à l'intérieur:
from liberapay.utils import get_participant
[---]
participant = get_participant(state)
[---] text/html
{{ _("Hello {0}, your id is {1}", request.path['username'], participant.id) }}
Comme illustré par la dernière ligne, notre moteur de modèle par défaut est Jinja.
La fonction _ tente de traduire le message dans la langue de l'utilisateur et échappe correctement aux variables (il sait qu'il génère un message pour une page HTML).
Le code Python à l'intérieur de Simplates est uniquement pour une logique spécifique à la demande, le code backend commun se trouve dans le répertoire liberapay/ .
Assurez-vous que les dépendances suivantes sont installées en premier:
Puis courez:
make env
Vous devez maintenant vous donner des pouvoirs de superutiliser Postgres (si cela n'a pas déjà été fait) et créer deux bases de données:
su postgres -c "createuser --superuser $(whoami)"
createdb liberapay
createdb liberapay_tests
Si vous avez besoin d'une compréhension plus profonde, jetez un œil aux rôles de la base de données et à la gestion des sections de bases de données de la documentation de PostgreSQL.
Ensuite, vous pouvez configurer la base de données:
make schema
Les variables d'environnement sont utilisées pour la configuration, les valeurs par défaut sont en defaults.env et tests/test.env . Vous pouvez les remplacer dans local.env et tests/local.env respectivement.
Une fois que vous avez tout installé et configuré la base de données, vous pouvez exécuter l'application:
make run
Il devrait désormais être accessible sur http: // localhost: 8339 /.
Aucun utilisateur n'est fourni par défaut. Vous pouvez créer des comptes comme vous le feriez sur le vrai site Web, et si vous le souhaitez, vous pouvez également créer un tas de faux utilisateurs (mais ils ne sont pas géniaux):
make data
Pour accorder des autorisations d'administration à un compte, modifiez la base de données comme:
psql liberapay -c "update participants set privileges = 1 where username = 'account-username'"
Pour exécuter un salaire local, ouvrez http: // localhost: 8339 / admin / jour de paie et cliquez sur le bouton "Exécuter le jour de paie". Vous pouvez ajouter OVERRIDE_PAYDAY_CHECKS=yes dans le fichier local.env pour désactiver les chèques de sécurité qui empêchent l'exécution de la paie au mauvais moment.
Le code Python interagit avec la base de données en envoyant des requêtes SQL brutes via la bibliothèque postgres.py.
La documentation officielle de PostgreSQL est votre ami lorsque vous traitez SQL, en particulier les sections "le langage SQL" et "SQL Commandes".
Le schéma DB est dans sql/schema.sql , mais ne modifiez pas ce fichier directement, mettez plutôt les modifications dans sql/branch.sql . Pendant le déploiement, ce script sera exécuté sur la DB de production et les modifications seront fusionnées dans sql/schema.sql . Ce processus est semi-automatisé par release.sh .
Pour nos styles, nous utilisons Sass et Bootstrap 3. Leshets de styles sont dans le style/ répertoire et notre code JavaScript est en js/ . Notre politique pour les deux est d'inclure le moins possible d'eux: le site Web doit être presque entièrement utilisable sans JS, et notre CSS devrait tirer parti de Bootstrap autant que possible au lieu de contenir de nombreuses règles personnalisées qui deviendraient un fardeau à maintenir.
Nous compilons bootstrap nous-mêmes de la source SASS dans le style/bootstrap/ répertoire. Nous le faisons pour pouvoir le personnaliser facilement en modifiant les valeurs dans style/variables.scss . La modification des fichiers dans style/bootstrap/ est probablement une mauvaise idée.
Pour les icônes d'interface utilisateur, nous utilisons les icônes bootstrap. Une icône peut être incluse dans une page en appelant la macro icon à partir de templates/macros/icons.html , par exemple {{ icon('liberapay') }} . Les icônes sont stockées dans le fichier www/assets/icons.svg . Pour ajouter une nouvelle icône dans ce fichier, l'élément root <svg> de l'icône ajoutée doit être transformé en un élément <symbol> , ne préservant que son attribut viewBox et l'ajout d'un attribut id .
Si vous ne trouvez aucune icône dans les icônes bootstrap qui convient à votre cas d'utilisation, vous pouvez essayer de rechercher des catalogues en ligne comme Flaticon, Icons8, Pictogrammers, SVG Repo et le projet Noun. Pour les icônes de marque, les icônes simples sont une bonne ressource.
La façon la plus simple d'exécuter la suite de tests est:
make test
Cela recrée le schéma du test DB et exécute tous les tests. Pour accélérer les choses, vous pouvez également utiliser les commandes suivantes:
make pytest uniquement les tests Python sans recréer le test DBmake pytest-re exécute uniquement les tests qui ont échoué précédemment Certains de nos tests incluent des interactions avec les services externes. Afin d'accélérer ces tests, nous enregistrons automatiquement les demandes et les réponses à l'aide de magnétoscope. Les enregistrements sont dans le répertoire tests/py/fixtures , un par classe de test.
Si vous ajoutez ou modifiez les interactions avec les services externes, les tests échoueront, car le magnétoscope ne trouvera pas la demande nouvelle ou modifiée dans les enregistrements et refusera d'enregistrer la nouvelle demande par défaut (voir les modes d'enregistrement pour plus d'informations). Lorsque cela se produit, vous pouvez soit ajouter VCR=new_episodes à votre commande de test (par exemple, make pytest VCR=new_episodes ) ou supprimer les fichiers de fixation obsolètes (par exemple rm tests/py/fixtures/TestPayinsStripe.yml ).
Si vous testez une API qui utilise des clés d'identification (par exemple l'API de Stripe), certaines demandes échoueront si elles ne sont plus exactement identiques. Dans ce cas, augmentez la valeur de l'attribut offset de la classe de test afin que différentes clés d'iDEmpotence soient utilisées.
PostgreSQL est conçu pour empêcher la perte de données, il fait donc beaucoup d'écrits de disque synchrones par défaut. Pour réduire le nombre de ces écritures de blocage, notre script recreate-schema.sh change automatiquement l'option synchronous_commit à off pour la base de données de test, mais cela ne désactive pas complètement la synchronisation. Si votre instance PostgreSQL ne contient que des données que vous pouvez vous permettre de perdre, vous pouvez accélérer les choses davantage en définissant fsync sur off , wal_level à minimal et max_wal_senders sur 0 dans le fichier de configuration du serveur ( postgresql.conf ).
Liberapay prend actuellement en charge deux processeurs de paiement: Stripe et PayPal.
Vous pouvez transmettre les rappels de Stripe sur votre instance Liberapay locale en courant, make stripe-bridge . Le programme Stripe-Cli doit être installé pour que cela fonctionne.
Toutes les nouvelles dépendances doivent être vérifiées pour vérifier qu'elles ne contiennent pas de code malveillant ou de vulnérabilités de sécurité.
Nous utilisons le mode de vérification du hachage de PIP pour nous protéger de la falsification des dépendances. Ainsi, lors de l'ajout ou de la mise à niveau d'une dépendance, les nouveaux hachages doivent être calculés et placer dans le fichier exigence. Pour cela, vous pouvez utiliser Hashin:
pip install hashin
hashin package==x.y -r requirements_base.txt
Si, pour une raison quelconque, vous devez réhabiliter toutes les exigences, exécutez make rehash-requirements .
Pour mettre à niveau toutes les dépendances dans le fichier d'exigences, exécutez hashin -u -r requirements_base.txt . Vous devrez peut-être exécuter des commandes hashin supplémentaires en cas de manque de nouvelles sous-dépendances.
Les dépendances de test dans requirements_tests.txt ne suivent pas ces règles car elles ne sont pas installées en production. C'est à vous d'isoler votre environnement de développement du reste de votre système afin de le protéger des vulnérabilités possibles dans les dépendances de test.
Lors de l'écriture de code qui gère les informations personnelles, gardez à l'esprit les principes consacrés dans le RGPD.
Remarque: Liberapay ne peut pas être auto-hébergé, cette section est uniquement destinée à documenter la façon dont nous déployons de nouvelles versions.
Liberapay est actuellement hébergé sur AWS (Irlande).
Pour déployer l'application, exécutez simplement release.sh , il vous guidera à travers. Bien sûr, vous devez d'abord avoir accès.
Dédicace du domaine public CC0 (voir cette discussion pour plus de détails.)
