This article describes how the default editor user authentication works. It also shows how to replace it if needed with something of your own. By default, the user authentication is done through the HTTP basic access authentication mechanism. Keep in mind that this sends the login and password in plain text so it's strongly recommended to run it through the HTTPS connection. The MD5 checksum is calculated from the received password and is compared to the checksum stored in the database for that login. If everything is fine, the editor action executes.

There is no way to edit the editor users through the editor, you will have to do it manually. All editor user data is stored in the EditorUsers table. It has the following columns: name, password, permissions and language. The first two are self-explanatory, but the latter two require some explanation. The "language" column has a two-letter language identifier in it that sets the language that the editor will use. Editor localization article provides more information.

If you wish to replace the authentication completely, you need to override the EditServer.checkUserAuth() method call. This method is called on every client request and should return editor user structure (with permissions string set) if the authentication was successful, or null otherwise.

The editor does not have a way to edit the editor users and their permissions. The default authentication mechanism uses the EditorUsers database table to store user information. It has the following fields:

• "ID" - User ID.
• "Language" - Two-symbol user language ID.
• "Name" - User login.
• "Password" - MD5 hash of user password.
• "Permissions" - User permissions string.

The PostgreSQL database has a built-in function to calculate MD5 hash of the string. You can use it to change passwords or when you add new users.

Usage example:

INSERT INTO EditorUsers (Name, Password, Permissions, Language) VALUES ('admin', md5('123'), '*', 'en');

The "permissions" column is a comma-separated string that holds editor action execution permissions. The simplest value is "*". That means that this user can execute every editor action. An empty string means this user cannot execute any actions. You can use the module names or specific request names to limit the user to. Permissions string example:

core/user,core/effect.list,core/locale

This example allows the editor user to use everything from the core user and localization modules. It also allows him to see a list of user effect types.

The main editor page has lots of links to various parts of editor functionality. If the user does not have permissions to execute the action attached to a link, that link will not be displayed. If you see the main page with lots of links missing, that means you don't have enough permissions. There is also a special permission key for main editor page. It is called "core/main.serverInfo" and it controls the visibility of the server information block on the main page. If you want users to view the main page itself, but do not want to display the server information, add "core/main.index" to the permissions string without adding the "core/main.serverInfo". For example, adding the string "core/main" will allow both the main page and server information block access, since both of them belong to that module.

The editor stats module uses user sub-permissions for controlling user access to specific stats pages. You can read about it in detail in Stats article.

The editor application class can set a list of editor actions that can be executed without proper authentication with EditServer.actionsNoAuth array. It can also set the default editor action with EditServer.defaultAction and default editor action when the user is not authenticated with EditServer.defaultActionNoAuth.