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

[Greg W. <gr...@gr...>]

> Re 3 - this can be disabled in the with the config.ini.php variable,=20=

> but I can remove it altogether if there's something you really dislike=20=

> about the way it's implemented. The only reservation I have is the=20
> user who, later on, really want this type of functionality.

I agree with the attempt to move away from Javascript, and doubt that=20
this functionality would ever be that necessary, but I guess it's not a=20=

big deal if we ship with the config variable defaulting to no.

> Re=A04 - It shouldn't be that much of a problem for them to be in=20
> config.inc.php. Admins who are concerned could just use=A0http basic =
or=20
> digest and disable the config.inc.php username/pass. The point of the=20=

> internal authentication was so be a simple & open, but not 100% secure=20=

> method of authentication. If you require http basic, ftp, webdav, it's=20=

> no longer general. For example, I've used a number of servers that do=20=

> not have either ftp or webdav, but rely on ssh (which is encrypted). I=20=

> think this is a good feature to have, and believe that as long as we=20=

> highlight the caveats in the docs, people would benefit from it=20
> staying.

Why would someone who relies on ssh want to use such an insecure form=20
of authentication?  If you've got a server that doesn't allow any=20
webdav or ftp access, I doubt they're going to want to allow this sort=20=

of thing.  I guess it's possible, but is it a reasonable enough=20
scenario to cater to it?  Again, it doesn't seem to be a big deal to=20
have the option, except in that the config.ini.php file just gets=20
longer and more trouble to configure (and, there's no point to having=20
features that won't be used and which take up space).

That's all I got.

Greg
--
http://www.gregwestin.com
Contact info: http://www.gregwestin.com/contact.php