#350: location in snow leopard, more explanation about the problem
-----------------------------------+----------------------------------------
Reporter: jduff...@… | Owner: wsanc...@…
Type: Defect | Status: new
Priority: 1: Blocker | Milestone: Later
Component: Calendar Server | Severity: Other
Keywords: location snow leopard |
-----------------------------------+----------------------------------------
Comment(by jduff...@…):
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>r...@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>r...@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
_______________________________________________
calendarserver-dev mailing list
calendarserver-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev
