[Tickets #1599] NEW: Free/Busy URL - fb.php broken

bugs at bugs.horde.org bugs at bugs.horde.org
Mon Mar 21 09:59:05 PST 2005


DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/?id=1599
-----------------------------------------------------------------------
 Ticket             | 1599
 Created By         | graeme at graemef.net
 Summary            | Free/Busy URL - fb.php broken
 Queue              | Kronolith
 Version            | HEAD
 State              | Unconfirmed
 Priority           | 2. Medium
 Type               | Bug
 Owners             | 
+New Attachment     | fb.php.patch
-----------------------------------------------------------------------


graeme at graemef.net (2005-03-21 09:59) wrote:

As per many mailing list posts, among them one from me on March 21st 2005,
use of the freebusyurl in kronolith 2.1-cvs (HEAD branch) is broken when
attempting to:

1. View Free/busy URL directly from a browser.
2. Check other users' availability when adding them to a new (or existing)
event.

As far as I can tell, kronlolith/fb.php is broken as it tries to use the
PATH_INFO environment variable to determine the calendar name it is using:

// Determine the username to show free/busy time for.
if (!empty($_SERVER['PATH_INFO'])) {
    $cal = basename($_SERVER['PATH_INFO']);
} else {
    $cal = Util::getFormData('c');
    if (is_array($cal)) {
        $cal = implode('|', $cal);
    }
}

In this logic, if $_SERVER['PATH_INFO'] is set (regardless of value) then
the query option "c=username" passed in the URI is ignored.
In my case, this then produces a calendar name of "fb.php" which, unless I
have a *very* odd set of usernames :) is not going to be valid. I can't see
why this environment variable is used at all; maybe someone could enlighten
me on that one...

In any case, I made a change to fb.php (patch attached) which ignores it.
The patch needs better error condition handling as it's possible to pass an
invalid username which will then return a bogus empty response, but it's
fixed it for me.

Is this valid, or just rubbish?




More information about the bugs mailing list