[CalendarServer-dev] [CalendarServer] #350: location in snow leopard, more explanation about the problem

[CalendarServer]

#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 at 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 at 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