Adding CAPTCHA to Radicale and what would need to change #1402
Replies: 3 comments
-
|
Thank you for your analysis, never digged that deep into the web interface so far.
Agreed, would be a requrement for having administrative "API" for e.g. setting specific passwords (or tokenized URLs) for application/devices.
Looks like without any caching or session support also already existing PRs for other authentication backends would potentially result on issues in higher load case...
There is TLS support already existing I've thought (never tested personally as offloading this to Apache in my setup) |
Beta Was this translation helpful? Give feedback.
-
Ah yes you're right. My bad. I have been using NGINX to proxy Radicale for so long I forgot it builtin SSL/TLS! Well, on the bright side that is one less task to do. |
Beta Was this translation helpful? Give feedback.
-
|
Nowadays a common trend is to deploy services behind a (reverse) auth proxy. So I vote for supporting
|
Beta Was this translation helpful? Give feedback.
-
RELATED: #1257, #1329
Hi All,
tldr;
I took a look at how we can implement CAPTCHA into Radicale and there is no solution that is minimally intrusive. To make CAPTCHA work for Radicale I have to make significant changes to the builtin web server and the way that responses are rendered. This is a sizeable undertaking and needs community feedback and involvement to develop and implement.
Why isn't it straightforward?
The Radicale Web UI
The Radicale Web UI does not have any special or additional access to Radicale. It is just a DAV client written in Javascript & HTML. The authentication of logins from the web UI is handled in the exact same way as any other authentication from any other client (such as DAVx5). As far as Radicale is concerned, it doesn't know or particularly care if you're logging in with the web UI. No additional authentication is performed by the Radicale WSGI for the web login.
The Radicale WSGI server
The Radicale WSGI server is entirely stateless. There are no sessions to keep track of authenticated users. Each request is authenticated every time. This means that implementing a CAPTCHA for the web UI without making changes in the server will require every request to be authenticated. Further, the WSGI can only serve static content for the web UI, it cannot generate dynamic content (which would be necessary).
Where to from here?
We need to consider improving the Radicale WSGI server in the following ways:
I am seeking community feedback on how much support and desirability there is for these improvements, and if there is support, a plan to develop and merge the needed improvements (potentially for a v3.5+ release?), as well as keep track of what other factors need to be considered (alternative auth methods, memory, performance, etc).
I welcome all feedback, comments, and discussion!
Beta Was this translation helpful? Give feedback.
All reactions