Fixing line break

caching,_sessions,_local_storage_&_cookies.md

@@ -2,19 +2,11 @@
 
 ## Caching
 
-For caching the `CacheManager` provides access to the caching systems in place. 
-Out of the box the CacheManager supports and automatically initializes either 
-Redis or Memcached depending on the client configuration. The caching is 
-not mandatory and therfor shouldn't be missuesed as in-memory database. It is 
-not necessary to check if Redis or Memcached are available the CacheManager 
-automatically handles the caching based on their existence.
+For caching the `CacheManager` provides access to the caching systems in place. Out of the box the CacheManager supports and automatically initializes either Redis or Memcached depending on the client configuration. The caching is not mandatory and therfor shouldn't be missuesed as in-memory database. It is not necessary to check if Redis or Memcached are available the CacheManager automatically handles the caching based on their existence.
 
 ### HTTP Cache
 
-By default only stylesheets, javascript and layout images as well as module 
-images are cached. Everything else is considered volatile and not cached. 
-If a response specific response should be cached feel free to use the 
-response header:
+By default only stylesheets, javascript and layout images as well as module images are cached. Everything else is considered volatile and not cached. If a response specific response should be cached feel free to use the response header:
 
 Example usage for 30 days caching:
 
@@ -22,9 +14,7 @@ Example usage for 30 days caching:
 $resposne->setHeader('Cache-Control', 'Cache-Control: max-age=2592000');
 ```
 
-In order to trigger a re-cache of stylesheets or javascript files make sure to 
-include their version hash as file name. This way version updates will result 
-in a new file name and will be re-cached by the client browser.
+In order to trigger a re-cache of stylesheets or javascript files make sure to include their version hash as file name. This way version updates will result in a new file name and will be re-cached by the client browser.
 
 Example usage:
 
@@ -34,24 +24,23 @@ $head->addAsset(AssetType::JS, $request->getUri()->getBase() . 'Modules/Media/Mo
 
 ## Sessions
 
-Sessions are handled via the `SessionManager`. Sessions can be set and 
-manipulated from the web application as well as the socket or console 
-application. 
+Sessions are handled via the `SessionManager`. Sessions can be set and manipulated from the web application as well as the socket or console application. 
 
 ### HTTP
 
-The Http session will be saved automatically, there is no need to access the 
-super global `$_SESSION`. Make sure to only modify session data using the 
-SessionManager
+The Http session will be saved automatically, there is no need to access the super global `$_SESSION`. Make sure to only modify session data using the SessionManager
 
 ### Socket & Console
 
-The session will be stored and assoziated with the logged in user in memory. 
-A disconnect or quit is considered as a logout and therefor results in the 
-destruction of the session object of this user and will be empty for the 
-next login.
+The session will be stored and assoziated with the logged in user in memory. A disconnect or quit is considered as a logout and therefor results in the destruction of the session object of this user and will be empty for the next login.
 
 ## Local Storage
 
 
-## Cookies
+## Cookies
+
+### PHP
+
+Only use cookies when absolutely necessary. Most of the time session data or local storage is the prefered choice. The `CookieJar` class provides you with all the necessary functionality similar to the `SessionManager`. The super global `$_COOKIE` is also overwritten and shouldn't be used anywhere.
+
+### JavaScript

security_guidelines.md

@@ -2,10 +2,7 @@
 
 ## CSRF
 
-The tool to protect clients from CSRF is a randomly generated CSRF token,
-that can be used inside the URI generator. It's highly recomended to make 
-use of this token whenever possible to reduce the risk of CSRF 
-attacks.
+The tool to protect clients from CSRF is a randomly generated CSRF token, that can be used inside the URI generator. It's highly recomended to make use of this token whenever possible to reduce the risk of CSRF attacks.
 
 Example usage:
 
@@ -15,16 +12,9 @@ Example usage:
 </form>
 ```
 
-Now the application will receive the automatically generated CSRF token as 
-query parameter for further use. If the CSRF token is not the same as the one 
-assoziated with the client on the server side the client will receive a 403 
-HTTP response. The CSRF however doesn't have be specified, if that's the case 
-**every module itself must make sure wheter a valid CSRF token is required** 
-or not. The reason for this is that third party requests are a possibility as 
-well, and sharing the private CSRF token would render it useless.
+Now the application will receive the automatically generated CSRF token as query parameter for further use. If the CSRF token is not the same as the one assoziated with the client on the server side the client will receive a 403 HTTP response. The CSRF however doesn't have be specified, if that's the case **every module itself must make sure wheter a valid CSRF token is required** or not. The reason for this is that third party requests are a possibility as well, and sharing the private CSRF token would render it useless.
 
-Since the validation of the CSRF token is performed automatically it is only 
-necessary to check the existence, since if it exists it has to be valid.
+Since the validation of the CSRF token is performed automatically it is only necessary to check the existence, since if it exists it has to be valid.
 
 Example usage in a module handling a API request:
 
@@ -41,37 +31,30 @@ if($request->getData('CSRF') === null) {
 
 ### When do I check for the CSRF token validity/existence?
 
-Always! Except the request has the potential to come from third party 
-referrers. Here a few examples of requests that must always have a valid CSRF 
-token:
+Always! Except the request has the potential to come from third party referrers. Here a few examples of requests that must always have a valid CSRF token:
 
 1. Login/logout
 2. Creating/updating/deleting a news post
 3. Uploading media files
 4. Changes in user settings
 
-Here some examples of requests that **MAY** not need a validation (mostly API 
-GET requests):
+Here some examples of requests that **MAY** not need a validation (mostly API GET requests):
 
 1. Get news posts
 2. Get last log message
 
-It's important to understand that the CSRF token is not equivalent with 
-authentication or API token. Client can be logged out and still need a 
-CSRF token and obviously vice versa.
+It's important to understand that the CSRF token is not equivalent with authentication or API token. Client can be logged out and still need a CSRF token and obviously vice versa.
 
 ## Super globals
 
-Super globals are not available througout the application and the values can 
-only be accesed through middleware classes like:
+Super globals are not available througout the application and the values can only be accesed through middleware classes like:
 
 * SessionManager
 * CookieJar
 * Request
 * Response
 
-In some cases super globals will even be overwritten by values from these 
-classes before generating a response. Do not directly access super globals!
+In some cases super globals will even be overwritten by values from these classes before generating a response. Do not directly access super globals!
 
 ## Input validation
 
@@ -91,10 +74,7 @@ Be vigilant of where and how the path for the following scenarios comes from:
 3. `file_get_contents('../relative/path/to/' . $path);`
 4. `mkdir($path);`
 
-These are just a few examples but it is very important to make sure, that 
-these paths only have access to wherever the programmer intended them for. 
-At first it is always a good idea to get the `$path = realpath($path)` of a 
-path in order to make sure the path exists and for further validation.
+These are just a few examples but it is very important to make sure, that these paths only have access to wherever the programmer intended them for. At first it is always a good idea to get the `$path = realpath($path)` of a path in order to make sure the path exists and for further validation.
 
 Example usage:
 
@@ -104,9 +84,7 @@ if(($pathNew = realpath($path)) === false || strpos($pathNew, ROOT_PATH . '/Modu
 }
 ```
 
-The example throws an exception if the path either doesn't exist or is trying 
-to access a path that doesn't contain the path defined in 
-`ROOT_PATH . '/Modules/' . self::$module`. Another validation could be:
+The example throws an exception if the path either doesn't exist or is trying to access a path that doesn't contain the path defined in `ROOT_PATH . '/Modules/' . self::$module`. Another validation could be:
 
 ```
 if(($pathNew = realpath($path)) === false || !Validator::startsWith($pathNew, ROOT_PATH)) {
@@ -114,7 +92,4 @@ if(($pathNew = realpath($path)) === false || !Validator::startsWith($pathNew, RO
 }
 ```
 
-This example now is not only checking if the path exists and if it contains a 
-path element, it also makes sure that the path is inside the application root 
-path. You could as easily replace `ROOT_PATH` with `self::MODULE_PATH` and this 
-validation would make sure `$path` only directs within a module.
+This example now is not only checking if the path exists and if it contains a path element, it also makes sure that the path is inside the application root path. You could as easily replace `ROOT_PATH` with `self::MODULE_PATH` and this validation would make sure `$path` only directs within a module.