[CalendarServer] #350: location in snow leopard, more explanation about the problem
#350: location in snow leopard, more explanation about the problem -----------------------------------+---------------------------------------- Reporter: jduffas1@… | Owner: wsanchez@… Type: Defect | Status: new Priority: 1: Blocker | Milestone: Later Component: Calendar Server | Severity: Other Keywords: location snow leopard | -----------------------------------+---------------------------------------- a <location> should not function as a <user>. normally, some people should be allowed to book locations (through <proxies>) but <locations> should always accept the booking (they have no choice to do this, they are not alive...) so, we can imagine that <locations> are programmated this way, and that the xml file should look like this: <location> <uid>rfi</uid> <guid>F2F2B56A-7B0E-498C-816F-1DA30D8A4168</guid> <password>dddd</password> <name>rfi</name> <email-address>rfi@free.fr</email-address> <proxies> <member type="users">jduffas</member> </proxies> </location> that way, only the user "jduffas" can access that <location>. But the problem is that the <location> accepts half the appointments: it leaves the question mark on the event's user having asked, however, the room still appears as reserved in the availability tool... worse, if I use another user (who is not in <proxies>, the server reacts completely identical. Now, if I add a <auto-schedule/>, the <location> accepts routinely the appointment, whatever the user is (in the <proxies> or not.) wholesale <proxies> in <locations> is not active, which represents a big security hole. the same in french (my language... i'm bad in english) un lieu ne devrait pas fonctionner comme un user. normalement, certaines personnes devraient être autorisées à réserver des lieux (grâce au proxi) mais les lieus devraient toujours accepter les réservation (ils n'ont pas le choix à faire, ce ne sont pas des être vivants) pour cellà, soit on se dit que les lieus sont programmés ainsi, et qu'il suffit de rentrer dans le .xml quelque chose de ce genre : <location> <uid>rfi</uid> <guid>F2F2B56A-7B0E-498C-816F-1DA30D8A4168</guid> <password>dddd</password> <name>rfi</name> <email-address>rfi@free.fr</email-address> <proxies> <member type="users">jduffas</member> </proxies> </location> ainsi seul le user "jduffas" pourra accéder au lieu. mais le hic est que le lieu accepte à moitié le rendez-vous : il laisse le point d'interrogation sur l'événement du user l'ayant demandé, en revanche, la salle apparait quand même comme réservée dans l'outil de disponibilité pire, si j'utilise un autre user (qui ne se trouve pas dans <proxies>, le serveur réagit de façon totalement identique. maintenant, si j'ajoute un <auto-schedule/>, le lieu est accepté systématiquement, quelque soit le user (qu'il soit dans le <proxies> ou non.) en gros, <proxies> dans les <locations> n'est pas actif, ce qui représente une grosse faille de sécurité. -- Ticket URL: <http://trac.calendarserver.org/ticket/350> CalendarServer </> HTTP/WebDAV/CalDAV Server
#350: location in snow leopard, more explanation about the problem -----------------------------------+---------------------------------------- Reporter: jduffas1@… | Owner: wsanchez@… Type: Defect | Status: new Priority: 1: Blocker | Milestone: Later Component: Calendar Server | Severity: Other Keywords: location snow leopard | -----------------------------------+---------------------------------------- Comment(by jduffas1@…): oups, sorry, I made a mistake, read this instead of the precedent : a <location> should not function as a <user>. normally, some people should be allowed to book locations (through <proxies>) but <locations> should always accept the booking (they have no choice to do this, they are not alive...) so, we can imagine that <locations> are programmated this way, and that the xml file should look like this: <location> <uid>rfi</uid> <guid>F2F2B56A-7B0E-498C-816F-1DA30D8A4168</guid> <password>dddd</password> <name>rfi</name> <email-address>rfi@free.fr</email-address> <proxies> <member type="users">jduffas2</member> </proxies> </location> that way, only the user "jduffas" can access that <location>. But the problem is that the <location> doesn't accept the appointments (it has to be done manually with a delegated calendar) : it leaves the question mark on the event's user having asked. worse, if I use another user (who is not in <proxies>, the server reacts completely identical. Now, if I add a <auto-schedule/>, the <location> accepts routinely the appointment, whatever the user is (in the <proxies> or not.) wholesale <proxies> in <locations> is not active, which represents a big security hole. the same in french (my language... i'm bad in english) un lieu ne devrait pas fonctionner comme un user. normalement, certaines personnes devraient être autorisées à réserver des lieux (grâce au proxi) mais les lieus devraient toujours accepter les réservation (ils n'ont pas le choix à faire, ce ne sont pas des être vivants) pour cellà, soit on se dit que les lieus sont programmés ainsi, et qu'il suffit de rentrer dans le .xml quelque chose de ce genre : <location> <uid>rfi</uid> <guid>F2F2B56A-7B0E-498C-816F-1DA30D8A4168</guid> <password>dddd</password> <name>rfi</name> <email-address>rfi@free.fr</email-address> <proxies> <member type="users">jduffas2</member> </proxies> </location> ainsi seul le user "jduffas" pourra accéder au lieu. mais le hic est que le lieu n'accepte jamais le rendez-vous (il faudrait le faire manuellement avec un calendrier délégué…) : il laisse le point d'interrogation sur l'événement du user l'ayant demandé. pire, si j'utilise un autre user (qui ne se trouve pas dans <proxies>, le serveur réagit de façon totalement identique. maintenant, si j'ajoute un <auto-schedule/>, le rendez-vous dans le lieu est accepté systématiquement, quelque soit le user (qu'il soit dans le <proxies> ou non.) en gros, <proxies> dans les <locations> n'est pas actif, ce qui représente une grosse faille de sécurité. -- Ticket URL: <http://trac.calendarserver.org/ticket/350#comment:1> CalendarServer </> HTTP/WebDAV/CalDAV Server
#350: location in snow leopard, more explanation about the problem -----------------------------------+---------------------------------------- Reporter: jduffas1@… | Owner: wsanchez@… Type: Defect | Status: new Priority: 1: Blocker | Milestone: Later Component: Calendar Server | Severity: Other Keywords: location snow leopard | -----------------------------------+---------------------------------------- Description changed by wsanchez@…: Old description:
a <location> should not function as a <user>. normally, some people should be allowed to book locations (through <proxies>) but <locations> should always accept the booking (they have no choice to do this, they are not alive...)
so, we can imagine that <locations> are programmated this way, and that the xml file should look like this:
<location> <uid>rfi</uid> <guid>F2F2B56A-7B0E-498C-816F-1DA30D8A4168</guid> <password>dddd</password> <name>rfi</name> <email-address>rfi@free.fr</email-address> <proxies> <member type="users">jduffas</member> </proxies> </location>
that way, only the user "jduffas" can access that <location>. But the problem is that the <location> accepts half the appointments: it leaves the question mark on the event's user having asked, however, the room still appears as reserved in the availability tool...
worse, if I use another user (who is not in <proxies>, the server reacts completely identical.
Now, if I add a <auto-schedule/>, the <location> accepts routinely the appointment, whatever the user is (in the <proxies> or not.)
wholesale <proxies> in <locations> is not active, which represents a big security hole.
the same in french (my language... i'm bad in english)
un lieu ne devrait pas fonctionner comme un user. normalement, certaines personnes devraient être autorisées à réserver des lieux (grâce au proxi) mais les lieus devraient toujours accepter les réservation (ils n'ont pas le choix à faire, ce ne sont pas des être vivants)
pour cellà, soit on se dit que les lieus sont programmés ainsi, et qu'il suffit de rentrer dans le .xml quelque chose de ce genre :
<location> <uid>rfi</uid> <guid>F2F2B56A-7B0E-498C-816F-1DA30D8A4168</guid> <password>dddd</password> <name>rfi</name> <email-address>rfi@free.fr</email-address> <proxies> <member type="users">jduffas</member> </proxies> </location>
ainsi seul le user "jduffas" pourra accéder au lieu. mais le hic est que le lieu accepte à moitié le rendez-vous : il laisse le point d'interrogation sur l'événement du user l'ayant demandé, en revanche, la salle apparait quand même comme réservée dans l'outil de disponibilité
pire, si j'utilise un autre user (qui ne se trouve pas dans <proxies>, le serveur réagit de façon totalement identique.
maintenant, si j'ajoute un <auto-schedule/>, le lieu est accepté systématiquement, quelque soit le user (qu'il soit dans le <proxies> ou non.)
en gros, <proxies> dans les <locations> n'est pas actif, ce qui représente une grosse faille de sécurité.
New description: a <location> should not function as a <user>. normally, some people should be allowed to book locations (through <proxies>) but <locations> should always accept the booking (they have no choice to do this, they are not alive...) so, we can imagine that <locations> are programmated this way, and that the xml file should look like this: {{{ <location> <uid>rfi</uid> <guid>F2F2B56A-7B0E-498C-816F-1DA30D8A4168</guid> <password>dddd</password> <name>rfi</name> <email-address>rfi@free.fr</email-address> <proxies> <member type="users">jduffas</member> </proxies> </location> }}} that way, only the user "jduffas" can access that <location>. But the problem is that the <location> accepts half the appointments: it leaves the question mark on the event's user having asked, however, the room still appears as reserved in the availability tool... worse, if I use another user (who is not in <proxies>, the server reacts completely identical. Now, if I add a <auto-schedule/>, the <location> accepts routinely the appointment, whatever the user is (in the <proxies> or not.) wholesale <proxies> in <locations> is not active, which represents a big security hole. the same in french (my language... i'm bad in english) un lieu ne devrait pas fonctionner comme un user. normalement, certaines personnes devraient être autorisées à réserver des lieux (grâce au proxi) mais les lieus devraient toujours accepter les réservation (ils n'ont pas le choix à faire, ce ne sont pas des être vivants) pour cellà, soit on se dit que les lieus sont programmés ainsi, et qu'il suffit de rentrer dans le .xml quelque chose de ce genre : {{{ <location> <uid>rfi</uid> <guid>F2F2B56A-7B0E-498C-816F-1DA30D8A4168</guid> <password>dddd</password> <name>rfi</name> <email-address>rfi@free.fr</email-address> <proxies> <member type="users">jduffas</member> </proxies> </location> }}} ainsi seul le user "jduffas" pourra accéder au lieu. mais le hic est que le lieu accepte à moitié le rendez-vous : il laisse le point d'interrogation sur l'événement du user l'ayant demandé, en revanche, la salle apparait quand même comme réservée dans l'outil de disponibilité pire, si j'utilise un autre user (qui ne se trouve pas dans <proxies>, le serveur réagit de façon totalement identique. maintenant, si j'ajoute un <auto-schedule/>, le lieu est accepté systématiquement, quelque soit le user (qu'il soit dans le <proxies> ou non.) en gros, <proxies> dans les <locations> n'est pas actif, ce qui représente une grosse faille de sécurité. -- -- Ticket URL: <http://trac.calendarserver.org/ticket/350#comment:2> CalendarServer </> HTTP/WebDAV/CalDAV Server
#350: Need controls on auto-accept to specify who can book a location/resource ------------------------------+--------------------------------------------- Reporter: jduffas1@… | Owner: wsanchez@… Type: Feature | Status: new Priority: 3: Important | Milestone: Later Component: Calendar Server | Severity: Other Keywords: | ------------------------------+--------------------------------------------- Changes (by wsanchez@…): * keywords: location snow leopard => * priority: 1: Blocker => 3: Important * type: Defect => Feature Comment: I think what you are asking for in a way to restrict the auto-accept functionality so that it will only accept meetings from certain principals and decline requests from any others. Changing the summary. -- Ticket URL: <http://trac.calendarserver.org/ticket/350#comment:3> CalendarServer </> HTTP/WebDAV/CalDAV Server
participants (1)
-
CalendarServer