install.lock

Ryan and I both feel we should apot something like this (except call our file install.lock for uniqueness):

Once the installation, import or update has completed, there will be an empty file called lock.conf in the base directory. The only function this file has with its existance is to disable these very scripts so that nobody can re-run the setup again and reset all data this way. It’s safe to remove the file when you also removed all install/import/update PHP scripts (e.g. install.php).

Attention: If file access rights are not set correctly, a warning will be displayed at the top of the install page. In case the lock.conf file could not be created, you should remove the install script immediately after setup is done since there will be no protection on them!

Its a nice idea, but we have Remove install Folder in-place.

just my .02$ ...

regards,

zi

The remove install folder automatically does not work, and requires an additional layer of getting a user to login via FTP and do something. If we can get it to create/check for this file, at least it would add an extra layer of protection for little coding effort.

hmm...

I agreed , prevent from immediate to-do for end-user.

I personally have forgotten to remove the install folder because I immediately went to work on a site. This could prevent potential site defacing from oversight or ignorance.

It worked for me on TextDrive hosting (nobody else had it working so far ?) : I guess it depends on host configuration, therefore you can not depend on it working no matter where you are hosted, which is a problem. UNB’s system is working fine, might be a good idea to use this system, yeah

Quote from: rthrash at Dec 17, 2005, 12:43 PM

The remove install folder automatically does not work, and requires an additional layer of getting a user to login via FTP and do something. If we can get it to create/check for this file, at least it would add an extra layer of protection for little coding effort.

Might be best to make this a setting inside the DB. If the setting field (e.g. lock_install)is set to on then installer will not run.

That’s an even more elegant solution Raymond... nice. Could require the person to enter the username/password for the default manager user and/or the DB installer in order to execute upgrades.

I like this idea, more security

Thanks