<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Mar 21, 2013, at 9:45 AM, Pascal Robert <<a href="mailto:probert@macti.ca">probert@macti.ca</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>Le 2013-03-21 à 11:38, Andre LaBranche <<a href="mailto:dre@apple.com">dre@apple.com</a>> a écrit :<br><br><blockquote type="cite"><br>On Mar 21, 2013, at 8:19 AM, Pascal Robert <<a href="mailto:probert@macti.ca">probert@macti.ca</a>> wrote:<br><br><blockquote type="cite"><br>Le 2013-03-21 à 11:14, Marko Bauhardt <<a href="mailto:mb@datameer.com">mb@datameer.com</a>> a écrit :<br><br><blockquote type="cite">Hi Morgen<br><br><blockquote type="cite">The entry without a username is normal and is because the request wasn't authenticated (note the 401 HTTP response status). In response to a 401 the user-agent will repeat the request with credentials included and you should then get a 20X response and an access.log entry with the authenticated username.<br></blockquote><br>unauthenticated requests means at least one client which is not logged in tries to connect to our calendar?<br></blockquote><br>It is normal… Especially by the fact that iCal Server don't support Basic auth,<br></blockquote><br>Hi,<br><br>Just a minor comment here; we do support Basic (Authentication --> Basic --> Enabled == True), but its use is discouraged for security reasons. It's only reasonably safe to use Basic over SSL. As of r10129 (in trunk, and going forward) we disallow use of Basic (even if it's enabled) unless the client is connecting over SSL. If you really want Basic over non-SSL, you have to set Authentication --> Basic --> AllowedOverWireUnencrypted == True.<br></blockquote><br>Ah, I didn't know Basic worked with iCal Server (not Calendar Server), I thought only Digest and Kerberos was supported.<br></div></blockquote><div><br></div><div>It's probably true that only Digest and Kerberos are supported in OS X Server / iCal Server :) There is always a gap between "works" and "supported". Mind that gap :)</div><div><br></div><div>-dre</div><br><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br><blockquote type="cite">-dre<br><br><blockquote type="cite">so the client must do at least one non-auth request to do the Digest workflow. This is just like a browser would do.<br><br><blockquote type="cite">so we have to figure out which client is making so many requests to our calendar installation.<br><br>we found also in our logs user names in a UUID style, e.g.: 1234-4321-abcd<br>Any idea who is sending those usernames?<br></blockquote><br>It's iCal itself who use this, and it's perfectly good. Resources in iCal Server are accessible by both the username or the UUID. It's not a problem.<br><br><blockquote type="cite">Thanks<br>Marko<br><br><br>_______________________________________________<br>calendarserver-users mailing list<br><a href="mailto:calendarserver-users@lists.macosforge.org">calendarserver-users@lists.macosforge.org</a><br>https://lists.macosforge.org/mailman/listinfo/calendarserver-users<br></blockquote><br>_______________________________________________<br>calendarserver-users mailing list<br><a href="mailto:calendarserver-users@lists.macosforge.org">calendarserver-users@lists.macosforge.org</a><br>https://lists.macosforge.org/mailman/listinfo/calendarserver-users</blockquote></blockquote></div></blockquote></div><br></body></html>