|
||||
 |
|
|||
Since tinySimple CMS is a file-based system, tinySimple must be able to save files on the server.
The system supports two optional ways of saving files: either by writing via FTP or by writing directly to the server's file system. Unless you have your own private server you probably won't be able (allowed) to write files directly.
The FTP file writing method requires that you enter the FTP username and pasword - whereas tinySimple tries to guess the 'FTP root'* (or 'ftp-to-web'-folder).
Using the FTP file writing method tinySimple also needs to know (and be allowed to use) a temporary folder to write files to. tinySimple will in most cases be able to locate the server's temp folder or PHP's image upload folder – otherwise you'll be told to type it in manually.
known issues
• if you're using the FTP file write method, and the document root path (i.e. the folder path that your site is placed in on the server) contains 2 folders with the same name, tinySimple won't be able to figure out what your 'ftp-to-web' path is
– example: /home/someuser/www/www/
– in such cases tinySimple will not work (using the FTP file write method)
The system supports 2 users: a system administrator and a content editor.
The content editor cannot access system settings, otherwise the two users have the same privileges.
Passwords are stored hashed.
When using Firefox (or other Gecko-based browser) passwords are also transmitted hashed over the net** – so for max security go for Firefox.
legal characters
• usernames are a-z (case-insensitive), numbers, underscore and hyphen
• passwords are case-sensitive (A not the same as a)
failed logins
• after 3 consecutive failed logins the user cannot login for 5 minutes
• after 6 consecutive failed logins the user's IP address is blocked (for login, not for browsing the site)
• un-blocking a user's IP:
– delete the file login_control/_[IP address]_blocked in the site's save folder
The control panel has a button for setting the current debugging level. In this context the debugging level controls error messages' detailing level, and ultimately allows for PHP errors to be exposed and written to screen. However, only your own session (you being logged into the system) is affected – for an outsider (someone not logged in) error messages will always stay on the least informative level and PHP errors will be suppressed no matter what.
* The FTP root is rarely something that a hosting provider would tell you (though no real secret, folks just usually don't need that information). And the FTP root can be pretty tricky to figure out.
** Hashing client-side is not possible for IE and Webkit because it would interfere with those browsers' login memorizers. Apparantly Gecko's password memorizer kicks in before evaluating the form data to be sent, whereas IE and Webkit's memorizers stumbles in after evaluating the form data – which in effect means that they would store the password hash instead of the hash itself, and when the user then revisits the site the browser ends up sending a hash of the hash (and that's obviously useless).