On Mar 21, 2013, at 8:19 AM, Pascal Robert <probert@macti.ca> wrote:
Le 2013-03-21 à 11:14, Marko Bauhardt <mb@datameer.com> a écrit :
Hi Morgen
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.
unauthenticated requests means at least one client which is not logged in tries to connect to our calendar?
It is normal… Especially by the fact that iCal Server don't support Basic auth,
Hi, 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. -dre
so the client must do at least one non-auth request to do the Digest workflow. This is just like a browser would do.
so we have to figure out which client is making so many requests to our calendar installation.
we found also in our logs user names in a UUID style, e.g.: 1234-4321-abcd Any idea who is sending those usernames?
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.
Thanks Marko
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users