Fri, 10 Apr 2026 13:36:24 +0000 https://bugs.horde.org/ticket/3696 Add authentication for remote calendars Per my note to the dev list, this patch adds HTTP authentication support for remote calendars. - The "Remote Calendars" prefs page was changed to accept user/password inputs, and to allow editing of an existing remote calendar entry - The "My Calendars" page was updated to add an iCal link to each calendar to provide a convenient way to copy the corresponding URL - The lib/prefs.php code was updated to handle the new preference attributes - The lib/Kronolith.php class was updated to look up the user/password as needed Note that both the user and password are encrypted and wrapped in base64 to prevent inadvertent disclosure via database queries. The encryption key (an MD5 hash of the target URL) is not particularly strong, but it is convenient and it should be sufficient to keep most DBAs honest. Tom Evans Tachometry Mon, 27 Mar 2006 09:13:07 +0000 https://bugs.horde.org/ticket/3696#t18161 I'm wondering if that really works? If I remember correctly, secrets are only guaranteed to work during a session, so you might be unable to decrypt the credentials after logging out. Tue, 28 Mar 2006 12:45:23 +0000 https://bugs.horde.org/ticket/3696#t18191 I have successfully connected with authenticated remote calendars across multiple login/logout cycles and everything seems fine. I also manually cleared the Horde cache and session files on the server just to be sure. Any other conditions I should test? Tue, 28 Mar 2006 16:40:24 +0000 https://bugs.horde.org/ticket/3696#t18309 Yes, try deleting cookies. Tue, 28 Mar 2006 17:41:29 +0000 https://bugs.horde.org/ticket/3696#t18321 OK - I cleared all cookies, dropped the session, log on/off and still have a good remote calendar connection. Thanks for the feedback. Anything else? Tue, 28 Mar 2006 18:27:40 +0000 https://bugs.horde.org/ticket/3696#t18336 No, should be fine then, thanks for testing. Tue, 28 Mar 2006 22:01:36 +0000 https://bugs.horde.org/ticket/3696#t18362 Ah, not quite. This patch doesn't give any more security than storing the credentials in cleartext. You use a known key (the url, stored in clear text in the preferences) to encrypt the credentials. Anybody who has access to the preferences, the people your are trying to protect the credentials against, can easily decrypt them, because they have the key. It's a bit more work, but still easy. Tue, 28 Mar 2006 22:08:16 +0000 https://bugs.horde.org/ticket/3696#t18367 OK - no problem. I wanted to obfuscate the value in the database without hard-wiring any magic cookies in the code. However, I agree it's not particularly secure, and we can make it a bit stronger by separating the key from the encrypted value. As an (imperfect) alternative, I could add a configuration parameter in the Horde setup for a global encryption key, optionally generating a random value for a new Horde installation where no key exists. If this makes sense, I can also declare a new setup configuration tab to define shared encryption parameters (key, key strength, algorithm, etc.). I can then plug these parameters into the Secret class. I will also add some convenience methods for the Base64 string wrapper. I'll put together a fresh patch with these additional changes for your review. I'm also open to other suggestions. Do yo think this same approach would work to protect the IMP fetch mail credentials? Thanks, Tom Tue, 28 Mar 2006 23:10:38 +0000 https://bugs.horde.org/ticket/3696#t18382 Why don't you use the users current password as the key? Granted, this will still break decryption if the user changes his password, but it makes a perfect secret key. I could have sworn we do this already somewhere in the code, but I can't find where. > I'll put together a fresh patch with these additional changes for > your review. I'm also open to other suggestions. Do yo think this > same approach would work to protect the IMP fetch mail credentials? Sure. Tue, 28 Mar 2006 23:17:46 +0000 https://bugs.horde.org/ticket/3696#t18383 Hi there. I am new to horde an dkronolith and still testing. With kronolith, I have a calendar with users, groups and rights. I have edited them to have only rights to view or show. They still have the right to write new events , edit and kill'em. They should not have. Is this the same problem you are talking about ? I want to be admin with editing events. The users only may see the events. How to do ? Do I have to change the php and delete the lines for showing the buttons ? Any help would be great. Is there any german forum ? Yours sincerely, Jörg Heusler Thu, 30 Mar 2006 05:43:18 +0000 https://bugs.horde.org/ticket/3696#t18417 > Is this the same problem you are talking about ? No, and this is *not* a support forum. Thu, 30 Mar 2006 22:04:41 +0000 https://bugs.horde.org/ticket/3696#t18465 I'm OK with using the user's password as a key. However, I couldn't tell at first glance whether it is available in plain text after it has been stored in the session. If you know where I should look, let me know. Otherwise I'll dig a little deeper on my own and get back to you. So next question - should I try to integrate with the password change application to re-encrypt a value when I have both the new and old passwords? It's still not bullet-proof, because passwords can be changed outside of Horde. Perhaps it's not worth the extra effort...thoughts? Fri, 31 Mar 2006 07:09:29 +0000 https://bugs.horde.org/ticket/3696#t18488 Never mind on my first question - figured it out (yikes!). Still wondering if a password change hook makes sense. I would need to find some way to register all such encrypted values to keep track of what needs to be updated with the new password-based encryption key. Fri, 31 Mar 2006 07:47:08 +0000 https://bugs.horde.org/ticket/3696#t18489 Updated patch file attached, merged with current HEAD. Should be clean (I hope). Thanks for all the feedback. Let me know if you think I should pursue the passwd application integration concept. I will be looking at IMP next to secure the credentials for remote email systems. Fri, 31 Mar 2006 08:03:49 +0000 https://bugs.horde.org/ticket/3696#t18490 The calendar management looks good, though I don't know what the md5() and base64 are for. And you should check whether there are credentials provided in the first place, both when saving and when using them. Regarding the password changes, hooking into Passwd would be slick but I can't imagine a nice and clean solution currently. We don't have a way to define listeners in the registry atm, we could loop through all APIs and check for certain methods though. Like we do for clearUserData or admin_list already. Fri, 31 Mar 2006 08:35:42 +0000 https://bugs.horde.org/ticket/3696#t18497 I am using base64 to convert the binary-ish output from the Secret class into something more string-friendly. Without it, the prefs page fails to render. Turns out the md5 hash was a holdover from an earlier interation - I've removed it. I added a check for a valid password credential. Now if the password is unavailable, the remote calendar credentials will be stored in plain text in the preferences table. Fri, 31 Mar 2006 09:43:08 +0000 https://bugs.horde.org/ticket/3696#t18502 Tweaked and committed, thanks. Mon, 07 Aug 2006 16:30:35 +0000 https://bugs.horde.org/ticket/3696#t22756