1
0
Fork 0
mirror of https://github.com/YunoHost-Apps/radicale_ynh.git synced 2024-09-03 20:16:14 +02:00

Corrections

This commit is contained in:
Maniack Crudelis 2016-04-12 13:15:39 +02:00
parent 6352bf5462
commit 57790838d9
6 changed files with 7318 additions and 89 deletions

View file

@ -16,70 +16,88 @@ URL : https://domain.tld/path/user/calendar.ics/
Exemple : https://example.org/radicale/moi/calendar.ics/
### ics et caldav indifféremment???
## Pour connecter un carnet d'adresses en particulier:
URL : https://domain.tld/path/user/AddressBook.vcf/
Exemple : https://example.org/radicale/moi/AddressBook.vcf/
## Créer un nouveau calendrier ou un nouveau carnet d'adresses
## Créer un nouveau calendrier ou un nouveau carnet d'adresses:
Créer un nouveau calendrier ou un nouveau carnet d'adresses est très simple avec radicale, il suffit d'y accéder! Radicale créera tout nouveau calendrier ou carnet d'adresses inexistant si vous tentez d'y accéder.
Il suffit donc de se connecter (comme précédemment) à un calendrier ou un carnet d'adresses inexistant pour le créer.
Cela peux être fait simplement avec un navigateur, pour le voir apparaitre dans une collection déjà connectée à un client.
Cela peux être fait simplement avec un navigateur, pour le voir apparaître dans une collection déjà connectée à un client.
## Accéder à un calendrier ou un carnet d'adresses d'un autre utilisateur:
Les adresses précédentes fonctionnent également pour accéder à des ressources n'appartenant pas à l'utilisateur authentifié.
> Exemple:
> User1 peut se connecter à la collection de user2
> https://example.org/radicale/user2/
> Il lui suffira d'indiquer le login et mot de passe de user1.
> Ce sont les règles de partage (voir ci-dessous) qui permettront ou pas à user1 de voir le contenu de la collection de user2.
> Par défaut, aucun partage n'est autorisé. (A VÉRIFIER !!!)
---
## Configurer les droits d'accès et les partages de calendriers et de carnets d'adresses:
Par défaut, tout utilisateur à le droit de lecture et d'écriture sur ses propres calendriers et carnets d'adresses.
Il est toutefois possible d'affiner ces règles par défaut et d'autoriser des partages en autorisant des utilisateurs à accéder à des ressources ne leurs appartenant pas.
Les règles régissant ces droits doivent être inscrite dans le fichier */etc/radicale/rights*
Qu'est-ce que je voulais ajouter?
Les règles de partage et de droits!
Chaque règle se présente sous cette forme:
```
# Commentaire précédant la règle et l'expliquant (optionnel évidemment):
[Nom de la règle]
user: utilisateur concerné
collection: calendrier, carnet ou collection concernée.
permission: permission, r (lecture), w (écriture) ou rw (lecture/écriture)
```
Le fichier *rights* contient plusieurs exemples pouvant être exploités.
Pour valider les modifications apportées au fichier */etc/radicale/rights*, radicale doit être rechargé via le service uwsgi.
```
sudo service uwsgi restart
```
# This means all users starting with "admin" may read any collection
[admin]
user: ^admin.*$
collection: .*
permission: r
# This means all users may read and write any collection starting with public.
# We do so by just not testing against the user string.
[public]
user: .*
collection: ^public(/.+)?$
## Partager des ressources:
Pour partager un calendrier ou un carnet d'adresses, il suffit d'écrire une règle le permettant. Le partage peut se faire avec un autre utilisateur.
```
user: ^user1$
collection: ^user2/shared2$
permission: rw
# A little more complex: give read access to users from a domain for all
# collections of all the users (ie. user@domain.tld can read domain/\*).
# [domain-wide-access]
# user: ^.+@(.+)\..+$
# collection: ^{0}/.+$
# permission: r
# Allow authenticated user to read all collections
[allow-everyone-read]
user: .+
collection: .*
```
Ou publiquement pour un utilisateur distant n'utilisant pas le même serveur.
```
user: .*
collection: ^user2/shared2$
permission: r
```
Dans les 2 cas, le partage ne fonctionnera qu'en utilisant l'adresse complète du calendrier ou de la collection. Autrement dit, les partages n'apparaissent pas dans la collection d'un utilisateur.
Cette limitation peut s'avérer bloquante pour des clients gérant une seule collection, tel que InfCloud. Pour ce cas particulier, une solution permet de contourner ce problème.
# Give write access to owners
[owner-write]
user: .+
collection: ^%(login)s/.+$
permission: w
### Partager des ressources directement dans la collection d'un utilisateur:
> Cette solution est fonctionnelle, mais reste du bidouillage...
# Partage public en lecture seule d'un agenda
#[public for readonly]
#user: .*
#collection: ^utilisateur/nom_calendrier*
#permission: r
Pour permettre à un partage d'apparaître directement dans la collection d'un utilisateur, il faut exploiter l'usage des fichiers sous Radicale.
En créant simplement un lien symbolique de la ressource à partager.
```
ln -sr user2/shared.ics user1/user2_shared.ics
```
La ressource partagée devient ainsi une ressource de la collection de user1, alors qu'elle reste physiquement dans la collection de user2.
En revanche, sans avoir recours à des règles pour chaque ressource de la collection de user1, la règle générale s'applique. user1 obtient donc le droit de lecture ET d'écriture par défaut sur la ressource partagé car elle fait partie de sa collection.
# Partage public en lecture/écriture d'un agenda
#[public for read/write]
#user: .*
#collection: ^utilisateur/nom_calendrier*
#permission: rw
---
#[user1 can read and write user2/shared2]
#user: ^user1$
#collection: ^user2/shared2$
#permission: rw
## Rendre le log de Radicale plus loquace:
Par défaut, le log de Radicale est réglé sur INFO. Ce mode épargne le disque dur mais ne permet pas de débugger Radicale en cas de problème.
Pour passer Radicale en mode DEBUG, il faut éditer le fichier */etc/radicale/logging* et passer INFO à DEBUG dans les sections *[logger_root]* et *[handler_file]* puis recharger le service uwsgi.
Dés lors, le log affiche toutes les requêtes qui sont faite à Radicale ainsi que l'analyse du fichier *rights*.
Il est toutefois déconseillé de rester sur ce mode, car le log se rempli très rapidement.
---
## Modifier la configuration de InfCloud:
La configuration de InfCloud se trouve dans le fichier *infcloud/config.js*
Pour prendre en compte une modification dans le fichier *config.js* (ou tout autre fichier de InfCloud) il faut recharger le cache avec le script fourni.
```
sudo ./cache_update.sh
```

View file

@ -9,27 +9,6 @@
# Leading or ending slashes are trimmed from collection's path.
# This means all users starting with "admin" may read any collection
[admin]
user: ^admin.*$
collection: .*
permission: r
# This means all users may read and write any collection starting with public.
# We do so by just not testing against the user string.
[public]
user: .*
collection: ^public(/.+)?$
permission: rw
# A little more complex: give read access to users from a domain for all
# collections of all the users (ie. user@domain.tld can read domain/\*).
# [domain-wide-access]
# user: ^.+@(.+)\..+$
# collection: ^{0}/.+$
# permission: r
# Allow authenticated user to read all collections
[allow-everyone-read]
user: .+
@ -40,15 +19,38 @@ permission: r
[owner-write]
user: .+
collection: ^%(login)s/.+$
permission: w
permission: rw
# Partage public en lecture seule d'un agenda
### EXAMPLES:
## This means all users starting with "admin" may read any collection
# [admin]
# user: ^admin.*$
# collection: .*
# permission: r
## A little more complex: give read access to users from a domain for all
# collections of all the users (ie. user@domain.tld can read domain/\*).
# [domain-wide-access]
# user: ^.+@(.+)\..+$
# collection: ^{0}/.+$
# permission: r
## This means all users may read and write any collection starting with public.
# [public]
# user: .*
# collection: ^public(/.+)?$
# permission: rw
## Partage public en lecture seule d'un agenda
# [public for readonly]
# user: .*
# collection: ^utilisateur/nom_calendrier*
# permission: r
# Partage public en lecture/écriture d'un agenda
## Partage public en lecture/écriture d'un agenda
# [public for read/write]
# user: .*
# collection: ^utilisateur/nom_calendrier*

View file

@ -142,8 +142,7 @@ sudo chown radicale: -R /opt/yunohost/$app
sudo chown -R radicale: $final_path
sudo mkdir /var/log/$app
sudo touch /var/log/$app/$app.log
sudo chgrp radicale -R /var/log/$app
sudo chmod g+w -R /var/log/$app
sudo chown radicale -R /var/log/$app
# Droit par défaut des dossiers de collections utilisateurs, tels qu'ils sont créés par radicale.
sudo chmod 666 -R $final_path/default_collections
sudo chmod 777 $final_path/default_collections $final_path/default_collections/USER

View file

@ -135,8 +135,7 @@ sudo chmod 644 /etc/$app/*
sudo chown -R radicale: $final_path
sudo mkdir -p /var/log/$app
sudo touch /var/log/$app/$app.log
sudo chgrp radicale -R /var/log/$app
sudo chmod g+w -R /var/log/$app
sudo chown radicale -R /var/log/$app
# Droit par défaut des dossiers de collections utilisateurs, tels qu'ils sont créés par radicale.
sudo chmod 666 -R $final_path/default_collections
sudo chmod 777 $final_path/default_collections $final_path/default_collections/USER

15
sources/Notes ajouts Normal file
View file

@ -0,0 +1,15 @@
Infos sur les fichiers modifiés dans le code source des logiciels:
# Radicale:
Correction du commit https://github.com/Kozea/Radicale/commit/e807c3d35bea9cfcfcacac83b1b17d748ea15a39
Ce commit force l'arrêt de l'analyse du fichier rights à la première règle valide.
Cette modification est faite aux lignes 112 à 116 du fichier regex.py
# InfCloud:
Le script cache_update.sh utilise l'éditeur de texte ed, qui n'est pas installé par défaut. La commande étant très simple, elle est remplacée par sed.
Une erreur bloquante affecte CardDavMATE, après discussion avec le dévellopeur Ján Máté, il a trouvé la source du bug. Le fichier interface.js est corrigé en conséquence en attendant une nouvelle version.
Correction aux lignes 6922 à 6928.

File diff suppressed because it is too large Load diff