Menu
▾
▴
phpicalendar-devel
|
From: Nicolas C. <nic...@gm...> - 2005-11-29 09:35:20
|
Hi, I'm thinking about using an other way to customize server/admin-side of the calendar. For now, the only way to set this seems to be editing the 'config.inc.php' = file. Wouldn't it be more pleasant for everone to do it throught the admin page ? This involves : * a non-scriptable config file. * Allowing admin.php access in the 'release' configuration. In my opnion, there are 2 ways to do that : * Creating our own plain-text format (.icp) and the fitting parser. * using XML or .plist format. I doesn't mind. What's youre opinion about this improvement ? Which file format would you prefer for the config file ? Nicolas. |
|
From: Marook K. <ma...@cr...> - 2005-11-29 09:49:16
|
Hi All,
Why not write a PHP constant definition file insted?
Then you only need to Write the file, not parse it back, as it would =20
be simple
define ('theSettingName', 'theValue');
lines. Would that not be easier, or?
Marook Zuug Kenja
[ MIB ]
On 29/11/2005, at 10:35, Nicolas Contamin wrote:
> Hi,
>
> I'm thinking about using an other way to customize server/admin-side
> of the calendar.
>
> For now, the only way to set this seems to be editing the =20
> 'config.inc.php' file.
> Wouldn't it be more pleasant for everone to do it throught the =20
> admin page ?
>
> This involves :
> * a non-scriptable config file.
> * Allowing admin.php access in the 'release' configuration.
>
> In my opnion, there are 2 ways to do that :
> * Creating our own plain-text format (.icp) and the fitting parser.
> * using XML or .plist format.
>
> I doesn't mind.
>
> What's youre opinion about this improvement ?
> Which file format would you prefer for the config file ?
>
>
> Nicolas.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through =20
> log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD =20
> SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
|
|
From: Nicolas C. <nic...@gm...> - 2005-11-29 10:12:36
|
On 11/29/05, Marook Kenja <ma...@cr...> wrote:
> Hi All,
>
> Why not write a PHP constant definition file insted?
>
> Then you only need to Write the file, not parse it back, as it would
> be simple
>
> define ('theSettingName', 'theValue');
> lines. Would that not be easier, or?
I hardly find the interest of a static page in a script format.
When I'll click on the 'save' button, I'll have to rewrite a php file
? Sound strange to me.
Would mind to explain a little bit more ?
Parsing is not a real charge for the server according to the current proces=
s.
Nicolas.
|
|
From: Marook K. <ma...@cr...> - 2005-11-29 11:10:43
|
Hi Nicolas,
Well, it was just a suggestion for an easy solution, so you didn't =20
have to include XML parsing functions, or write your own parser - or =20
at least a very simple write function.
As the 'parser' would be a simple 'include "path/to/file.inc.php";'
and the write could simply run through the defined variables, maybe =20
in an array, it should be Very simple.
But if you wanna play around with parsing & writing XML files (or =20
plain text), then fine with me - it's just raising the implementation =20=
level... ;-)
Best,
Jakob Peterh=E4nsel
'I don't have to try to be a sex bomb, I am one!'
- Kylie Minogue
Email: ja...@hj...
AIM: Marook
Phone: +45 22684961
On 29/11/2005, at 11:12, Nicolas Contamin wrote:
> On 11/29/05, Marook Kenja <ma...@cr...> wrote:
>> Hi All,
>>
>> Why not write a PHP constant definition file insted?
>>
>> Then you only need to Write the file, not parse it back, as it would
>> be simple
>>
>> define ('theSettingName', 'theValue');
>> lines. Would that not be easier, or?
>
> I hardly find the interest of a static page in a script format.
> When I'll click on the 'save' button, I'll have to rewrite a php file
> ? Sound strange to me.
>
> Would mind to explain a little bit more ?
> Parsing is not a real charge for the server according to the =20
> current process.
>
>
> Nicolas.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through =20
> log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD =20
> SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
|
|
From: Wesley M. <we...@we...> - 2005-11-30 02:42:20
|
The advantage of having the variables only defined in config.inc.php =20
is security. I personally would not want to expose certain things on =20
the admin page. And I don't think the current situation is too =20
difficult for regular admins to grasp. Right now, config.inc.php can =20
be read-only and it can hide things like the blacklisted calendars or =20=
user accounts. We're opening up a whole can of worms if we decide to =20
make this something that can be modified from a web page.
Certainly, the idea is nice. But I think things are less complicated =20
and more secure the current way, and there is very little advantage =20
to putting together a web-based admin page. config.inc.php is too =20
straight-forward and simple as it stands for me to believe it can =20
really benefit from a better UI.
Anyway, that's my 2 cents.
On Nov 29, 2005, at 3:10 AM, Marook Kenja wrote:
> Hi Nicolas,
>
> Well, it was just a suggestion for an easy solution, so you didn't =20
> have to include XML parsing functions, or write your own parser - =20
> or at least a very simple write function.
>
> As the 'parser' would be a simple 'include "path/to/file.inc.php";'
> and the write could simply run through the defined variables, maybe =20=
> in an array, it should be Very simple.
>
> But if you wanna play around with parsing & writing XML files (or =20
> plain text), then fine with me - it's just raising the =20
> implementation level... ;-)
>
>
> Best,
>
> Jakob Peterh=E4nsel
>
> 'I don't have to try to be a sex bomb, I am one!'
> - Kylie Minogue
>
> Email: ja...@hj...
> AIM: Marook
> Phone: +45 22684961
>
> On 29/11/2005, at 11:12, Nicolas Contamin wrote:
>
>> On 11/29/05, Marook Kenja <ma...@cr...> wrote:
>>> Hi All,
>>>
>>> Why not write a PHP constant definition file insted?
>>>
>>> Then you only need to Write the file, not parse it back, as it would
>>> be simple
>>>
>>> define ('theSettingName', 'theValue');
>>> lines. Would that not be easier, or?
>>
>> I hardly find the interest of a static page in a script format.
>> When I'll click on the 'save' button, I'll have to rewrite a php file
>> ? Sound strange to me.
>>
>> Would mind to explain a little bit more ?
>> Parsing is not a real charge for the server according to the =20
>> current process.
--
Wesley Miaw
we...@we...
|
|
From: Nicolas C. <nic...@gm...> - 2005-11-30 11:29:17
|
On 11/30/05, Wesley Miaw <we...@we...> wrote: > The advantage of having the variables only defined in config.inc.php > is security. I personally would not want to expose certain things on > the admin page. And I don't think the current situation is too > difficult for regular admins to grasp. Right now, config.inc.php can > be read-only and it can hide things like the blacklisted calendars or > user accounts. We're opening up a whole can of worms if we decide to > make this something that can be modified from a web page. > > Certainly, the idea is nice. But I think things are less complicated > and more secure the current way, and there is very little advantage > to putting together a web-based admin page. config.inc.php is too > straight-forward and simple as it stands for me to believe it can > really benefit from a better UI. > > Anyway, that's my 2 cents. You're right. The login/pass are the only secret information contained in this file, aren't they ? What are their practical uses ? Entering the 'admin' page and publishing (I'm not sure, they're really useful in it), what else ? By the way, thanks all for your cents, thats the major point of a discussio= n. ;) Nicolas. -- I'm a poor and lonesome Yaourt... (Air connu) |
|
From: Wesley M. <we...@we...> - 2005-11-30 18:30:58
|
Hi Nicolas, > You're right. > The login/pass are the only secret information contained in this file, > aren't they ? I would consider the calendar path, things like webcals, showing events, showing todos, login, the tmp_dir, and all of those login things like locked cals, etc to be secret information also. The other stuff is more cosmetic, and probably not damaging to expose. > What are their practical uses ? > Entering the 'admin' page and publishing (I'm not sure, they're really > useful in it), what else ? Not sure what your question is? Later, -- Wesley Miaw we...@we... |
|
From: Nicolas C. <nic...@gm...> - 2005-11-30 23:17:54
|
On 11/30/05, Wesley Miaw <we...@we...> wrote: > > Hi Nicolas, > > > You're right. > > The login/pass are the only secret information contained in this file, > > aren't they ? > > I would consider the calendar path, things like webcals, showing > events, showing todos, login, the tmp_dir, and all of those login > things like locked cals, etc to be secret information also. What is damaging in seeing all thoses information (I'm not talking, of course, about login) ? Calendars are access restricted, by the htaccess procedure, and everything else is just information, in a readonly (well configure) anonymous web server ... The other stuff is more cosmetic, and probably not damaging to expose. > > > What are their practical uses ? > > Entering the 'admin' page and publishing (I'm not sure, they're really > > useful in it), what else ? > > Not sure what your question is? A part of entering the admin page and publishing calendars, where the coupl= e login/pass is used, in phpicalendar ? (I'm thinking of getting rid of plaintext password, because THAT is a real security breach) Nicolas. |
|
From: Wesley M. <we...@we...> - 2005-11-30 23:28:23
|
Hi Nicolas, >> I would consider the calendar path, things like webcals, showing >> events, showing todos, login, the tmp_dir, and all of those login >> things like locked cals, etc to be secret information also. > > What is damaging in seeing all thoses information (I'm not talking, > of course, about login) ? > Calendars are access restricted, by the htaccess procedure, and > everything else is just information, in a readonly (well configure) > anonymous web server ... Being able to modify the values such as to show events or todos may expose information the calendar owner or server administrator doesn't want to expose. Supporting webcals from a site that doesn't initially want to do that may result in abuse of their installation. The tmp_dir and calendar path provide information about the web server's internals which could be bad if revealed. Certainly accessing and/or modifying this information is ideally restricted. All I'm saying is that by exposing this on a web page, we're opening ourselves up to additional security concerns and in my opinion the benefits are negligible. >> > What are their practical uses ? >> > Entering the 'admin' page and publishing (I'm not sure, they're >> really >> > useful in it), what else ? >> >> Not sure what your question is? > > A part of entering the admin page and publishing calendars, where > the couple login/pass is used, in phpicalendar ? (I'm thinking of > getting rid of plaintext password, because THAT is a real security > breach) I still don't understand your question, sorry? I don't see much alternative to having a plaintext username/password for the admin login. You want to do a client-side one-way hash or something? Or something more complicated like SiteKey? Later, -- Wesley Miaw we...@we... |
|
From: Nicolas C. <nic...@gm...> - 2005-11-30 23:49:55
|
Hi Wesley,
On 12/1/05, Wesley Miaw <we...@we...> wrote:
>
> Being able to modify the values such as to show events or todos may
> expose information the calendar owner or server administrator doesn't
> want to expose. Supporting webcals from a site that doesn't initially
> want to do that may result in abuse of their installation. The
> tmp_dir and calendar path provide information about the web server's
> internals which could be bad if revealed.
>
> Certainly accessing and/or modifying this information is ideally
> restricted. All I'm saying is that by exposing this on a web page,
> we're opening ourselves up to additional security concerns and in my
> opinion the benefits are negligible.
Ok.
The idea is to let just the admin modifying those parameters, under the
secure admin area.
So if apache is well configured, it would be any problem.
I'll work on it next week, when I'll be less busy, and call you back for
analysing the effectivness.
I still don't understand your question, sorry?
Login/pass seem to be used only for admin purpose.
And according to the code, 'admin' is an apache authenticated user, so i'm
not sure, it's usefull to duplicate it (and in a clear format).
I don't see much alternative to having a plaintext username/password
> for the admin login. You want to do a client-side one-way hash or
> something? Or something more complicated like SiteKey?
>
Yes a ('homemade' ?) hash or a web base auth. as we already use in '
publish.ical.php'.
Let stand this point until I give you something to (crack), look at.
Nicolas.
|
|
From: Wesley M. <we...@we...> - 2005-12-01 05:03:09
|
Hi Nicolas,
> Ok.
> The idea is to let just the admin modifying those parameters, under
> the secure admin area.
> So if apache is well configured, it would be any problem.
>
> I'll work on it next week, when I'll be less busy, and call you
> back for analysing the effectivness.
Just to be clear, my opinion is that we shouldn't make the contents
of config.inc.php editable or viewable from a web page. I do not know
if any of the other developers have an opinion on this one way or the
other.
>> I still don't understand your question, sorry?
>
> Login/pass seem to be used only for admin purpose.
> And according to the code, 'admin' is an apache authenticated user,
> so i'm not sure, it's usefull to duplicate it (and in a clear format).
There are different logins at work here. The login for the admin page
is not an HTTP authenticated user. HTTP authentication is used (at
least as far as config.inc.php is concerned) to identify users for
access to different calendars.
The login for the admin page may either be authenticated against the
username in config.inc.php or against an FTP server (which I have not
tried myself) and is used to determine who can upload calendar files.
BTW - I just noticed the default is for admin to be 'yes'. I think it
should default to 'no'. Anyone else have opinions on this?
>> I don't see much alternative to having a plaintext username/password
>> for the admin login. You want to do a client-side one-way hash or
>> something? Or something more complicated like SiteKey?
>
> Yes a ('homemade' ?) hash or a web base auth. as we already use in
> 'publish.ical.php'.
HTTP authentication is also passed in the clear unless you are using
SSL. So that doesn't give you any benefits over the current plaintext
login. Turning on HTTP authentication also requires more web server
privileges than some people have. So moving from the current username/
password text login to an HTTP authentication is a bad idea in my
opinion. It will work for less people, and not give you any security
benefits.
A client-side hash is an interesting thing to consider. But to do
this securely, you need to make it a one-way hash that is different
every time, based on a token provided by the server. And the server
needs to manage the token(s) that were distributed to allow only one-
time use at the client. Otherwise you can just replay the captured
hash and you're in. Those same tokens need some sort of expiration.
If you want to try and tackle implementing something like Diffie-
Hellman (which I think still has problems, but I always remember the
name) then you're welcome to. A bit of overkill in my opinion though.
We could ask for peer-review of the PHP code at sci.crypt or something.
Later,
--
Wesley Miaw
we...@we...
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X