LuxCal Forum

The place for questions, suggestions and news about the LuxCal Event Calendar

User:   Password:   Remember Me?   
LuxCal Forum / LuxCal / Comments and Suggestions / lcaldbc.dat to lcconfig.php
Posted:  17 Dec 2012 01:23
I just upgraded to v273 from v272a - seems to have gone through without a hitch!

Just out of curiosity, why did you decide to switch back to a non encrypted configuration file?  Was it simply because updating the database credentials was too difficult?  Or did you also come to the conclusion that there is no security enhancement over a plain text php script file?  I noticed in your release notes you indicate the php script file actually provides BETTER security?  I'm just curious about your take on this is all.
Posted:  17 Dec 2012 03:49
I've been thinking about this...  Is the php script file considered more secure because, at least with a web server properly set up to serve PHP, there is no way (short of a security problem in PHP and/or the web server software) for someone to download the PHP script file and/or view the contets thereof?  But with the encrypted security file someone actually COULD download the file and possibly break the encryption?
Posted:  17 Dec 2012 09:56

I could be wrong, I believe you are correct with it being a php file. Any php scripts I have installed have always had the database credentials in a php file.

"Little Guy"
Some own motorcycles, others ride them.

Find great LuxCal examples by Schwartz at
Posted:  17 Dec 2012 11:47
Hi Gork and Dan,
There are three main reasons for this change:
1. Some "server experts" pointed out to me that sensitive data should not be stored in a .dat file, because this type of file can be easily downloaded. As Gork said above, PHP files cannot be downloaded so easily, because they are served via the PHP processor (and the new lcconfig.php file doesn't output anything).
2. The encryption method used in the previous versions was an "intelligent piece of art" created by myself wink The fact that the encryption method was "home made" was a challenge to some wizards who reverse-engineered my code and, with an IQ of 140+, it appeared to be not so difficult to break the method. Security is relative . . .
3. The encrypted db credentials were an obstacle for some calendar users who for instance wanted to move the calendar to a new host. With the new approach my help is less needed (I hope).

And you're right Dan, other applications most of the time use php-files too for usernames and passwords.
Posted:  17 Dec 2012 14:01
Makes sense...  It also makes me feel a bit dumb for not thinking of that before!

I'm still glad the calendar settings are now saved in the database instead of the PHP script file though.  So I guess that trip from PHP to DOC and back to PHP wasn't a wasted effort.  :)