Read the changelog on GitHub.
+Read the changelog on GitHub.
You want to try Radicale but only have 5 minutes free in your calendar? Let's go right now and play a bit with Radicale!
-When everything works, you can get a client and start creating calendars and address books. The server only binds to localhost (is not reachable over the network) and you can log in with any user name and password. If Radicale fits your needs, it may be time for some basic configuration.
+When everything works, you can get a client and start creating calendars and address books. The server only binds to localhost (is not reachable over the network) and you can log in with any username and password. If Radicale fits your needs, it may be time for some basic configuration.
Follow one of the chapters below depending on your operating system.
All configuration options are described in detail in the Configuration section.
In its default configuration Radicale doesn't check user names or passwords. If the server is reachable over a network, you should change this.
-First a users file with all user names and passwords must be created. It can be stored in the same directory as the configuration file.
In its default configuration Radicale doesn't check usernames or passwords. If the server is reachable over a network, you should change this.
+First a users file with all usernames and passwords must be created. It can be stored in the same directory as the configuration file.
The users file can be created and managed with htpasswd:
Create the users file by hand with lines containing the user name and password separated by :. Example:
Create the users file by hand with lines containing the username and password separated by :. Example:
user1:password1
user2:password2Authentication can be enabled with the following configuration:
@@ -474,7 +474,7 @@ user2:password2Be reminded that Radicale's default configuration enforces limits on the maximum number of parallel connections, the maximum file size and the rate of incorrect authentication attempts. Connections are terminated after a timeout.
Set the configuration option type in the auth section to http_x_remote_user. Radicale uses the user name provided in the X-Remote-User HTTP header and disables HTTP authentication.
Set the configuration option type in the auth section to http_x_remote_user. Radicale uses the username provided in the X-Remote-User HTTP header and disables HTTP authentication.
Example nginx configuration:
location /radicale/ {
proxy_pass http://localhost:5232/;
@@ -557,7 +557,7 @@ user2:password2Set the configuration option type in the auth section to remote_user. Radicale uses the user name provided by the WSGI server and disables authentication over HTTP.
Set the configuration option type in the auth section to remote_user. Radicale uses the username provided by the WSGI server and disables authentication over HTTP.
Path to the CA certificate for validating client certificates. This can be used to secure TCP traffic between Radicale and a reverse proxy. If you want to authenticate users with client-side certificates, you also have to write an authentication plugin that extracts the user name from the certificate.
+Path to the CA certificate for validating client certificates. This can be used to secure TCP traffic between Radicale and a reverse proxy. If you want to authenticate users with client-side certificates, you also have to write an authentication plugin that extracts the username from the certificate.
Default:
Available backends:
none : Just allows all usernames and passwords.
htpasswd : Use an Apache htpasswd file to store usernames and passwords.
remote_user : Takes the user name from the REMOTE_USER environment variable and disables HTTP authentication. This can be used to provide the user name from a WSGI server.
http_x_remote_user : Takes the user name from the X-Remote-User HTTP header and disables HTTP authentication. This can be used to provide the user name from a reverse proxy.
remote_user : Takes the username from the REMOTE_USER environment variable and disables HTTP authentication. This can be used to provide the username from a WSGI server.
http_x_remote_user : Takes the username from the X-Remote-User HTTP header and disables HTTP authentication. This can be used to provide the username from a reverse proxy.
Default: none
Many clients do not support the creation of new calendars and address books. You can use Radicale's web interface (e.g. http://localhost:5232) to create and manage address books and calendars.
-In some clients you can just enter the URL of the Radicale server (e.g. http://localhost:5232) and your user name. In others, you have to enter the URL of the collection directly (e.g. http://localhost:5232/user/calendar).
In some clients you can just enter the URL of the Radicale server (e.g. http://localhost:5232) and your username. In others, you have to enter the URL of the collection directly (e.g. http://localhost:5232/user/calendar).
Enter the URL of the Radicale server (e.g. http://localhost:5232) and your user name. DAVx⁵ will show all existing calendars and address books and you can create new.
Enter the URL of the Radicale server (e.g. http://localhost:5232) and your username. DAVx⁵ will show all existing calendars and address books and you can create new.
GNOME Calendar and Contacts do not support adding WebDAV calendars and address books directly, but you can add them in Evolution.
-In Evolution add a new calendar and address book respectively with WebDAV. Enter the URL of the Radicale server (e.g. http://localhost:5232) and your user name. Clicking on the search button will list the existing calendars and address books.
In Evolution add a new calendar and address book respectively with WebDAV. Enter the URL of the Radicale server (e.g. http://localhost:5232) and your username. Clicking on the search button will list the existing calendars and address books.
The titles of the sections are ignored (but must be unique). The keys user and collection contain regular expressions, that are matched against the user name and the path of the collection. Permissions from the first matching section are used. If no section matches, access gets denied.
The user name is empty for anonymous users. Therefore, the regex .+ only matches authenticated users and .* matches everyone (including anonymous users).
The titles of the sections are ignored (but must be unique). The keys user and collection contain regular expressions, that are matched against the username and the path of the collection. Permissions from the first matching section are used. If no section matches, access gets denied.
The username is empty for anonymous users. Therefore, the regex .+ only matches authenticated users and .* matches everyone (including anonymous users).
The path of the collection is separated by / and has no leading or trailing /. Therefore, the path of the root collection is empty.
In the collection regex you can use {user} and get groups from the user regex with {0}, {1}, etc.
In consequence of the parameter substitution you have to write {{ and }} if you want to use regular curly braces in the user and collection regexes.