System
In this article you will receive useful information in terms of the system-tab in the Shopware backend settings. Here we explain in detail the topics service, input filter, backend, passwords and log.
Service mode
Shopware gives you the opportunity to activate a closure mode for the frontend. If activated the complete frontend is not reachable except for the excluded IP`s which have to be saved in the field IP excluded from closure.
The maintenance mode will only be active in the frontend after you have cleared the store cache. You can do this in the backend under Configuration > Cache / Performance > Clear shop cache.
Deactivate frontend
To do this, you need had to change two settings in the backend. You can call this function in the basic settings at the menu entry System > Service. Activate the closure by setting Closure shop due to maintenance to Yes.
To find out your IP, some external sites offer a special service (E.g. http://www.whatismyip.com/). After you have copied your IP, save it in the field IP excluded from closure: (2). If more than one IP is allowed to enter the frontend, you can enter another IP in the field. In this case use a space as a separator of the ip addresses like this: "192.168.178.100 192.168.178.101". The entry could look this:
How can I customize the maintenance text in the frontend?
The maintenance text, which is displayed in the frontend, can be easily modified in the snippet management. Open the snippets module in the backend under Configuration > Snippets and edit the needed snippet:
| Snippet | Description | |
|---|---|---|
| ServiceHeader | Not available due to maintenance! | |
| ServiceIndexTitle | Not available due to maintenance! | |
| ServiceText | Due to maintenance work, the shop is temporarily not available. |
After modifying the snippets you have to save the changes and clear the shop cache. The snippet supports HTML formatted text and embed images. This means you can also place images into the snippet.
Input filter
Shopware has a few mechanisms by default to protect you from attacks.
- SQL-Injection protection
- XSS - Protection
- RemoteFileInclusion protection
Own filters
Here you can define a own regex for the InputFilter. Matching request variables won't reach the shop.
The separator is "|".
The regex has to be constructed by the following example:
javascript:|src\s*=|on[a-z]+\s*=|style\s*=
You should only configure this, when you know what you're doing!
Use strip_tags globally
When you activate this, each form input in the frontend is filtered with strip_tags.
This function filters HTML- and PHP-tags for input forms in the frontend.
Backend
In this area you can manage the basic settings for your backend.
- PHP timeout: Here you can define a timeframe for inactive backend sessions. Idle users will be automatically logged off after the set time has passed. Note: Selecting 0 seconds disables the automatic logoff feature.
- Selectable language: Here you can set the default backend languages available. This setting will be overwritten by a user's personal language settings. This makes sure, users of other languages don't get in trouble at the login.
Never delete the default languages "Deutsch" or "Englisch" - they are vital system languages!
- Run 'First Run Wizard' on next backend call: If you want to run the First Run Wizard again, activate this option, clear the cache, log off and log in again to the backend. This option is not permanent, after completing the First Run Wizard, it will be deactivated again.
- Ajax timeout: Defines the maximum execution time of ExtJS Ajax requests (in seconds). The minimum value is 6, if you manually fill in a lower value, it will be saved without hesitation, but the default value (30) is used from then on.
- Automatically expand backend menu entries: If active, the main menu entries will expand when hovering over them. If deactivated, they will require a click to expand.
- Notification position: This sets the position of the system's growl messages (the small black notifications) are displayed. By default "Top right" is set, however you can freely choose any of the 4 corners.
Passwords
The setting Passwords (1) define the encryption type and the amount of work of the hash value calculation.
- Password algorithm (2): Auto, Bcrypt, Sha256, Md5. Standard value is Auto (Bcrypt). Bcrypt is available from php 5.3.7. Sha256 is used as fallback.
- Live migration (3): Outdated password algorithms by customer-accounts from older versions of Shopware (< SW4.1.0) were automatically updated.
- Bcrypt iterations (4): As higher time required for generating a new password as more secure the BCrypt password is. We recommend carefully increase the value 1. Default is 10. If the value is much too high (E.g. 20) the server requires more memory power when customers create an account, if password algorithm is BCrypt.
- Sha256 iterations (5): As higher time required for generating a new password as more secure the Bcrypt-password is. We require the value 100. Default is 1000. If the value is much too high (E.g. 20000) the server requires more memory power when customers create an account, if password algorithm is Sha256.
Log
The log is a helpful tool especially for developer to track error messages in the shop.
Report errors to shop owner
If an error occurs, the shop will notify the shop owner by email. This is helpful, when you built up your shop and test it, so eventually not catched errors will be sent by mail.
This setting is especially not intended for productive systems! E.g. through clicking old links, which are not reachable anymore, an error message would be sent too, even if this error is desired or not!
Alternative email address for errors
Here you may enter an alternative email address, to which the error mails from your shop will be send. If you do not enter an email address here, the address from the basic information will be used.
Log level
This setting defines for which log levels you will receive the emails. The default setting is "Warning", but you could e.g. change it to "Error", to only receive mails for log entries containing an error or worse. The following explains which log levels exist and for which events the messages are sent.
Debug: Lowest log level. Messages are sent for insignificant events. Example: Messages from the user or SQL logs.
Info: Uncommon events.
Notice: Exeptional occurences that are not errors. Examples: Use of depricated APIs, poor use an API.
Warning: Runtime Errors.
Error: Critical conditions. Example: Application component unavailable, unexpected exception.
Critical: Action must be talen immediately. Examples: Entire shop or database are unavailable.
Alert: Urgent alert.
Emergency: Highest log level. This is only bumped when API breaks are done and should follow the major version of the library.