Table of contents ▼▲
Pretty Urls
Pretty Url's can now be used. This means you would call http://www.turland.net/start rather than the longer http://www.turland.net/wikidx.php?page=startDependant on the htacess file and access to mod_rewrite. Most ISP's give access to this.
The wiki will adjust its internal link generation to create 'pretty' or 'standard' links depending on the calling url.
A new API call has been added to support this.. API::Pretty_HREF()
.htaccess
Finally managed to get a working htacess file. It now blocks direct calls to many files. Also has a section which is needed for the pretty url's to work.
Protecting against 'Cross Site Request Forgery' attacks
It seems some spammers out there have decided to write a script to replace the content of a wikidx site every nn minutes (thanks eric for reporting). To try and reduce possible attacks I have added a hidden input field to the edit forms. The value is an md5 hash of your session_id and the content of$FormValidationPassword. When a save request is issued, this value is checked against the same calculated value. If they match, great, if not then either the password is not known or the session_id is incorrect and the save fails.
Failure due to missing skin
An oversight in the setskin routines meant that even if the requested skin did not exist, it would still try and use it, failing the code in the process. Will now revert to the 'default' skin.
Install script & File permissions
After reading many documents regarding file permissions on shared unix servers I have decided to change how WikiDX installs. Gone is the setting of 2777 and checking of guid() etc... A much simpler model is now in place that allows the admin to maintain control over the data files.On a shared unix server environment there is little to no controls you can put in place to prevent a file from being modified via apache/php. Due to the user/group used (normally nobody/nobody), any file that is created by that user, can be modified. For example if you knew the file locations of other 'web maintained' files on a shared server, code could be written to modify them.
So now the admin creates the data & trash files with permissions of 0777. Unfortunately, this is a limitation in *nix authority, in that 0777 is required to allow the nobody/nobody user create files in that directory. SO now when php creates a file, it will have perms of 0666 and be owned by nobody/nobody. This means that the admin now has full control over the datafiles via ftp. This was an extremely annoying side-effect of the previous install script
I am always up for improvements, so if someone knows differently, please let me know.