|
From: Jim Hu <ji...@ta...> - 2006-04-29 00:43:20
|
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
|