Return to documentation index

Title: Logging into Janox applications

Content:

- Preamble

- Validation level

- Users profiling

- Runtime administrator: root

- Logging as developer

- Passing parameters for direct login

Preamble

Logging into a Janox application is primary done by the Janox login form: this form, for WEB systems, is a static HTML page under Janox runtime alias (http://host/janox/ [janox/jxrnt/htdocs/index.html]), while, for GTK environments, it is a standard window opening at startup.

Informations described here can be set by login form. In the last paragraph ("Passing parameters for direct login") we will see how to bypass the login form, passing directly all needed informations at first call.

Validation level

The type of validation required for project is settable by the

"validation" parameter in the application configuration file

(<app_root>/<app_name>.ini).

Parameter can assume three different values:

"0" No validation required. All sessions are logged with "default" as user ID and all sessions have the same user profile. This validation level is intended for fully free to browse projects, running more as dynamic pages than as applications.

"1" Mandatory validation. Only sessions providing valid credentials are logged in and profiled according to credentials, others are rejected. This validation level is intended for intranet or business-to-business projects, where every logging user is playing an expected role.

"2" Mixed validation. If valid credentials are passed at login, session is logged according with credential, else "default" user ID is used for logging and profiling. This validation level is intended for a wide range of application models, free to browse but with a protected back-end access for personnel.

Users profiling

When a validation level of type 1 or 2 is set, it is possible to switch session profile according to logged user. User profile affects different project aspects:

- User name is set according to credentials: it can be retrieved by developers and it is used for tracking activities.

- In ASP projects, area ID is set to user "ASP area" value.

- Current user rights and roles are assumed, enabling or disabling application functionalities and resources.

- Menus are filtered according to menu profiling settings.

- File system resources (like "temp", "download" or "reporter models" directories) are changed to match personal user file system.

Runtime administrator: root

When a validation level of type 1 or 2 is set, at last one user always exists and that user is "root". At login time, if "root" user does not exist, it is automatically created with blank password. Password will be settable after first login.

User "root" is intended to be the "full" runtime administrator and his main prerogatives are:

- Creating users and assigning roles and rights to them (granting)

- Administering databases, accessing all project used tables with full functionalities for editing, dropping, export/import, etc...

- Accessing project file-system resources

- Setting project options (like keyboard mapping or skin)

- Managing all users scheduled jobs

- In ASP projects, access all data, regardless of "ASP area" code

User "root" is to be used for administration and not production roles.

Logging as developer

While developing projects, in order to get more informations and to better reach project runtime resources, you can login as a DEVELOPER. To login as a developer you must provide valid developer credentials to the project login form: just fill fields "Developer" with developer name and "Key" with developer password.

Allowed developers are listed in file janox/jxrnt/developers: it is a PHP file containing calls to the developer definition function, in the form:

o2def::developer("<developer>", "<key>");

where <developer> is the developer name and <key> is the developer password.

NOTE: <key> parameter can be set both in clear or in hashed (MD5) mode.

When logged as DEVELOPER, an extra menu is added to the context menu (right-click menu for WEB and systray menu for GTK) for information and debugging purposes. When logged as DEVELOPER the runtime administration menu is always visible, regardless of user rights and roles.

Logging as DEVELOPER is required to enable projects and databases conversions.

Passing parameters for direct login

Most of the times, when you need to access several times the same project with the same credentials, can be useful to provide login parameters in the first call, so to avoid to fill up login form each time.

To directly login into a Janox project you need to provide, at last, the "user" parameter, regardless of the project validation level. If no validation is required "user" parameter can be any value. If validation level 1 or 2 is set you can pass the "password" parameter; similarly, for development, you can pass "developer" and "key".

Accepted parameters are:

    user:          User ID
    password:      User password
    dev:           Developer ID
    key:           Developer password
    jxrnt (GTK):   Janox runtime to use (full path to jxrnt/o2rnt.php)

All parameters are "named parameters" and can be passed in any order.

The way to make the call and pass login parameters depends on the interface context you are using:

WEB/HTML

WEB parameters are accepted both in POST and in GET mode, so it is simple to create a link (<a href=''>) in a page, create a .URL file or fill a browser bookmark with a target like this:

http://host/app/app.php?user=userID&password=xxx&dev=supervisor

GTK

Command line parameters follow the name of the application main script, that is the first parameter passed to PHP executable.

Single command line couples of parameters and values must be in the form "<parameter>=<value>", without blank spaces, and they must be separated by one or more blank spaces.

So a command line call with parameters will look like this:

>.../php .../app/app.php user=userID password=xxx dev=supervisor

Command line for direct login can be stored on a system script (Windows BAT/CMD or Linux bash shell) or in a link on your desktop.

Multiple starts, with different purposes, can be created for the same application: for example, you can create a start with "dev" parameter for debugging and one without "dev" parameter for production.

Return to documentation index