Security in the Aukyla Platform
Introduction
In essence, security in the Aukyla Platform does not differ from the security in any other PHP environment. However, it is good to understand some of the security consequences of functionality provided by the Aukyla Platform, as well as to understand how access to frontends is granted or denied.
Frontend access control
Every frontend can potentially be unsafe and could contain security flaws (just like any script can). Therefore, access to frontends is by default restricted to users who are logged in. Exceptions to this rule are the default frontend, which is always available, and frontends which have been explicitly white-listed. After a fresh installation of the Aukyla Platform exactly one frontend will be installed, which is the Aukyla Administration Area. This frontend is then both the default frontend, and it is also white-listed. The motivation for white-listing the Admin Area is that once you have installed another frontend and made it the default, you should still be able to log in to the Admin Area and perform administration tasks, even if the other frontend breaks.
The Aukyla Administration Area checks that it can only be used by users who have administration privileges. As long as you're using the default credential handler (which can be configured in the Admin Area as well), every user who is a member of the group admin is considered to have administration privileges. If you're using the PostgreSQL credential handler, those users who are superusers in the PostgreSQL database will be considered administrators.
You can alter the access control for frontends in the Server tab in the Admin Area. There you can set which frontend should be the default frontend, which frontends are white-listed. You can even uncheck the option to limit anonymous users to the default frontend, but this is not recommended.
The Login class
The Aukyla Platform provides a complete login system with session and credential management. Logging in and session management are all fully transparent to your scripts and you shouldn't need to be bothered with them. Of course, it may be interesting to query whether the current user (the user doing the current page request) is logged in, and if he is, what's his or her username. The first can be queried using the Login::userLoggedIn() function, and the second can be get using the Login::username() function. Credentials can be managed using the aptly named CredentialManager class.
The actual logging in of users is triggered either by sending a page request to the index.php script with the parameters action, username and password. The action variable should always have the value "Login", the others obviously are the user's username and password. The same request can also be sent to the login.php script, which can be useful from AJAX applications. Users can be logged out by sending a request with the action parameter set to "Logout". There's a ready-to-use LoginForm class that sends the right page requests for logging in.
Permissions checking with Aukyla Local URI namespaces
The Aukyla Platform provides a mechanism called Local URI namespaces. Using this mechanism you can store files in special URIs using standard file I/O functions, but with added benefits of having support for meta-data and built-in permissions control. It is important to understand there are two ways of getting access to the data in a Local URI namespace, namely through the file functions provided by PHP, and through the Aukyla Platform's URI class.
Every Local URI namespace has built-in facilities to indicate what permissions different users, and the currently logged-in user in particular, have to its data. These permissions are automatically checked when using the URI class to access the data, but they have to be explicitly checked when you're using the PHP file functions. Therefore, it is always recommended to use the URI class when working with Local URI namespaces; calls to the URI class will automatically fail if the current user does not have the right permissions to perform the operation you're trying to perform. As an added security measure, the URI class will disallow all access to the local filesystem and other PHP file streams which are not Local URI's, so any operations through the URI class will be guaranteed to only get access to Local URI namespaces, with built-in permissions checking.
As said, access to a Local URI namespace is also possible through the regular PHP file functions, and in some cases you will have no choice but to use these. If that's the case, you will want to check whether the current user has the right permissions using the URI::permissions() function before proceeding.
Finally, the Aukyla Platform only comes with Local URI namespace plugins for accessing temporary files and accessing uploaded files. If you're looking for a Local URI namespace implementing a fairly complete virtual filesystem, you should check out ADMS which comes with the ADMS2 Local URI namespace.
Escaping functions to avoid cross-site scripting attacks
Make sure you escape all strings from external sources before you include them in the output you generate. This avoids that arbitrary JavaScript code can be inserted into your output causing cross-site scripting attacks.
There are two useful escaping functions you may want to use, which are String::safe() and String::jsSafe(). String::safe() works the same as the PHP function htmlspecialchars(), but you can also pass it an extra argument to specify the character encoding of the input string, in which case it will use iconv() to also convert the string to the correct output encoding (UTF-8, by default). String::jsSafe() is again an extension on htmlspecialchars(), but this function will also escape backslashes and single quotes, so that strings can be safely used in single-quoted JavaScript strings.