-
This bug can only be observed and reproduced as follows: Squirrelmail setup with login_auth. Version of ./functions/global.php => 1.4.16. Browser that allows you to see all the values of cookie, such as the "view cookies" add-on for Firefox. Browser must be fully closed down between each attempt to view problem.
Our mail server has http_auth via ldap at the top of the web root, so we can log...
2009-04-26 11:21:16 UTC in SquirrelMail
-
I seem to remember that there is an option in Apache where it is able to try different combinations of upper-case & lower-case to map a url to a file, as Unix is case sensitive regarding filenames and Windows is not. I wonder if something similar is happening, where it tries different case in the username to let someone log in, but the name the person originally entered is still wrong.
2008-09-18 09:36:14 UTC in WebCalendar
-
I have recreated this error as well. The problem would seem to be that the entry in Sunbird (or Lightning) is simply removed from the iCal publish. So how does WebCalendar know to remove this entry. I think the heart of the matter lies in the webcal_import_cal data. As far as I can tell, an entry is not created in here until the calendar is exported to iCal. So that distinguishes a new entry in...
2008-08-08 19:58:33 UTC in WebCalendar
-
I think the fix below is the wrong solution. UID's are supposed to be case sensitive, so converting them to lower case may break a UID that is supposed to have upper case characters. However I have a setup where the user has had to authenticate via Apache first (using auth_ldap), so I know that their login is correct so I cannot even start to recreate this error.
The first thing I would check...
2008-08-08 18:43:32 UTC in WebCalendar
-
I had something similar. It turned out to be to do with the entry in ./includes/user-ldap.php that maps the ldap attributes. We use SAMBA with ldap authentication, so this might not work for you:
$ldap_user_attr = array (
// LDAP attribute //WebCalendar variable
'uid', //login
'sn', //lastname
'givenname', //firstname
'displayname'...
2008-08-08 17:42:36 UTC in WebCalendar
-
I think I have just fixed a similar problem (2041908). I have attached my proposed bug fix to the report for ./includes/xcal.php, for WebCalendar-1.2.b1
Might be worth trying to see if it fixes your problem.
Regards,
Marco.
2008-08-08 17:34:31 UTC in WebCalendar
-
I think I have worked out a bug fix for this problem. in ./includes/xcal.php you need to change the line in the generate_uid function that says:
$uid = str_replace ( 'http://', ' ', $uid );
with
$uid = str_ireplace ( 'http://', ' ', $uid );
$uid = str_ireplace ( 'https://', ' ', $uid );
If you do this with an existing calendar you will get another load of duplicates after it...
2008-08-08 17:23:03 UTC in WebCalendar
-
I think I have tracked the issue down to the use of the SERVER_URL variable. In ./install/index.php there is a chunk of code regarding this. In it, it assumes that the page is running http, and doesn't check if it is running https. In generate_url it tries to strip out this part of the URL, but I am not sure this works. In the system settings page it correctly uses the https:// part of the url...
2008-08-07 20:34:08 UTC in WebCalendar
-
When you add an entry in the Web Interface, it exports fine to the iCal client, and the UID of the entry has a HTTPS:- bit at the front of it eg:
UID:HTTPS:-AA000019-UK-FABIT-NET-WEBCALENDAR-MVANBEEK-0000000019
When the entry is edited in the iCal client (eg Sunbird) and the calendar is saved back, a new entry is created. It looks like the "HTTPS:" bit of the UID is getting stripped out by...
2008-08-07 17:00:12 UTC in WebCalendar
-
marcovanbeek committed patchset 2 of module ssis-v2 to the Single Source Information Server CVS repository, changing 139 files.
2005-01-12 17:43:34 UTC in Single Source Information Server
