macOS/iOS/iPadOS CalDAV clients try to log in as anonymous? #1411
Unanswered
gitkohster
asked this question in
Q&A client
Replies: 10 comments 3 replies
-
|
As a test, I added a test anonymous section to my rights file: Then I restarted the server with debug logging turned on. Here's the failed initial connection attempt from macOS Calendar.app. Then immediately after that is the successful connection: |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I have this same anonymous user problem and it is maddening. I have used radicale for several years without problem including still on an old mac running mojave but with ventura (macbook, macbook air m2, mac mini m2 pro) and maybe monterey (can't remember now) I too get the anonymous user problem. On my macs I only have one account setup for radicale with proper credentials for both caldav and carddav so I don't know why the macs do anon requests. And it is not just the first request in a refresh but interspersed throughout. I sometimes get the request for the account password but mostly a little black triangle for error. Repeated refreshes sometimes work but sometimes I have to undo changes, refresh multiple times, then redo changes and try multiple refreshes again. My android phone has no problem refreshing. Note that in the successful http requests there is "HTTP_AUTHORIZATION': 'Basic masked'" which is missing from the anonymous requests. I don't know what apple changed and I don't expect them to fix this. I left a comment in apple discussion threads back in march and no one has responded at all. Also, it mostly seems to happen when I am writing changes to radicale and not as much when I am just getting changes made on other machines. An exception to this is that once in awhile I delete the account locally and recreate it. Even though in this case I am only retrieving data, it still takes multiple refreshes to get all the data as I get multiple black triangle errors too. I don't know if there is anything that can be done on the radicale side to alleviate this problem. BTW, I run radicale on a local linux machine under arch linux on an odroid N2+ SBC. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
By default, in macOS/ios, it refers to the root of the server's domain - "/". That is, if your server is behind a proxy and you pass the url like <?xml version='1.0' encoding='utf-8'?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<href xmlns="DAV:">/caldav</href>
<D:propstat>
<D:prop>
<D:current-user-principal>
<D:href>/caldav/{user}</D:href>
</D:current-user-principal>
</D:prop>
<status xmlns="DAV:">HTTP/1.1 200 OK</status>
</D:propstat>
</D:response>
</D:multistatus>If request does not auth - 401, you must return |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
...or you could simply adjust your webserver to properly respond to the ".well-known/..." URLs which are used by IOS as well. To make it work, I added these two lines in my nginx-config: # ...
server {
listen 443 ssl http2;
location = /.well-known/caldav { return 302 /radicale/; }
location = /.well-known/carddav { return 302 /radicale/; }
# ...
location /radicale/ {
proxy_pass http://127.0.0.1:5232/;
# ...
}
}...Given that radicale is accessible under |
Beta Was this translation helpful? Give feedback.
0 replies
-
Unfortunately it didn't work for me. IOS made a request for the |
Beta Was this translation helpful? Give feedback.
0 replies
-
Hm, In my case I am just using "mycoolservername.local" as the only information together with username and password. Of course, I switched on Basic Auth in nginx and have a proper certificate which I had to import on my IOS device. And it worked without any hassle. the rest of the location-part in nginx looks like the following: # ...
location /radicale/ { # The trailing / is important.
proxy_pass http://127.0.0.1:5232/;
proxy_set_header X-Script-Name /radicale;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Remote-User $remote_user;
proxy_set_header Host $http_host;
proxy_buffering on;
auth_basic "Restricted Content";
auth_basic_user_file /etc/nginx/conf.d/radicale.htpasswd;
} |
Beta Was this translation helpful? Give feedback.
0 replies
-
In my case, I am using an additional authorization plugin and the username does not match the username specified in the url, this may be the case. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Follow-Up: have you been able to solve the problem above? |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
There are HTTP client implementations out which first send a request without username:password and then server respond with |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
So, we can't use iOS/MacOS/iPadOS with Radicale? Nevermind! I got it working in MacOS 10.13's calendar v10.0 by following this #954 |
Beta Was this translation helpful? Give feedback.
3 replies
-
|
The tip in #954 works for establishing connectivity with macOS Calendar.app, but the issue with that app failing authentication and regularly asking for the password to be re-entered remains. The issue does not occur with iOS/iPadOS clients. |
Beta Was this translation helpful? Give feedback.
-
|
Do I understand proper: credentials are supplied in the app, then it's working and after some time for whatever reason the authentication failed, app throws away the password then and asking for a "new" password? If this is the case, one has to investigate on server side (potentially with enabled debug log) why suddenly authentication failed - or app has a misbehavior. |
Beta Was this translation helpful? Give feedback.
-
|
The behavior appears to be that the macOS Calendar app/client tries to log in without credentials anonymously first and fails, and after that resorts to using the saved/configured credentials. And then after some random number of the anonymous failures, the client prompts the user to re-enter the password. Having said that, things seemed to work better after upgrading to macOS 14.7 on Monday and then macOS 15 today. Fingers crossed..... |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Greetings everyone! Yesterday I started playing with radicale to replace an ancient Darwin Calendar Server installation. I got things mostly working as a completely standalone LAN-only instance running on macOS Ventura. I'm using a self-signed root SSL certificate that was successfully imported into all my clients, and creating/syncing calendar events works just fine for the most part. However, I've noticed that the Apple clients (Calendar.app on macOS, iOS, and iPadOS devices) always seem to try to connect as anonymous users first before authenticating using my test "ical" account name. This causes an unceasing string of 401 errors when trying to make any updates, to the point where I am regularly getting prompted by the OS to re-enter my password in the System Settings for the account.
Here's an example of the info-level log files that get generated when I do a refresh using macOS Calendar.app:
My rights file is the vanilla default suggestion from the documentation:
When I connect using Thunderbird, no errors like the above are logged.
Random other info: using htpasswd/md5 authentication to a users file, using direct connections to the server using IP address:5232.
Anyone seen this and/or have hints to offer? Thanks in advance!!!
Beta Was this translation helpful? Give feedback.
All reactions