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

[Jim Hu <ji...@ta...>]

Re: Editing events via email
This sounds like a mod that would not be part of the main  
phpicalendar development.  I worry that it would be hard to make this  
compatible with regular ical use - there are issues related to file  
locking etc. that may be problematic (and I'm also hoping CalDAV will  
serve the desired purpose).

I would like to see svens make it available, and with appropriate  
disclaimers I think it (and other mods like the editing system  
someone else has on the bbs) could be hosted on the sourceforge files/ 
packages page.  How does that sound?  If I was going to put time into  
making an editable system, I agree with Greg that I'd just make a web  
interface.  I'd set up a mysql backend for the persistence layer and  
just have events and todos as record types.  I bet it wouldn't be too  
hard to have the database output populate the master array...in fact,  
I thought someone had a project to do that already with phpicalendar  
1.x.

Re: Superglobals

I hadn't been thinking of doing it OO, but that's probably a good  
idea.  If I understand Wesley, we'd create a class globals (or some  
similar name).  The object constructor method would do something like

foreach ($_REQUEST as $key=>$val){
	#code to handle the variable namespace from $_GET or $_POST or  
$_COOKIE or from config.inc.php
	...probably a big switch statement
	unset $_GET[$key];
	unset $_POST[$key];
	unset $_REQUEST[$key];
}

The globals object would then have methods to return the sanitized  
values.  Then init.inc.php would be something like
$globals = new globals
and $globals would be used as a global object variable as needed.   
Instances of $getdate, for example, would be replaced by $globals- 
 >getdate

Is that about right? I like this, since one can just declare $globals  
as global instead of enumerating lots of variable names.

In the non-OO approach I've used elsewhere, I just move all the  
values from $_REQUEST[$key] into a new array $clean[$key] after doing  
value validation via a large switch statement.  In the codebase, we'd  
just do a global search and replace for $_GET, $_POST, and $_REQUEST  
to $clean.

Jim

On Apr 28, 2006, at 6:10 PM, Wesley Miaw wrote:

> 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...
>
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel