#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