Some privacy, cookies and uploaded data issues divided into two parts are presented below:
Front - end
On the client side, the script only stores information about the website's language. This information is stored in a cookie “sLanguage”. If this cookie is disabled, it will be impossible to browse the website in any language, for which a translation was added.
Data of a user that filled an order form without submitting it and moved to another subpage are also stored in cookies. These data will be stored until the browser is closed. Names of cookies storing these data are: sFirstName, sLastName, sCompanyName, sStreet, sZipCode, sCity, sPhone, sEmail.
When a customer clicks “save cart”, sCustomeren cookie is created. It will store an encrypted id of the temporary order for 72 hours.
The script also stores the temporary order id in a session variable if a user adds a new product to the cart as well as the user information if the user is logged. Storing these data is necessary for the script to function properly.
And finally, personal data and contact information the client submits while placing an order are stored in the orders database.
Back - end
There are more data stored on the administrator’s side. These are cookies “sLanguageA”, “sLogin”, as well as the session data, which store login information.
After logging, news from OpenSolution.org are downloaded, as well as random information in the “Additional information” box. For statistical purposes, Opensolution also uploads the www address. If you do not want to send this information, remove the “$_SERVER[HTTP_HOST]” variable form the “templates/admin/home.php” template.
If the required link to OpenSolution.org is removed, and this option hasn’t been paid for yet, the script displays an alert about the license breach and sends this information to OpenSolution. Due to security reasons we will not disclose where this information is sent to. If, however, you have removed the aforementioned variable and you are not breaking the license agreement, you don’t have to worry about any information being sent to OpenSolution.
We strongly encourage not to remove the OpenSolution.org news from the pulpit. If you do that, you will not be notified about security issues of the script or any possible updates. Don’t be surprised if someone takes advantage of your not-up-to-date script and uploads some undesired contents to your site.
We developed a range of additional script's safety protocols, which should efficiently prevent any third parties from intercepting classified data. It’s worth emphasizing that the script has no gaps or errors that we know of, which could be used by the intruders, but there are several issues to consider that might improved the script's security:
- Limit access to the admin panel to specific IP addresses. Add the $config['allowed_ips_admin_panel'] variable in the configuration file. Learn more » about this variable.
- You should not save the login data in an FTP clients (e.g. Total Commander). There are programs of the trojan horses type, which allow the assailants to intercept these data and access your data.
- It’s worth finding an uncommon login and password to the admin panel, that include letters and digits and are of considerable length. Often the default login ‘admin’ is adapted by the user - this makes a brake in easier.
- After loading the page you must change the file name "admin.php" to something else, like: "db6ebd.php". When this change is done, the administration panel's address in your browser will be www.your-address.com/db6ebd.php. Don't share this address with other people - it will make it much harder to hack your website.
For versions v6.2 and higher, edit the "database/config/general.php" file, find the $config['admin_file'] variable, and replace its value "admin.php" with the new file name, which in this case is "db6ebd.php".
- Another possibility is to attempt to set the more restrictive permissions directories and files that require write permissions to, for example, 700 or 600 and then to test whether the script works correctly
- Check whether all known vulnerabilities in the script are fixed.
- Be careful if you want to install some scripts or plugins you don’t know. Hackers commonly use such popular scripts vulnerability to hack your site. So we advise you not to install for example any file managers for WYSIWYG, because they are usually not secure enough and vulnerable.
- Do not share the script with third parties. Database stores clients’ personal data, that should be protected and not shared with unauthorized parties. If you need to share the script, send it without files which names start with “orders” and are located in the “database/” directory.
Here we present pros and cons of flat files. We want users to be aware of their beauty as well as their limitations.
Some are terrified by the idea of flat files. Many have never even seen this solution - all they know is SQL and the like. For those who have never heard of it, we present a list of flat files qualities and faults.
Flat files pros
- simple installation - to make the script run, after uploading it to the server you just have to change permission modes of some directories and files (sometimes the default values are the right ones)
- speed - data collected from flat files in the script are collected significantly faster than in case of MySQL, SQLite, etc. This is of course true only in case of small websites. You have to remember that the script is meant to handle small websites with 1 to 2000 products (the limit is 3000 products, although it depends on products' description length length and server settings).
- the script works almost everywhere - some hosting services (especially the free ones) do not allow sharing of SQL databases. The script will solve this problem for you.
- easy data transfer - if you want to copy the whole website from one server to another, all you have to do is to download the script from the FTP account, upload it to the other server, set the permissions to the specific directories and files, and it’s done!
- easy backup - there’s a free plugin you can download, that will create your backup, or you can just login to your FTP account and copy the “database/” directory
- find and replace - once you master flat files you will realize, that in most cases you will be able to modify the data in pages or files collectively. You just have to download a file from the FTP account and when editing it in a notepad, use the find and replace function.
- security - flat files are managed without using SQL queries, so the scripts don’t require additional security protocols, e.g. against SQL Injection type attacks.
Flat files cons
- limited data size - this script in not suited to manage very large websites (although there are many exceptions from this rule). If you plan to store a lot of content, e.g. you want to create a website with 2000 products and without changing server limitations, there could be a problem. It all depends on:
- description length - you can accommodate 2000 products with one short description on each, or 100 products with 5 page-worth of text on it. Our experience tells us, that the users often paste Microsoft Word text in their description, which generates plenty of redundant code, and so to put 3 sentences in the description, the actual text takes 10 times more space due to the trash data. That’s why it is important to watch the text quality and use the HTML code only if necessary.
- server settings - on many servers the cache limit is set to 32 MB or more. On some the limit is still larger (we’ve even seen the limit to be 128 MB). This kind of limit will let the server to manage your website even if other servers wouldn’t.
- possibility of file damage larger than in SQL - this kind of situations can happen even in SQL databases, so don’t panic. Still, the probability of file damage is certainly larger and is increased with multiple administrators managing the website simultaneously. This is why we encourage to make backups using the free plugin or by copying the “database/” directory from the FTP account every time there’s a significant number of modifications made to the pages, products or files data.
- more complicated data management - managing the database can be problematic for someone used to the SQL type database. Nevertheless, a skilled programmer will be able to master it in a matter of hours.
The script generates data several times faster than most other available CMS scripts like WordPress, Joomla, etc (read about script performance). This is a very significant advantage. However there are limitations on the database files sizes. It is difficult to determine an exact limit of number of pages and files attached to it, since it depends on several factors like the size of page descriptions and products, number of pages and products and server settings.
Supposing restrictive limits of the server one has to assume, that files in the “database/” directory are not larger than 8 MB for one language, not including the statistics files (containing the "stats" phrase in their name). Although in most cases it will be possible to store files 2-3 times larger.
Please, remember also, that the script is prepared to operate with small amounts of data. Even if server allows for storage of bigger data sets, the script will not handle it well - it will slow down and overload the server processor. The script handles best small websites hosting 1000 products and 100 pages and subpages with little content (large content would be 4 pages (a4 size) of text/code).
For more information about the database go to the Flat files - pros and cons section.