FusionForge

Difference between revisions of "Developer doc"

From FusionForge Wiki
Jump to: navigation, search
m (Adding a pointer to development environment)
(Added short description of configuration API)
Line 35: Line 35:
  
 
There is a specific admin role given to the project admin, each project creator is by default project admin, he can manage roles for other users, give or remove admin role, design new roles, add/remove users of the group he is admin.
 
There is a specific admin role given to the project admin, each project creator is by default project admin, he can manage roles for other users, give or remove admin role, design new roles, add/remove users of the group he is admin.
 +
 +
= Configuration =
 +
 +
Configuration was previously accessed through a mess of global variables.  This is being deprecated in favour of a (hopefully) clean API:
 +
* forge_get_config(name [, section]): get value of variable "name" in section "section" (defaults to "core");
 +
* forge_define_config_item(name, section, default): define a new configuration item with given name/section and default value;
 +
* forge_read_config_file(file): read a *.ini file and inject its contents into the configuration.
  
 
See also [[Development environment]].
 
See also [[Development environment]].

Revision as of 13:33, 15 March 2010

A few things to know about how the code works. Far from complete.

Internationalisation

i18n in FusionForge is done via the standard Gettext library, with no particular quirks in FusionForge. This makes it a bit unwieldy to use custom/local translations or strings. Lolando has a local branch with code to generate a local translation package that can override the official ones. Need to finish it and commit it to trunk.

Database access

Database queries go through the db_query_params() method (db_query() is being deprecated to help get rid of a whole class of potential SQL injection bugs). This is a wrapper around the PostgreSQL database access methods, which passes the variable parts of a query as separate parameters, removing the need for careful escaping and unescaping. To get the full benefits of that, it is important that the query itself be immutable, and all variable parts need to go into separate parameters. For instance, a query counting the groups with a given word in their name or their description should read:

$res = db_query_params ('SELECT count(*) FROM groups WHERE group_name LIKE $1 OR description LIKE $2',
                        array ($word, $word)) ;

Thus, even if $word comes from a malicious user query, it can't do any harm in the database.

Note that this prevents usage of WHERE foo IN (...) constructs if the number of elements in the set is not constant. Fortunately, we can use an alternative way, with the WHERE foo = ANY($1), with the values built with the db_string_array_to_any_clause() or db_int_array_to_any_clause() methods:

$values = array (1, 2, 5, 8) ;
$res = db_query_params ('SELECT foo FROM bar WHERE col = ANY($1)',
                        array (db_int_array_to_any_clause($values))) ;

URLs and links

As described in FusionForge/Suggestions/URL relocation, URLs to pages in the forges should always be generated by the util_make_url() function. This allows to keep the URL scheme in a single point, so that individual pages don't have to know or care whether the forge runs in its own virtualhost, or on SSL, or in a subset of the URL space within a vhost, and so on.

util_make_link() can be used to generate links rather than just URLs, with extra parameters to add attributes to the <a ...> element in the generated HTML. A use case is to add a class for CSS styling.

Authentication/Permissions

The authentication uses an MD5 password stored in the database by default, but a hook allows to override that with a plugin.

The permission model is RBAC, role-based access control. 'Users' are members of any number of 'groups'. Each membership of a user in a group has a 'role', possibly shared by several users in a group. Each role is specific to a group (no cross-group sharing currently), and it has a set of 'role settings' which are permission bits for the members of the role on the tools of the group.

There is a global admin "role" given to all users member of the admin project, there is no premission control on this user that can add/remove all permissions he wants

There is a specific admin role given to the project admin, each project creator is by default project admin, he can manage roles for other users, give or remove admin role, design new roles, add/remove users of the group he is admin.

Configuration

Configuration was previously accessed through a mess of global variables. This is being deprecated in favour of a (hopefully) clean API:

  • forge_get_config(name [, section]): get value of variable "name" in section "section" (defaults to "core");
  • forge_define_config_item(name, section, default): define a new configuration item with given name/section and default value;
  • forge_read_config_file(file): read a *.ini file and inject its contents into the configuration.

See also Development environment.