weird logging behavior
Hi list, we are on Mac OSX Lion server ( 10.7.4 ) and here is a snippet from our logfile /var/log/caldavd/access.log. We would like to know why first time we get a entry with the correct username, but second time a empty string for the same user? It's a little bit confusing, because we run a wallboard for monitoring the usage on our server and the 'top ten' users, but the empty string is not so nice ;) I removed the ip address and the UUID, but both has the same values in the original logfile. Is there a way to get this corrected? 127.0.0.1 - username [18/Mar/2013:14:21:47 +0200] "PROPFIND /principals/__uids__/the_UUID_of_the_user/ HTTP/1.1" 207 1366 "-" "Mac OS X/10.8.2 (12C3012) CalendarAgent/55" i=7 t=12.0 or=1 cached=1 xff=xx.xx.xx.xx fwd=xx.xx.xx.xx 127.0.0.1 - - [18/Mar/2013:14:22:21 +0200] "PROPFIND /principals/__uids__/the_same_UUID_as_in_the_entry_before/ HTTP/1.1" 401 141 "-" "Mac OS X/10.8.2 (12C3012) CalendarAgent/55" i=6 t=14.6 or=1 xff=xx.xx.xx.xx fwd=xx.xx.xx.xx Thanks, Sirko
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. On Mar 21, 2013, at 7:22 AM, Sirko Mann <smann@datameer.com> wrote:
Hi list,
we are on Mac OSX Lion server ( 10.7.4 ) and here is a snippet from our logfile /var/log/caldavd/access.log. We would like to know why first time we get a entry with the correct username, but second time a empty string for the same user? It's a little bit confusing, because we run a wallboard for monitoring the usage on our server and the 'top ten' users, but the empty string is not so nice ;) I removed the ip address and the UUID, but both has the same values in the original logfile. Is there a way to get this corrected?
127.0.0.1 - username [18/Mar/2013:14:21:47 +0200] "PROPFIND /principals/__uids__/the_UUID_of_the_user/ HTTP/1.1" 207 1366 "-" "Mac OS X/10.8.2 (12C3012) CalendarAgent/55" i=7 t=12.0 or=1 cached=1 xff=xx.xx.xx.xx fwd=xx.xx.xx.xx 127.0.0.1 - - [18/Mar/2013:14:22:21 +0200] "PROPFIND /principals/__uids__/the_same_UUID_as_in_the_entry_before/ HTTP/1.1" 401 141 "-" "Mac OS X/10.8.2 (12C3012) CalendarAgent/55" i=6 t=14.6 or=1 xff=xx.xx.xx.xx fwd=xx.xx.xx.xx
Thanks, Sirko
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users
Hi Morgen, great, that helps me. Just wanted to make sure that this is not a bug. Sirko On 21.03.2013, at 15:44, Morgen Sagen wrote:
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.
On Mar 21, 2013, at 7:22 AM, Sirko Mann <smann@datameer.com> wrote:
Hi list,
we are on Mac OSX Lion server ( 10.7.4 ) and here is a snippet from our logfile /var/log/caldavd/access.log. We would like to know why first time we get a entry with the correct username, but second time a empty string for the same user? It's a little bit confusing, because we run a wallboard for monitoring the usage on our server and the 'top ten' users, but the empty string is not so nice ;) I removed the ip address and the UUID, but both has the same values in the original logfile. Is there a way to get this corrected?
127.0.0.1 - username [18/Mar/2013:14:21:47 +0200] "PROPFIND /principals/__uids__/the_UUID_of_the_user/ HTTP/1.1" 207 1366 "-" "Mac OS X/10.8.2 (12C3012) CalendarAgent/55" i=7 t=12.0 or=1 cached=1 xff=xx.xx.xx.xx fwd=xx.xx.xx.xx 127.0.0.1 - - [18/Mar/2013:14:22:21 +0200] "PROPFIND /principals/__uids__/the_same_UUID_as_in_the_entry_before/ HTTP/1.1" 401 141 "-" "Mac OS X/10.8.2 (12C3012) CalendarAgent/55" i=6 t=14.6 or=1 xff=xx.xx.xx.xx fwd=xx.xx.xx.xx
Thanks, Sirko
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users
------------------------------------------------------------------------------------------------ Datameer GmbH, Grosse Ulrichstrasse 7-9, D-06108 Halle (Saale), Amtsgericht Stendal, HRB: 10348, Geschäftsführer: Stefan Groschupf
Hi List, We're on Mac OSX Lion server 10.7.3 and before me, someone else was responsible for the server. Now I'm the person which have to take care of the server and I try now to fix some issues. One issue we found is this in our error logfile for caldavd. from the /var/log/caldavd/error.log ... 2013-03-21 16:00:50+0100 [-] [mailgateway] 2013-03-21 16:00:50+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['HIGHESTMODSEQ', '1'], 'Highest'] 2013-03-21 16:00:50+0100 [-] [mailgateway] 2013-03-21 16:00:50+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['URLMECH', 'INTERNAL'], 'Mechanisms', 'supported'] 2013-03-21 16:01:20+0100 [-] [mailgateway] 2013-03-21 16:01:20+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['HIGHESTMODSEQ', '1'], 'Highest'] 2013-03-21 16:01:20+0100 [-] [mailgateway] 2013-03-21 16:01:20+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['URLMECH', 'INTERNAL'], 'Mechanisms', 'supported'] 2013-03-21 16:01:50+0100 [-] [mailgateway] 2013-03-21 16:01:50+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['HIGHESTMODSEQ', '1'], 'Highest'] 2013-03-21 16:01:50+0100 [-] [mailgateway] 2013-03-21 16:01:50+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['URLMECH', 'INTERNAL'], 'Mechanisms', 'supported'] 2013-03-21 16:02:20+0100 [-] [mailgateway] 2013-03-21 16:02:20+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['HIGHESTMODSEQ', '1'], 'Highest'] 2013-03-21 16:02:20+0100 [-] [mailgateway] 2013-03-21 16:02:20+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['URLMECH', 'INTERNAL'], 'Mechanisms', 'supported'] 2013-03-21 16:02:50+0100 [-] [mailgateway] 2013-03-21 16:02:50+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['HIGHESTMODSEQ', '1'], 'Highest'] 2013-03-21 16:02:50+0100 [-] [mailgateway] 2013-03-21 16:02:50+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['URLMECH', 'INTERNAL'], 'Mechanisms', 'supported'] 2013-03-21 16:03:20+0100 [-] [mailgateway] 2013-03-21 16:03:20+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['HIGHESTMODSEQ', '1'], 'Highest'] ... What does this mean and how can we fix this, get rid of? Thanks, Sirko
Those are annoying but harmless, and I believe have already been taken care of in more recent versions of OS X Server. I don't remember exactly when it was fixed, but I'm running Server 2.2.1 on top of OS X 10.8.2 and I don't see those messages. On Mar 21, 2013, at 8:14 AM, Sirko Mann <smann@datameer.com> wrote:
Hi List,
We're on Mac OSX Lion server 10.7.3 and before me, someone else was responsible for the server. Now I'm the person which have to take care of the server and I try now to fix some issues. One issue we found is this in our error logfile for caldavd.
from the /var/log/caldavd/error.log
... 2013-03-21 16:00:50+0100 [-] [mailgateway] 2013-03-21 16:00:50+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['HIGHESTMODSEQ', '1'], 'Highest'] 2013-03-21 16:00:50+0100 [-] [mailgateway] 2013-03-21 16:00:50+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['URLMECH', 'INTERNAL'], 'Mechanisms', 'supported'] 2013-03-21 16:01:20+0100 [-] [mailgateway] 2013-03-21 16:01:20+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['HIGHESTMODSEQ', '1'], 'Highest'] 2013-03-21 16:01:20+0100 [-] [mailgateway] 2013-03-21 16:01:20+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['URLMECH', 'INTERNAL'], 'Mechanisms', 'supported'] 2013-03-21 16:01:50+0100 [-] [mailgateway] 2013-03-21 16:01:50+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['HIGHESTMODSEQ', '1'], 'Highest'] 2013-03-21 16:01:50+0100 [-] [mailgateway] 2013-03-21 16:01:50+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['URLMECH', 'INTERNAL'], 'Mechanisms', 'supported'] 2013-03-21 16:02:20+0100 [-] [mailgateway] 2013-03-21 16:02:20+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['HIGHESTMODSEQ', '1'], 'Highest'] 2013-03-21 16:02:20+0100 [-] [mailgateway] 2013-03-21 16:02:20+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['URLMECH', 'INTERNAL'], 'Mechanisms', 'supported'] 2013-03-21 16:02:50+0100 [-] [mailgateway] 2013-03-21 16:02:50+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['HIGHESTMODSEQ', '1'], 'Highest'] 2013-03-21 16:02:50+0100 [-] [mailgateway] 2013-03-21 16:02:50+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['URLMECH', 'INTERNAL'], 'Mechanisms', 'supported'] 2013-03-21 16:03:20+0100 [-] [mailgateway] 2013-03-21 16:03:20+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['HIGHESTMODSEQ', '1'], 'Highest'] ...
What does this mean and how can we fix this, get rid of?
Thanks, Sirko _______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users
Hi Morgan, Thanks for your quick response. I try since 3 days to find a answer on this, but in Apple's support forum nobody answered. So you say we can safely ignoring this. But I would like to get rid of them. We wont upgrade to 10.8 at the moment. Is there any other way to fix this? Thanks, Sirko On 21.03.2013, at 16:25, Morgen Sagen wrote:
Those are annoying but harmless, and I believe have already been taken care of in more recent versions of OS X Server. I don't remember exactly when it was fixed, but I'm running Server 2.2.1 on top of OS X 10.8.2 and I don't see those messages.
On Mar 21, 2013, at 8:14 AM, Sirko Mann <smann@datameer.com> wrote:
Hi List,
We're on Mac OSX Lion server 10.7.3 and before me, someone else was responsible for the server. Now I'm the person which have to take care of the server and I try now to fix some issues. One issue we found is this in our error logfile for caldavd.
from the /var/log/caldavd/error.log
... 2013-03-21 16:00:50+0100 [-] [mailgateway] 2013-03-21 16:00:50+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['HIGHESTMODSEQ', '1'], 'Highest'] 2013-03-21 16:00:50+0100 [-] [mailgateway] 2013-03-21 16:00:50+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['URLMECH', 'INTERNAL'], 'Mechanisms', 'supported'] 2013-03-21 16:01:20+0100 [-] [mailgateway] 2013-03-21 16:01:20+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['HIGHESTMODSEQ', '1'], 'Highest'] 2013-03-21 16:01:20+0100 [-] [mailgateway] 2013-03-21 16:01:20+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['URLMECH', 'INTERNAL'], 'Mechanisms', 'supported'] 2013-03-21 16:01:50+0100 [-] [mailgateway] 2013-03-21 16:01:50+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['HIGHESTMODSEQ', '1'], 'Highest'] 2013-03-21 16:01:50+0100 [-] [mailgateway] 2013-03-21 16:01:50+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['URLMECH', 'INTERNAL'], 'Mechanisms', 'supported'] 2013-03-21 16:02:20+0100 [-] [mailgateway] 2013-03-21 16:02:20+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['HIGHESTMODSEQ', '1'], 'Highest'] 2013-03-21 16:02:20+0100 [-] [mailgateway] 2013-03-21 16:02:20+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['URLMECH', 'INTERNAL'], 'Mechanisms', 'supported'] 2013-03-21 16:02:50+0100 [-] [mailgateway] 2013-03-21 16:02:50+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['HIGHESTMODSEQ', '1'], 'Highest'] 2013-03-21 16:02:50+0100 [-] [mailgateway] 2013-03-21 16:02:50+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['URLMECH', 'INTERNAL'], 'Mechanisms', 'supported'] 2013-03-21 16:03:20+0100 [-] [mailgateway] 2013-03-21 16:03:20+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['HIGHESTMODSEQ', '1'], 'Highest'] ...
What does this mean and how can we fix this, get rid of?
Thanks, Sirko _______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users
------------------------------------------------------------------------------------------------ Datameer GmbH, Grosse Ulrichstrasse 7-9, D-06108 Halle (Saale), Amtsgericht Stendal, HRB: 10348, Geschäftsführer: Stefan Groschupf
On Mar 21, 2013, at 4:25 PM, Morgen Sagen wrote: Hi Morgen,
Those are annoying but harmless, and I believe have already been taken care of in more recent versions of OS X Server. I don't remember exactly when it was fixed, but I'm running Server 2.2.1 on top of OS X 10.8.2 and I don't see those messages.
Hmm. We are running caldav in production, so we can't update osx or any other software for now. did you see another way than update, to avoid "spam" messages (or non error messages) in our error log file. these messages occurs 40times in every 10 minutes. thx marko
from the /var/log/caldavd/error.log
... 2013-03-21 16:00:50+0100 [-] [mailgateway] 2013-03-21 16:00:50+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['HIGHESTMODSEQ', '1'], 'Highest']
I sent Sirko a possible workaround to try yesterday. ~morgen On Mar 22, 2013, at 12:46 AM, Marko Bauhardt <mb@datameer.com> wrote:
On Mar 21, 2013, at 4:25 PM, Morgen Sagen wrote:
Hi Morgen,
Those are annoying but harmless, and I believe have already been taken care of in more recent versions of OS X Server. I don't remember exactly when it was fixed, but I'm running Server 2.2.1 on top of OS X 10.8.2 and I don't see those messages.
Hmm. We are running caldav in production, so we can't update osx or any other software for now. did you see another way than update, to avoid "spam" messages (or non error messages) in our error log file. these messages occurs 40times in every 10 minutes.
thx marko
from the /var/log/caldavd/error.log
... 2013-03-21 16:00:50+0100 [-] [mailgateway] 2013-03-21 16:00:50+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['HIGHESTMODSEQ', '1'], 'Highest']
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users
Hi Morgen, we decided to try the workaround and it seems to work! :D Thanks for that!! The error message is gone and now we see the real errors ;) Sirko On 22.03.2013, at 17:47, Morgen Sagen <sagen@apple.com> wrote:
I sent Sirko a possible workaround to try yesterday.
~morgen
On Mar 22, 2013, at 12:46 AM, Marko Bauhardt <mb@datameer.com> wrote:
On Mar 21, 2013, at 4:25 PM, Morgen Sagen wrote:
Hi Morgen,
Those are annoying but harmless, and I believe have already been taken care of in more recent versions of OS X Server. I don't remember exactly when it was fixed, but I'm running Server 2.2.1 on top of OS X 10.8.2 and I don't see those messages.
Hmm. We are running caldav in production, so we can't update osx or any other software for now. did you see another way than update, to avoid "spam" messages (or non error messages) in our error log file. these messages occurs 40times in every 10 minutes.
thx marko
from the /var/log/caldavd/error.log
... 2013-03-21 16:00:50+0100 [-] [mailgateway] 2013-03-21 16:00:50+0100 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['HIGHESTMODSEQ', '1'], 'Highest']
_______________________________________________ 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
------------------------------------------------------------------------------------------------ Datameer GmbH, Grosse Ulrichstrasse 7-9, D-06108 Halle (Saale), Amtsgericht Stendal, HRB: 10348, Geschäftsführer: Stefan Groschupf
Hi List, we want to change the behavior of logging for the access.log. At the moment we have a rotation of almost every day: ... -rw-r--r-- 1 root _calendar 7.2M Feb 21 00:00 access.log.2013_2_20 -rw-r--r-- 1 root _calendar 6.0M Feb 22 00:00 access.log.2013_2_21 -rw-r--r-- 1 root _calendar 4.5M Feb 23 00:00 access.log.2013_2_22 -rw-r--r-- 1 root _calendar 1.9M Feb 24 00:05 access.log.2013_2_23 -rw-r--r-- 1 root _calendar 1.5M Feb 25 00:01 access.log.2013_2_24 -rw-r--r-- 1 root _calendar 7.2M Feb 26 00:00 access.log.2013_2_25 -rw-r--r-- 1 root _calendar 7.9M Feb 27 00:00 access.log.2013_2_26 -rw-r--r-- 1 root _calendar 12M Feb 28 00:00 access.log.2013_2_27 … We want to have this for at least 2 days. My question now is how we have to do this? bash-3.2# serveradmin settings calendar | grep -i log calendar:ErrorLogFile = "error.log" calendar:DefaultLogLevel = "warn" calendar:ErrorLogRotateMB = 100 calendar:LogRoot = "/var/log/caldavd" calendar:AccessLogFile = "access.log" calendar:RotateAccessLog = yes calendar:ErrorLogMaxRotatedFiles = 365 serveradmin settings calendar:ErrorLogMaxRotatedFiles = xxx <- will it work when I change it in this way? What is the value I have to fill in? When I use e.g. 120 will the access.log file rotated every 3 days? I also looked through /etc/caldavd/caldavd.plist but seems that there is no value for the rotation stuff. Or do I have to do it with 'newsyslog'? Thanks, Sirko
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? 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? Thanks Marko
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, 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
Ah! Perfect. Understand. Thanks. Marko On Mar 21, 2013, at 4:19 PM, Pascal Robert 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, 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
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
Le 2013-03-21 à 11:38, Andre LaBranche <dre@apple.com> a écrit :
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.
Ah, I didn't know Basic worked with iCal Server (not Calendar Server), I thought only Digest and Kerberos was supported.
-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
On Mar 21, 2013, at 9:45 AM, Pascal Robert <probert@macti.ca> wrote:
Le 2013-03-21 à 11:38, Andre LaBranche <dre@apple.com> a écrit :
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.
Ah, I didn't know Basic worked with iCal Server (not Calendar Server), I thought only Digest and Kerberos was supported.
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 :) -dre
-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
participants (5)
-
Andre LaBranche
-
Marko Bauhardt
-
Morgen Sagen
-
Pascal Robert
-
Sirko Mann