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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi Jim,

I agree with your decision on the event editing.

As for superglobals, I didn't necessarily mean to treat it as a  
global object. The array approach works just as well and might be  
easier for everyone. But the OO approach might mean more control over  
security. I'm not really sure. You could just use $globals->get("")  
so that you don't need to modify the globals class that much whenever  
a new value needs to be exposed. Since there's no $globals->set(),  
which you can't prevent when using an array, you're safe.

The advantage of defining regular expressions to match against the  
global values in a separate file is that you can make your switch  
statement go away and instead do something like (this is rough, and I  
haven't got the PHP syntax right):

foreach ($key in $_REQUEST) {
     $regexp = $global_regexps[$key];
     if (!defined $regexp) next;
     preg_match($_REQUEST[$key], $regexp, $matches);
     $global_store[$key] = $matches[1];
     unset $_POST[$key];
     unset $_GET[$key];
     unset $_REQUEST[$key];
}

Later,
Wes

On Apr 28, 2006, at 5:43 PM, Jim Hu wrote:

> 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
>
>
>
> -------------------------------------------------------
> 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

--
Wesley Miaw
we...@we...