Re: [PHPiCalendar-DEV] admin control panel patch available - please help by testing

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

Re 1 & 2 - sounds good - I'll start with this.
Re 3 - this can be disabled in the with the config.ini.php variable, but I can remove it altogether if there's something you really dislike about the way it's implemented. The only reservation I have is the user who, later on, really want this type of functionality.
Re 4 - It shouldn't be that much of a problem for them to be in config.inc.php. Admins who are concerned could just use http basic or digest and disable the config.inc.php username/pass. The point of the internal authentication was so be a simple & open, but not 100% secure method of authentication. If you require http basic, ftp, webdav, it's no longer general. For example, I've used a number of servers that do not have either ftp or webdav, but rely on ssh (which is encrypted). I think this is a good feature to have, and believe that as long as we highlight the caveats in the docs, people would benefit from it staying.
Re 5 - The cookie is used to store state information, meaning that once they login, we need to know that. If we don't use a cookie, we have to carry the password from page to page using form parameters. This isn't more secure, and just a sloppier way to handle things.
Re 6 - I think the unlink just needs to be converted to a function call which will handle more cases. unlink() is a very standard function, but there are many different system configs which need to be taken into account. I'll look into this. Regarding your system, I suspect that your webserver is running as a user which doesn't have rights to delete files created by the user you are creating files with. afaik, this is not the normal configuration.
Re 7 - I agree. But, there always that line you walk between reducing your translation needs, and having a user friendly app. Being that this is an admin portion, I don't think it would be unacceptable to have it in english-only until translations start rolling in from users.
Comments?
thanks,
mike
 Chad <ch...@ch...> wrote:Some more thoughts:

1) How about being able to upload more than 1 calendar at a time, let's 
try 5.
2) Multiple delete. Let's list all the calendars with unchecked 
checkboxs. Whichever get highlighted by the admin get deleted.
3) Remove the javascript confirm. If Im the admin, I login, select a 
calendar, then click delete, I dont need a 4th step to confirm, its 
just a waste of time.
4) Username and passwords will not be stored in the config. I don't 
want them set anywhere where someone else could get access. Anyone 
using PHP iCalendar has some sort of ftp or webdav username and 
password already on the system. Use them.
5) Cookies. Not sure what to do here. Personally I don't think we 
should set a cookie, since its an added security risk. I don't think 
people will be loging in daily to admin their calendars, if they are 
they need a better solution than the admin page.
6) Unlink. Seems like another possible security problem. If ftp is more 
supported, than why not use it. Unlink requires no username and 
password. Would like to hear from other developers on this one. That 
and it doesn't work on my development machine (Mac OS X).
6) Translations. Seems like we have a good bit of new lines, perhaps we 
can look at this and lighten them up a bit.

Please don't get discouraged by this list. Your contribution is greatly 
appreciated and will help make PHP iCalendar better. I just need to 
think about things overall -- Ease of use, Setup, Security, Looks, 
Functionality -- and work with all the developers (I know they are here 
somewhere) to find a common ground.

Thanks.
C

On Saturday, March 29, 2003, at 05:31 PM, Mike Traum wrote:

> Re: unlink error, I don't get that error on my server - maybe a server 
> config issue? This may be a better way to delete (from php.net):
> > function suppr($file) {
> $delete = @unlink($file);
> if (@file_exists($file)) {
> $filesys = eregi_replace("/","\\",$file);
> $delete = @system("del $filesys");
> if (@file_exists($file)) {
> $delete = @chmod ($file, 0775);
> $delete = @unlink($file);
> $delete = @system("del $filesys");}}}
> ?>
>
> Re: javascript confirm, it can de disabled by setting $confirm_changes 
> to 'no' in config.inc.php, so I don't know why it needs be removed.
>
> Re: coding standards, I thought I was. Which part didn't meet your 
> standards?
>
> mike
>
>  Chad wrote:
>
> Well, it need a bit of a polish, which I can take care of over the next
> few days. I also got an error trying to delete a calendar:
>
> Warning : unlink() failed (Permission denied) in
> /Users/clittle/Sites/phpicalendar/admin.php on line 180.
>
> The coding standards should also match ours, so developers can expect
> consistant structure. The javascript confim can also go away. I've
> committed it for now but we'll have to work it over.
>
> -C
>
> On Friday, March 28, 2003, at 12:55 PM, Mike Traum wrote:
>
> > Thanks for all of the good suggestions regarding the admin control
> > panel. The patch is available on the sourceforge patch page. Please
> > help by testing this so we can get it up to release standards asap.
> >
> > thanks,
> > mike
> >
> >
> >
>
> >
> > Do you Yahoo!?
> > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your 
> desktop!
>
>
> -------------------------------------------------------
> 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
>
>
>

>
> Do you Yahoo!?
> Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!

---------------------------------
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!