phpicalendar-devel

Re: [PHPiCalendar-DEV] adding interface to upload new calendars - design discussion

[blaine <la...@us...>]

On Wednesday, Mar 26, 2003, at 14:44 America/Vancouver, Mike Traum 
wrote:

> there will be only one user/password, which is configured in 
> config.inc.php. afaik, this is a slight security problem, in that if 
> something goes haywire with the server, it's possible that the text of 
> config.inc.php could be obtained. That being said, it's the simpliest 
> and I think sufficiently secure.
>
> Comments?

I think an admin panel is a great idea; however, since most 
phpicalendar installations will be using webdav, and therefore already 
have some sort of Apache Basic (or digest) authentication enabled, it 
would make more sense to use that (i.e., use the $REMOTE_USER variable) 
--- perhaps a list of users who are allowed access to the admin panel.

Of course, there could always be an override password --- a username 
isn't necessary. But in any case, it would be nice to be able to turn 
this off, since it's always better to store passwords apart from the 
web server's gaze than close to it ;-)

b.

Re: [PHPiCalendar-DEV] adding interface to upload new calendars - design discussion

[blaine <la...@us...>]

I've actually been thinking about some related ideas for a while now...=20=

I'll just get them out there to [hopefully] provoke some discussion /=20
ideas.

I have two major issues with PHPiCalendar; one of them is actually an=20
issue with Apple's implementation of iCal (or perhaps iSync...)

1) PHP iCalendar doesn't scale well. One calendar works great, 5=20
calendars works ok, and much more than that and it's just unmanageable.=20=

What needs to happen (imho) is for PHPiCalendar to recognise a=20
directory hierarchy filled with iCals as a "calendar store", which=20
could then be navigated.

So, for example, take a directory structure that looks like this:

/webroot (phpical base)
        |
       +--- calendars
                        |
                       +--- film screenings
                        |                  |
                        |                  +----- theatre 1
                        |                  +----- theatre 2
                        |                  +----- ...
                        |                  +----- theatre n
                        |
                       +--- concerts
                       +--- public lectures

We should then be able to request calendars like so:

     http://calendar.mycity.net/concerts/
     http://calendar.mycity.net/public_lectures/
     http://calendar.mycity.net/film_screenings/theatre_2/

This can / should be done with either mod_rewrite or just setting a=20
phpicalendar page to be a handler for a given domain. (eg: SetHandler /=20=

php-script)

Obviously there are some problems with this;

	i) it's not facetted (i.e., if I want to search for theatres by =
type=20
or by city, instead of by name, we run into problems. This can be fixed=20=

either with a handler at the application level (url mapping, through a=20=

config file or database), or at the filesystem level with symlinks).

	ii) Multiple calendar support needs to be very carefully thought =
out;=20
such a system could make multiple calendar support extremely powerful,=20=

though --- each user could arrive on-site, and see a customised=20
calendar, or even subscribe to a customised calendar.

	iii) descriptions of calendars become useful when you have lots =
of=20
them. Perhaps PHPiCalendar could have an optional SQL backend that=20
stores meta-data that isn't in iCal (or doesn't belong there).

	iv) Permissions are a bit sketchy if PHP iCalendar manages 'em.=20=

However, webdav (or ftp, as chad hinted at), already have permissions,=20=

and so they could be used (perhaps as a secondary to $REMOTE_USER).

2) There's no way to have collaborative calendars; you can't publish a=20=

calendar, and then have others directly contribute to it. The only way=20=

I've found around this is to write up a little script that generates=20
iCal files based on input from an online form (which is overly simple=20
and limiting), and having the script mail them to me, so that I can=20
move them to my published calendar. This puts the total load of=20
maintaining a calendar on exactly one person.

Obviously, it would be ideal if Apple would just freakin' support=20
publishing AND subscribing to a single calendar, directly in iCal. They=20=

could even add logic to force a refresh of the calendar before editing=20=

it. But if there were a way to "simulate" this with PHP iCalendar, then=20=

all would be good --- for example, if there were a way to email PHP=20
iCalendar with an event that could be added to the queue, then iCal's=20
"invite" system would automatically enable collaborative calendaring.=20
This sort of thought would require a lot more thought, but could be=20
useful.

Anyways, a lot of this is a long ways off, and perhaps even wishful=20
thinking; if you've made it this far, thanks. :-) Sorry for the rant.

please let me know if you have any ideas; now that the parser is=20
more-or-less done, as I see it steps should be taken to improve=20
scalability, etc. What are others' priorities?

b.

On Wednesday, Mar 26, 2003, at 14:44 America/Vancouver, Mike Traum=20
wrote:

> Hi,
> I'm working on an interface=A0for calendar administration. Here's what =
I=20
> have as a basic design:
> Admin Options
> - Update a calendar (replace a calendar file with a new one)
> - Add a new calendar
> - Delete a calendar
> ...=

Re: [PHPiCalendar-DEV] adding interface to upload new calendars - design discussion

[Chad <ch...@ch...>]

I would say most are not using webdav actually, and pretty much all can 
use ftp.

-C

On Wednesday, March 26, 2003, at 04:49  PM, blaine wrote:

> On Wednesday, Mar 26, 2003, at 14:44 America/Vancouver, Mike Traum 
> wrote:
>
>> there will be only one user/password, which is configured in 
>> config.inc.php. afaik, this is a slight security problem, in that if 
>> something goes haywire with the server, it's possible that the text 
>> of config.inc.php could be obtained. That being said, it's the 
>> simpliest and I think sufficiently secure.
>>
>> Comments?
>
> I think an admin panel is a great idea; however, since most 
> phpicalendar installations will be using webdav, and therefore already 
> have some sort of Apache Basic (or digest) authentication enabled, it 
> would make more sense to use that (i.e., use the $REMOTE_USER 
> variable) --- perhaps a list of users who are allowed access to the 
> admin panel.
>
> Of course, there could always be an override password --- a username 
> isn't necessary. But in any case, it would be nice to be able to turn 
> this off, since it's always better to store passwords apart from the 
> web server's gaze than close to it ;-)
>
> b.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel