Re: [PHPiCalendar-DEV] Emailed Events, Editing Events, and Superglobals

[Wesley M. <we...@we...>]

Hi People,

Sorry I haven't been active on the project much lately. Been busy  
with other things.

Unfortunately, authentication based solely upon the sender's email  
address is incredibly insecure, and easily spoofed. So I'm afraid  
that cannot be used. It's easy enough to identify the email address  
being used to update a calendar by monitoring the inbound email  
traffic to that server.

Since it seems the primary motivation of this system is to provide  
the addition of .ics events to an existing calendar, I believe a good  
solution would be to allow upload of .ics files via the admin page to  
add the contents of that .ics file to an existing calendar. This  
still allows remote additions, while also remaining within the  
authentication framework currently used to add/delete calendars.  
There's no need to make it full-featured if we only support insertion  
of events via the admin interface. However, there is the issue of  
merging identical events, as I believe you receive .ics files back  
when someone accepts your meeting invitation, for example. So you  
would have to identify the matching event (there is a unique event  
ID, I think?) and update the fields appropriately in the master .ics  
file.

Seems fair enough that if you are the administrator, then adding a  
feature to delete and possibly even edit events (since the previous  
paragraph added the ability to update existing events) could be done  
because PHP iCalendar knows you are the administrator. I see mention  
of deleting events in one of the previous emails.

Also sorry I didn't provide any more input on the topic of sanitizing  
user input earlier. Nicolas, I think you said you will work on this?  
If I read the emails right. An easy way to do this would be to parse  
the superglobals such as _GET and _POST into a registry object,  
perform sanity checks on the values as you register them, and then  
completely clean-out the contents of those superglobals so that  
attempts to access them elsewhere will just fail. Then provide  
methods to access the registry contents like as Hashtable.

The sanity checks on the input could be specified as regular  
expressions in a central file, which happens to be the ONLY file the  
superglobal registry file pulls in. Any edits to the registry file  
later on would be easy to flag as suspicious, and same as any changes  
to the regular expressions definition file. If you allow the sanity  
checks to be defined in random places, then it becomes too hard to  
keep track.

Later,
--
Wesley Miaw
we...@we...