YunoHost/doc
1
0
Fork 0
mirror of https://github.com/YunoHost/doc.git synced 2024-09-03 20:06:26 +02:00
Code Issues Projects Releases Packages Wiki Activity

Fix typos

Browse source
This commit is contained in:
ericgaspar 2020-09-15 14:38:11 +02:00
parent e927fdcfe3
commit 1748b597b4
No known key found for this signature in database
GPG key ID: 574F281483054D44
2 changed files with 36 additions and 36 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

24
packaging_apps_guidelines.md
View file

@ -69,8 +69,8 @@ Each YEP is associated with:
| YEP 3.6 | Update versions containing CVE | draft | manual | OFFICIAL (6) | | YEP 3.6 | Update versions containing CVE | draft | manual | OFFICIAL (6) |
| | | | | | | | | | | |
| ** YEP 4 ** | ** Integrate an app ** | ** Status ** | ** Test ** | ** Level ** | | ** YEP 4 ** | ** Integrate an app ** | ** Status ** | ** Test ** | ** Level ** |
| 4.1 | Link to ldap | validated | manual | OFFICIAL (4) | | 4.1 | Link to LDAP | validated | manual | OFFICIAL (4) |
| YEP 4.2 | Link authentication to sso | validated | manual | OFFICIAL (4) | | YEP 4.2 | Link authentication to SSO | validated | manual | OFFICIAL (4) |
| YEP 4.2.1 | Sign Out | validated | manual | OFFICIAL (9) | | YEP 4.2.1 | Sign Out | validated | manual | OFFICIAL (9) |
| YEP 4.3 | Provide YunoHost Backup Script Functional | validated | Home | OFFICIAL (6) | | YEP 4.3 | Provide YunoHost Backup Script Functional | validated | Home | OFFICIAL (6) |
| YEP 4.4 | Provide a YunoHost Restore Functional script | validated | Home | OFFICIAL (6) | | YEP 4.4 | Provide a YunoHost Restore Functional script | validated | Home | OFFICIAL (6) |
@ -99,7 +99,7 @@ In other words, it must respect the following rules:
For application names containing spaces, virtually all current packages simply remove them without replacing them with dashes or underscores. For application names containing spaces, virtually all current packages simply remove them without replacing them with dashes or underscores.
By convention, the YunoHost application repositories are always named their ID followed by the string "\ _ynh". Thus one can distinguish the upstream repository of the application, the deposit of the yunohost package. This notation also makes it possible to find applications not listed by the search engines of platforms offering version managers (GitHub for example). By convention, the YunoHost application repositories are always named their ID followed by the string "\_ynh". Thus one can distinguish the upstream repository of the application, the deposit of the YunoHost package. This notation also makes it possible to find applications not listed by the search engines of platforms offering version managers (GitHub for example).
Example: ID: Example Filing Name: example_ynh Example: ID: Example Filing Name: example_ynh
@ -119,13 +119,13 @@ For the `apps.json` list maintained by the project team, registration is on [the
##### Indicate the license associated with the package | draft | AUTO | WORKING | ##### Indicate the license associated with the package | draft | AUTO | WORKING |
The license of the packet must be specified in a `LICENSE` file at the root of the packet. Be careful not to confuse with the license of the application that will be installed whose acronym is to be entered in the `license` field of the manifest. The license of the packet must be specified in a `LICENSE` file at the root of the packet. Be careful not to confuse with the license of the application that will be installed whose acronym is to be entered in the `license` field of the manifest.
The application list apps.json only accept packages with a free license, as well as the license for the contained application. Some free applications require non-free dependencies (example: mp3, drivers, etc.). In this case, you should add `&dep-non-free` to the acronym and if possible give details in the README.md of the package, in this case the integration will be accepted on a case-by-case basis. The application list apps.json only accept packages with a free license, as well as the license for the contained application. Some free applications require non-free dependencies (example: MP3, drivers, etc.). In this case, you should add `&dep-non-free` to the acronym and if possible give details in the README.md of the package, in this case the integration will be accepted on a case-by-case basis.
**NB:** Apps not included in apps.json lists may still be installed: either manually with the URL to the app, or in a more practical way using non-official lists (which can be created and maintained by the community). **NB:** Apps not included in apps.json lists may still be installed: either manually with the URL to the app, or in a more practical way using non-official lists (which can be created and maintained by the community).
In the future, YunoHost will probably display details about the license of the application. To achieve this, the acronym must be the one from this [list of licenses listed in the SPDX](https://spdx.org/licenses/) (if there are 2 acronyms, the one containing the version number). For consistency, the case must be respected. In the future, YunoHost will probably display details about the license of the application. To achieve this, the acronym must be the one from this [list of licenses listed in the SPDX](https://spdx.org/licenses/) (if there are 2 acronyms, the one containing the version number). For consistency, the case must be respected.
If the license is not present in the list, in this case it is necessary to indicate `free` or `non-free` depending on whether it is free or not and give the user the opportunity to inquire in the README .md (link, explanations, ...). If the license is not present in the list, in this case it is necessary to indicate `free` or `non-free` depending on whether it is free or not and give the user the opportunity to inquire in the README.md (link, explanations...).
Example: for a GNU Lesser General Public License (LGPL), version 3 the acronym is `LGPL-3.0` if non-free dependencies are used in this case it will be necessary to put LGPL-3.0 & dep-non-free `in the manifesto. Example: for a GNU Lesser General Public License (LGPL), version 3 the acronym is `LGPL-3.0` if non-free dependencies are used in this case it will be necessary to put LGPL-3.0 & dep-non-free `in the manifesto.
@ -203,7 +203,7 @@ There is also README.md, which must and can contain:
* instructions to use it (for example to connect your smartphone or computer) * instructions to use it (for example to connect your smartphone or computer)
* the location to report a malfunction / request * the location to report a malfunction / request
* the roadmap / TODO * the roadmap / TODO
* possibly prerequisites in terms of ram memories, processor etc. (some equipment has less than 512MB of ram) * possibly prerequisites in terms of RAM memories, processor etc. (some equipment has less than 512 MB of RAM)
#### YEP 1.10 #### YEP 1.10
##### Keep a clean version history | draft | manual | OFFICIAL | ##### Keep a clean version history | draft | manual | OFFICIAL |
@ -225,11 +225,11 @@ The manifest allows to describe an app so that YunoHost can apply the good treat
#### YEP 2.2 #### YEP 2.2
##### Using bash for main scripts | validated | Home | WORKING | ##### Using bash for main scripts | validated | Home | WORKING |
Action scripts (install, upgrade, remove, backup and restore) must be in the bash so that the cli / api yunohost can call them correctly. Action scripts (install, upgrade, remove, backup and restore) must be in the bash so that the CLI/API YunoHost can call them correctly.
That being said, there is nothing to prevent other scripts or function libraries from using these scripts. These are not obliged to be in bash. That being said, there is nothing to prevent other scripts or function libraries from using these scripts. These are not obliged to be in bash.
However, careful attention must be paid to the correct display of logs of information, warning, or errors. So that a user of the cli / api yunohost can understand the operation of the script just executed and if necessary repair its YunoHost instance. However, careful attention must be paid to the correct display of logs of information, warning, or errors. So that a user of the CLI/API YunoHost can understand the operation of the script just executed and if necessary repair its YunoHost instance.
#### YEP 2.3 #### YEP 2.3
##### Save the answers during the installation | validated | manual | WORKING | ##### Save the answers during the installation | validated | manual | WORKING |
@ -238,12 +238,12 @@ During installation, it is necessary to save each answer to the questions in the
#### YEP 2.4 #### YEP 2.4
##### Detecting and Managing Errors | draft | manual | WORKING | ##### Detecting and Managing Errors | draft | manual | WORKING |
The install, upgrade, backup, and restore scripts must detect errors to avoid further scripting in case of blocking error or empty variable usage. The install, upgrade, backup, and restore scripts must detect errors to avoid further scripting in case of blocking error or empty variable usage.
The use of trap and set -eu is recommended to detect and treat errors ([Discussion in progress](https://forum.yunohost.org/t/gestion-des-erreurs-set-e-and-or-trap/2249/5)) The use of trap and `set -eu` is recommended to detect and treat errors ([Discussion in progress](https://forum.yunohost.org/t/gestion-des-erreurs-set-e-and-or-trap/2249/5))
It is also necessary to check the contents of the variables before removing the remove script. For example, an `rm -Rf /var/www/$app` with `$app` empty would have a disastrous result. It is also necessary to check the contents of the variables before removing the remove script. For example, an `rm -Rf /var/www/$app` with `$app` empty would have a disastrous result.
At the beginning of the scripts, before any modifications, it is necessary to check the existence of the users mentioned at the installation, as well as the availability of the requested path, the availability of the final file of the application and the size of the passwords if necessary. At the beginning of the scripts, before any modifications, it is necessary to check the existence of the users mentioned at the installation, as well as the availability of the requested path, the availability of the final file of the application and the size of the passwords if necessary.
Do not forget that in case of installation error the removal script will be launched automatically by the yunohost cli. Do not forget that in case of installation error the removal script will be launched automatically by the YunoHost CLI.
#### YEP 2.5 #### YEP 2.5
##### Copy files correctly | draft | manual | WORKING | ##### Copy files correctly | draft | manual | WORKING |
@ -341,7 +341,7 @@ A web app should be able to install on a path `/path`.
#### YEP 2.18.5 #### YEP 2.18.5
##### Manage the YunoHost tile to easily navigate between applications | validated | manual | OFFICIAL | ##### Manage the YunoHost tile to easily navigate between applications | validated | manual | OFFICIAL |
Except in rare cases it is advisable to integrate the tile YunoHost which allows to return to the menu of the SSO. This integration is done in the nginx configuration. Except in rare cases it is advisable to integrate the tile YunoHost which allows to return to the menu of the SSO. This integration is done in the NGINX configuration.
Some users have replaced this square with a script adding a menu at the top of each webapp. Some users have replaced this square with a script adding a menu at the top of each webapp.
@ -356,7 +356,7 @@ It should also be checked whether the port should be open on the router, beyond
#### YEP 3.3 #### YEP 3.3
##### Facilitating Source Integrity Control | draft | manual | OFFICIAL | ##### Facilitating Source Integrity Control | draft | manual | OFFICIAL |
The upstream application should not be integrated into tarball in the source folder of the package, as this adds to the package and the git repository and does not allow verification of the integrity of the source. The upstream application should not be integrated into tarball in the source folder of the package, as this adds to the package and the Git repository and does not allow verification of the integrity of the source.
The source must be downloaded from the official website, then its integrity must be checked before installing it. The source must be downloaded from the official website, then its integrity must be checked before installing it.
#### YEP 3.4 #### YEP 3.4

28
packaging_apps_guidelines_fr.md
View file

@ -70,8 +70,8 @@ Chaque YEP est associée à :
| YEP 3.7 | Modifier correctement les dépots sources | draft | manuel | NOTWORKING (0) | | YEP 3.7 | Modifier correctement les dépots sources | draft | manuel | NOTWORKING (0) |
| | | | | | | | | | | |
| **YEP 4** | **Intégrer une app** | **Statut** | **Test** | **Niveau** | | **YEP 4** | **Intégrer une app** | **Statut** | **Test** | **Niveau** |
| 4.1 | Lier au ldap | validé | manuel | OFFICIAL (4) | | 4.1 | Lier au LDAP | validé | manuel | OFFICIAL (4) |
| YEP 4.2 | Lier l'authentification au sso | validé | manuel | OFFICIAL (4) | | YEP 4.2 | Lier l'authentification au SSO | validé | manuel | OFFICIAL (4) |
| YEP 4.2.1 | Déconnexion | validé | manuel | OFFICIAL (9) | | YEP 4.2.1 | Déconnexion | validé | manuel | OFFICIAL (9) |
| YEP 4.3 | Fournir un script de sauvegarde YunoHost fonctionnel | validé | auto | OFFICIAL (6) | | YEP 4.3 | Fournir un script de sauvegarde YunoHost fonctionnel | validé | auto | OFFICIAL (6) |
| YEP 4.4 | Fournir un script de restauration YunoHost fonctionnel | validé | auto | OFFICIAL (6) | | YEP 4.4 | Fournir un script de restauration YunoHost fonctionnel | validé | auto | OFFICIAL (6) |
@ -100,7 +100,7 @@ De plus l'identifiant doit respecter l'expression régulière suivante `^[a-z0-9
Pour les noms d'applications contenant des espaces la quasi-totalité des paquets actuels les retirent simplement sans les remplacer par des tirets ou underscores. Pour les noms d'applications contenant des espaces la quasi-totalité des paquets actuels les retirent simplement sans les remplacer par des tirets ou underscores.
Par convention, les dépôts d'applications YunoHost sont toujours nommés de leur ID suivis de la chaîne de caractère "\_ynh". Ainsi on peut distinguer le dépôt upstream de l'application, du dépôt du paquet yunohost. Cette notation permet également de trouver des applications non répertoriées à travers les moteurs de recherche des plateformes proposant des gestionnaires de version (GitHub par exemple). Par convention, les dépôts d'applications YunoHost sont toujours nommés de leur ID suivis de la chaîne de caractère "\_ynh". Ainsi on peut distinguer le dépôt upstream de l'application, du dépôt du paquet YunoHost. Cette notation permet également de trouver des applications non répertoriées à travers les moteurs de recherche des plateformes proposant des gestionnaires de version (GitHub par exemple).
Exemple : ID : exemple Nom de dépôt : exemple_ynh Exemple : ID : exemple Nom de dépôt : exemple_ynh
@ -120,13 +120,13 @@ Pour la liste `apps.json` maintenue par l'équipe du projet YunoHost, l'inscript
##### Indiquer la licence associée au paquet | brouillon | AUTO | WORKING | ##### Indiquer la licence associée au paquet | brouillon | AUTO | WORKING |
La licence du paquet est à indiquer dans un fichier `LICENSE` à la racine du paquet. Attention à ne pas confondre avec la licence de l'application qui va être installée dont l'acronyme est à renseigner dans le champ `license` du manifeste. La licence du paquet est à indiquer dans un fichier `LICENSE` à la racine du paquet. Attention à ne pas confondre avec la licence de l'application qui va être installée dont l'acronyme est à renseigner dans le champ `license` du manifeste.
La liste d'application apps.json n'accepte que les paquets dont la licence est libre, de même pour la licence de l'application contenue. Certaines applications libres nécessitent des dépendances non-libres (exemple: mp3, drivers, etc.). Dans ce cas, il faut ajouter `&dep-non-free` à l'acronyme et si possible donner des précisions dans le README.md du paquet, l'intégration sera dans ce cas acceptée au cas par cas. La liste d'application apps.json n'accepte que les paquets dont la licence est libre, de même pour la licence de l'application contenue. Certaines applications libres nécessitent des dépendances non-libres (exemple: MP3, drivers, etc.). Dans ce cas, il faut ajouter `&dep-non-free` à l'acronyme et si possible donner des précisions dans le README.md du paquet, l'intégration sera dans ce cas acceptée au cas par cas.
**NB :** Les applications non-présentes dans la liste maintenue par le projet peuvent tout de même être installées : soit manuellement via le lien de l'application, soit de manière plus intégrée via des listes non-officielles (qui peuvent être créées et maintenues par la communauté). **NB :** Les applications non-présentes dans la liste maintenue par le projet peuvent tout de même être installées : soit manuellement via le lien de l'application, soit de manière plus intégrée via des listes non-officielles (qui peuvent être créées et maintenues par la communauté).
Dans le futur, YunoHost affichera sans doute des détails sur la licence de l'application. Pour y parvenir, l'acronyme doit être celui issu de cette [liste de licences répertoriées du SPDX](https://spdx.org/licenses/) (si il y a 2 acronymes, il faut prendre celui contenant le numéro de version). Pour plus de cohérence, la casse doit être respectée. Dans le futur, YunoHost affichera sans doute des détails sur la licence de l'application. Pour y parvenir, l'acronyme doit être celui issu de cette [liste de licences répertoriées du SPDX](https://spdx.org/licenses/) (si il y a 2 acronymes, il faut prendre celui contenant le numéro de version). Pour plus de cohérence, la casse doit être respectée.
Si la licence n'est pas présente dans la liste, dans ce cas il faut indiquer `free` ou `non-free` selon qu'elle est libre ou non et donner l'occasion à l'utilisateur de se renseigner dans le README.md (lien, explications, ...). Si la licence n'est pas présente dans la liste, dans ce cas il faut indiquer `free` ou `non-free` selon qu'elle est libre ou non et donner l'occasion à l'utilisateur de se renseigner dans le README.md (lien, explications...).
Exemple : pour une licence `GNU Lesser General Public License (LGPL), version 3` l'acronyme est `LGPL-3.0` si toutefois des dépendances non libres sont utilisées dans ce cas il faudra mettre `LGPL-3.0&dep-non-free` dans le manifeste. Exemple : pour une licence `GNU Lesser General Public License (LGPL), version 3` l'acronyme est `LGPL-3.0` si toutefois des dépendances non libres sont utilisées dans ce cas il faudra mettre `LGPL-3.0&dep-non-free` dans le manifeste.
@ -204,7 +204,7 @@ Il y a également le README.md, ce dernier doit et peut contenir :
* des instructions pour l'utiliser (par exemple pour relier son smartphone ou son ordinateur) * des instructions pour l'utiliser (par exemple pour relier son smartphone ou son ordinateur)
* l'endroit pour signaler un dysfonctionnement / une demande * l'endroit pour signaler un dysfonctionnement / une demande
* la roadmap/TODO * la roadmap/TODO
* éventuellement les pré-requis en termes de mémoires ram, processeur etc. (certains équipements ont moins de 512Mo de ram) * éventuellement les pré-requis en termes de mémoires RAM, processeur etc. (certains équipements ont moins de 512 Mo de RAM)
#### YEP 1.10 #### YEP 1.10
##### Garder un historique de version propre | brouillon | manuel | OFFICIAL | ##### Garder un historique de version propre | brouillon | manuel | OFFICIAL |
@ -226,11 +226,11 @@ Le manifeste permet de décrire une app afin que YunoHost puisse lui appliquer l
#### YEP 2.2 #### YEP 2.2
##### Utiliser bash pour les scripts principaux | validé | auto | WORKING | ##### Utiliser bash pour les scripts principaux | validé | auto | WORKING |
Les scripts d'action (install, upgrade, remove, backup et restore) doivent être en bash afin que la cli/api yunohost puisse correctement les appeler. Les scripts d'action (install, upgrade, remove, backup et restore) doivent être en bash afin que la CLI/API YunoHost puisse correctement les appeler.
Ceci étant, rien n'empêche à l'intérieur de ces scripts de faire appel à d'autres scripts ou bibliothèques de fonction. Ceux-ci ne sont pas obligés d'être en bash. Ceci étant, rien n'empêche à l'intérieur de ces scripts de faire appel à d'autres scripts ou bibliothèques de fonction. Ceux-ci ne sont pas obligés d'être en bash.
Cependant, il faudra porter une attention particulière à l'affichage correct des logs d'information, de warning, ou d'erreurs. Afin qu'un utilisateur de la cli/api yunohost puisse comprendre le fonctionnement du script venant d'être exécuté et au besoin réparer son instance YunoHost. Cependant, il faudra porter une attention particulière à l'affichage correct des logs d'information, de warning, ou d'erreurs. Afin qu'un utilisateur de la CLI/API YunoHost puisse comprendre le fonctionnement du script venant d'être exécuté et au besoin réparer son instance YunoHost.
#### YEP 2.3 #### YEP 2.3
##### Sauvegarder les réponses lors de l'installation | validé | manuel | WORKING | ##### Sauvegarder les réponses lors de l'installation | validé | manuel | WORKING |
@ -239,12 +239,12 @@ Lors de l'installation, il est nécessaire de sauvegarder chaque réponse aux qu
#### YEP 2.4 #### YEP 2.4
##### Détecter et gérer les erreurs | brouillon | manuel | WORKING | ##### Détecter et gérer les erreurs | brouillon | manuel | WORKING |
Les scripts install, upgrade, backup et restore doivent détecter les erreurs pour éviter la poursuite des scripts en cas d'erreur bloquante ou d'usage de variable vide. Les scripts install, upgrade, backup et restore doivent détecter les erreurs pour éviter la poursuite des scripts en cas d'erreur bloquante ou d'usage de variable vide.
L'usage de trap et de set -eu est recommandé pour détecter et traiter les erreurs ([Discussion en cours à ce sujet](https://forum.yunohost.org/t/gestion-des-erreurs-set-e-et-ou-trap/2249/5)) L'usage de trap et de `set -eu` est recommandé pour détecter et traiter les erreurs ([Discussion en cours à ce sujet](https://forum.yunohost.org/t/gestion-des-erreurs-set-e-et-ou-trap/2249/5))
Il est nécessaire également de vérifier le contenu des variables avant les suppressions du script remove. Par exemple un `rm -Rf /var/www/$app` avec `$app` vide aurait un résultat désastreux. Il est nécessaire également de vérifier le contenu des variables avant les suppressions du script remove. Par exemple un `rm -Rf /var/www/$app` avec `$app` vide aurait un résultat désastreux.
Au début des scripts, avant toutes modifications, il faut vérifier l'existence des utilisateurs mentionné à l'installation, ainsi que la disponibilité du path demandé, la disponibilité du dossier final de l'application et la taille des mots de passe le cas échéant. Au début des scripts, avant toutes modifications, il faut vérifier l'existence des utilisateurs mentionné à l'installation, ainsi que la disponibilité du path demandé, la disponibilité du dossier final de l'application et la taille des mots de passe le cas échéant.
N'oubliez pas qu'en cas d'erreur d'installation le script de suppression sera lancé automatiquement par la cli yunohost. N'oubliez pas qu'en cas d'erreur d'installation le script de suppression sera lancé automatiquement par la CLI YunoHost.
#### YEP 2.5 #### YEP 2.5
##### Copier correctement des fichiers | brouillon | manuel | WORKING | ##### Copier correctement des fichiers | brouillon | manuel | WORKING |
@ -343,7 +343,7 @@ Une web app devraient pouvoir s'installer sur un chemin `/path`.
#### YEP 2.18.5 #### YEP 2.18.5
##### Gérer la tuile YunoHost pour naviguer facilement entre les applications | validé | manuel | OFFICIAL | ##### Gérer la tuile YunoHost pour naviguer facilement entre les applications | validé | manuel | OFFICIAL |
Sauf dans de rare cas il est conseillé d'intégrer la tuile YunoHost qui permet de retourner sur le menu du SSO. Cette intégration se fait dans la configuration nginx. Sauf dans de rare cas il est conseillé d'intégrer la tuile YunoHost qui permet de retourner sur le menu du SSO. Cette intégration se fait dans la configuration NGINX.
Certains utilisateurs ont remplacé ce carré par un script ajoutant un menu en haut de chaque webapp. Certains utilisateurs ont remplacé ce carré par un script ajoutant un menu en haut de chaque webapp.
@ -358,13 +358,13 @@ Il convient également de vérifier si le port doit être ouvert sur le routeur,
#### YEP 3.3 #### YEP 3.3
##### Faciliter le contrôle de l'intégrité des sources | brouillon | manuel | OFFICIAL | ##### Faciliter le contrôle de l'intégrité des sources | brouillon | manuel | OFFICIAL |
L'application upstream ne doit pas être intégrée en tarball dans le dossier source du package, car cela alourdit le package et le dépôt git et ne permet pas la vérification de l'intégrité de la source. L'application upstream ne doit pas être intégrée en tarball dans le dossier source du package, car cela alourdit le package et le dépôt Git et ne permet pas la vérification de l'intégrité de la source.
La source doit donc être téléchargée depuis le site officiel, puis son intégritée doit être vérifiée avant de l'installer. La source doit donc être téléchargée depuis le site officiel, puis son intégritée doit être vérifiée avant de l'installer.
#### YEP 3.4 #### YEP 3.4
##### Isoler l'app | brouillon | manuel | OFFICIAL | ##### Isoler l'app | brouillon | manuel | OFFICIAL |
Afin d'éviter des effets de bords en cas de compromission éventuelle de l'application, celle-ci doit être isolée pour ne pas risquer d'impacter les autres applications. Afin d'éviter des effets de bords en cas de compromission éventuelle de l'application, celle-ci doit être isolée pour ne pas risquer d'impacter les autres applications.
Pour cela, il convient d'isoler l'application dans son dossier d'exécution en restreignant son environnement par un chroot, soit par un mécanisme interne à l'application lorsque c'est possible (par exemple pour un serveur ftp), soit par l'usage de phpfpm. Pour cela, il convient d'isoler l'application dans son dossier d'exécution en restreignant son environnement par un chroot, soit par un mécanisme interne à l'application lorsque c'est possible (par exemple pour un serveur FTP), soit par l'usage de PHP-FPM.
De même, pour restreindre la portée de l'utilisateur exécutant l'application, il est préférable d'utiliser un utilisateur dédiée à l'application. Dont les droits sont restreint à l'usage de l'application uniquement. De même, pour restreindre la portée de l'utilisateur exécutant l'application, il est préférable d'utiliser un utilisateur dédiée à l'application. Dont les droits sont restreint à l'usage de l'application uniquement.
Toutefois, cela ne doit pas exempter d'une restriction maximale des droits sur les fichiers de l'application. Autant que possible, les fichiers doivent appartenir à root, et l'utilisateur dédié ne doit avoir de droits d'écriture que sur les fichiers le réclamant expressément. Toutefois, cela ne doit pas exempter d'une restriction maximale des droits sur les fichiers de l'application. Autant que possible, les fichiers doivent appartenir à root, et l'utilisateur dédié ne doit avoir de droits d'écriture que sur les fichiers le réclamant expressément.
@ -400,7 +400,7 @@ Dans tous les cas, une app ne devrait pas modifier les dépôts sources pour les
Cette meta YEP traite de l'intégration d'une app avec l'environnement YunoHost. Une bonne intégration est en général un gage de qualité et de confort pour les utilisateurs. Cette meta YEP traite de l'intégration d'une app avec l'environnement YunoHost. Une bonne intégration est en général un gage de qualité et de confort pour les utilisateurs.
#### YEP 4.2 #### YEP 4.2
##### Lier l'authentification au sso | validé | manuel | OFFICIAL | ##### Lier l'authentification au SSO | validé | manuel | OFFICIAL |
Le Single Sign On permet d'éviter d'avoir à créer les mêmes utilisateurs pour chaque app. Ainsi, un utilisateur YunoHost pourra se connecter via le Single Sign On à l'ensemble des apps. Le Single Sign On permet d'éviter d'avoir à créer les mêmes utilisateurs pour chaque app. Ainsi, un utilisateur YunoHost pourra se connecter via le Single Sign On à l'ensemble des apps.
Pour se faire, il convient de lier son app au LDAP et/ou d'utiliser des hooks pour dupliquer les identifiants du compte dans la base de données de l'app. Pour se faire, il convient de lier son app au LDAP et/ou d'utiliser des hooks pour dupliquer les identifiants du compte dans la base de données de l'app.