Problem using the "first matching rule" for the rights #374
Comments
liZe
changed the title
|
The "rights" file is a list of independant examples, not a default configuration file. I've just added this to the file to make it clear. I'm interested in real life examples of configuration files that were easy to write before #335 and hard to write now. Could you please provide such an example? |
|
... Pour commencer, désolé d'être francophone... J'avais fait l'effort de traduire en anglais pour les autres. Mais si ma partie en français disparaît, je préfère ne pas écrire en anglais... Un exemple dans la vraie vie? J'en ai eu un hier justement. Mais User1 souhaite également accéder à un calendrier de User2 qui le partage avec lui. Avant le PR #335, ça fonctionne sans problème. User1 a accès à sa collection et au calendrier partagé. Après ce PR, la seconde règle n'est pas vérifiée puisque la première est déjà validée. C'est sans doute possible de régler ça avec des regex, mais c'est un casse tête infernal pour y parvenir. Et encore, c'est un seul calendrier partagé. |
I'm a French guy too. I can understand what you wrote, and French is not a problem for me. But it could be a problem for the other ones. That's why I'd really prefer to have comments written in English, even if it's poor English with mistakes. People won't tell you that your English is horrible because they don't care, they'll be too happy to see that someone else has the same problem, sharing their issues and their solutions with you. Thank you very much for taking the time to report this bug and to translate it in English. I'll leave your last comment in French. But if you want to share your problem with the other users, for this project, you'll have to write all your comments in English. Imagine this issue tracker filled with bugs written by users in their native languages. It doesn't work. If you're shy: just don't be :).
It's a really good example that was working before and is not working easily anymore. The original bug (#334) was proposing another solution, but I do prefer the current one, because it's a bit more secure. We could:
@maniackcrudelis @daald @prlw1 What do you think of that? I like 2 and 4. |
|
I know you're french. We work at few kilometers one of the other. I translate in english (at least google does...) precisely because I understand the problem to be as universal as possible. But to read me, and for those who are allergic or do not understand english, allows me to express myself in words I understand. The fourth solution seems very interesting, because it would use complex rules early in the rights file and block if validated. At the moment, for my use, I patched the regex.py file. It works, but this idea seems a great way to fix this. Je sais que tu es toi même français, nous travaillons à quelques kilomètres d'intervalle. Je traduis en anglais (du moins google le fait...) justement car je comprend la problématique d'être le plus universel possible. Mais pour me relire, et pour tout ceux qui sont allergique ou qui ne comprenne pas l'anglais, permet moi de m'exprimer en des termes que je comprends. La 4e solution me parait très intéressante, car elle permettrait d'utiliser des règles complexes au début du fichier de droits et de bloquer si elles sont validées. Pour le moment, pour mon usage, j'ai patché le fichier regex.py. Ça fonctionne, mais cette idée me semble un excellent moyen d'arranger tout ça. |
|
Well… After diving into the code, I think that your example actually works. When User1 tries to reach User2's calendar, the first rule doesn't match but the second one does, giving User1 read access as needed. Did I miss something? |
|
Yes I see, as I wrote in fact, it should not validate the first rule. For keeping only But this only rule seems not permitted to see the contents of the collection: I found myself obliged to put this rule for the collection to be readable, and it may have a right to read and write the contents of the collection. A problem also happens for calendar sharing on clients that do not allow to connect to a specific calendar, only the complete collection. Typically a phone on android with DAVdroid. Oui je vois, tel que je l'ai écrit en effet, il ne devrait pas valider la première règle. Pour ne garder que Mais cette règle seule semble ne pas permettre de voir le contenu de la collection: Je me suis trouvé obligé de remettre cette règle pour que la collection soit lisible, et qu'il puisse avoir un droit de lecture et d'écriture sur le contenu de la collection. Un problème se pose également pour le partage d'agenda sur des clients qui ne permette pas de se connecter à un calendrier en particulier, uniquement la collection complète. Typiquement un téléphone sous android avec DAVdroid. |
|
I don't get it. I think that what you need is: [owner-write]
user: .+
collection: ^%(login)s/.+$
permission: rw
[allow-everyone-read]
user: .+
collection: .*
permission: rIs there anything wrong with that for your use?
That's another point. This behaviour is caused by two different problems:
With the rights rules above and The problem is that because of point 1, you need one account ( Another solution is to use a different pattern for your calendars. Keeping only 1 depth (storing calendars in |
|
The order of owner-write and allow-everyone-read not matter in my use case since regex.py is patched to not stop at the first validated rule. The problem is that without the rule allow-everyone-read, the collection appears empty because it does not get any reading right and the client (InfCloud) refuses to connect. That may be abnormal behavior? Here is the log of what happened: If I re-established the rule, everything is back in order. The client will connect to https://domain.tld/radicale/ I had not thought possible to create schedules in this way user1-calendar1.ics. In the state, the rights of the file rights prohibit me but it must be corrected. Anyway, I think come to the same conclusion. DAVdroid is capable of charging multiple accounts, so he should be able to access these shares. However this is not the case for Agendav or CalDavZap. Finally to return about this issue, do you think as even if share calendars, it is possible to get by with a blocking rule? L'ordre de owner-write et allow-everyone-read importe peu dans mon cas d'usage puisque regex.py est patché pour ne pas s'arrêter à la première règle validée. Le problème est bien que sans la règle allow-everyone-read, la collection apparait vide car il n'obtient aucun droit de lecture et le client (InfCloud) refuse de se connecter. C'est peut-être un comportement anormal? Voila le log de ce qui s'est passé: Si je rétabli la règle, tout entre en ordre. Le client se connecte à l'adresse https://domain.tld/radicale/ Je ne pensais pas possible de créer des calendriers de cette manière, user1-calendar1.ics. En l'état, les droits du fichier rights me l'interdise mais ça doit pouvoir se corriger. Quoi qu'il en soit, je crois arriver à la même conclusion. DAVdroid est capable de charger plusieurs comptes, donc il devrait pouvoir accéder à ces partages. En revanche ce n'est pas le cas de Agendav et CalDavZap. Enfin pour revenir au sujet de cet issue, penses-tu alors que même en cas de partage de calendriers, il est possible de s'en sortir avec une règle bloquante? |
|
I think that with the current |
Hello,
Following the PR #335, the default rules of the rights file does not work.
The rule allow-everyone-read match before owner-write, so registered users have no write access...
The solution of course would be to reverse the order of the rules.
But this principle to stop at the first match rule is a real problem. It prevents creation of more complex rules (except to tear his hair with regex). This makes it impossible to authorize share a calendar for a user, as it has been before match in the file.
The text was updated successfully, but these errors were encountered: