Access rights

Access levels

Access level in Smereka is very simple. This is a number from 0 to 255, which determines the degree of secrecy of this node. User can see the node only if his access level is not lower than the node access level. User access level is determined by a group to which he belongs. Node access level is determined by the site editor of the site and stored in the node attribute accesslevel.

Anonymous user on the Internet obtain a default access level 5. So, pages with access level 0..5 are for general use.

The logic of secrecy suggests that access levels will increasing from the root of the tree to the terminal nodes. That is the most secret node must be the deepest immersed in a tree, have the highest hierarchical level. But for some reason the site may have "islands" of public accessible pages as children of secret node. They can act as semi-secret – if the user knows their URL, he can see them, but they are not available through standard Smereka navigation mechanisms.

Smereka page designer must choose whether to notify the user about the existence of subordinate pages with a higher level of access. Such notification may be useful, for example, for paid access to information.

Assigning of access levels

When adding a new top it automatically gets access level of the parent node. Often this is what we need.

Of course, the editor can not assign for a node access level higher than that he has by himself (ie can not hide node from himself).

Access blocking

Smereka administrator can determine what should happen if the user does not have access to a web page. The reaction is determined by AccessBlock attribute for the subdomain, in the context of which blocking occured. Preset values are:

403 – send code 403 (Forbidden) by HTTP protocol definition and create a page explaining the blocking reasons. This response means that Smereka recognizes the existence of the page. This value is used by default.

404 – send a 404 (Not found) HTTP protocol code and create a page with the message that the page does not exist. This response means that Smereka denies the existence of the page (this can be more convenient for secret pages, as the existence of which is secret too).

Custom – function CustomAccessBlocking will be called. This function must determine a reaction to the situation. By default, it returns a 403 code.

Silent – make internal redirect to subdomain root page (best when it is not necessary to scare the user with error messages).

User rights

Anonymous user have only one right – to see public pages available to your site, using the features that they provide (eg, buying something in online store or sending a message through the feedback form).

Registered user acquires rights described in the group to which he belongs (or rather, his account belongs). He always has the right to view pages with the access level 0 .. $MaxPublicLevel. All other rights (add / change / delete something, etc.) are valid only within the group influence zone.

Group is a node of a special class designed for access rights management. Groups form a separate Smereka hierarchy. A group can contain other groups, users and links to the administration zone. Group influence zone is a set of administrative zones. Group, which does not contain any administrative zones, has no influence (in direct and figurative sense): members of such group have nodes, for which they can apply their rights.

Hierarchy of groups begins with a global administrators group (by default it is named Administrators). This group provides users with all the rights that only exist in Smereka. By default, a user named Admin and one administrative zone which covers all the tree created in this group. Therefore the membership in this group entitles you to manage all objects of Smereka.

Administrator in Smereka known anyone who has the right to add / delete / modify administration objects, ie, groups, users and zones. The administration applies to all objects of the group, which belongs to the administrator, and all subordinate objects. The administrator can view the properties of his group, but has no right to change them – to do this one must belong to higher administrator level. This implies that properties of the global administrators group can not be changed (and there is no need to do this!).

Having relevant rights granted, the administrator can create new groups, subordinated to his own group, and delegate rights to them. The general rule is that an administrator can not delegate more rights than he has by himself, but he can reduce these rights. Thus, the group rights narrowing from global administrators group to more specialized groups. But it should be understood that the group does not inherit any properties from a parent group. In particular, the influence zone is determined for each group by itself.

Determining the group rights, administrators must remember that within Smereka the right CanModify* is more important than rights CanCreate* and CanDelete*. The user must have the right to change some objects to get an access to editor of these objects, where the creation / deletion commands are available.

Administration zones

Administration zone created with any Smereka node by adding two attributes: ZoneId, ZoneMask. These attributes are hidden and inaccessible to the node editors. Only administrators who have rights over the zones can see these values. Zone is the crown of such node.

Inside the administration zone, one can create other administration zones, provided that their zone ids will meet the mask area of the parent zones (ie ZoneId AND (NOT ParentZoneMask) == ParentZoneId). Clearly, the zone with zero mask (terminal zone) can not contain any nested zones.

By default, only one administration zone created. It is associated with the root node in Smereka hierarchy and has ZoneId = 0, ZoneMask = 0xFFFFFFFF, that absorbs all other administration zones.

Zone management is complex operation that requires precise planning and a clear awareness of possible side effects.

New zone can be created possible everywhere, except the terminal zone. New zone id must comply with the zone mask active in this context. After creating the new zone spreads to all of its crown. If this crown contain some sub-zones, they remain unchanged, provided that they comply with the mask of the newly created zone, otherwise these zones are removed, and all their nodes included in the newly created zone. This cascade deletion of zones may have undesirable consequences for groups that use these zones.

After zone deleting all its nodes enter to the parent zone. Sub-zones remained unchanged.

If one change the zone settings, an creating new zone algorithm is used to create a new zone with new parameters. Thus, the expansion of the zone mask is safe, its narrowing – potentially dangerous, and id changing – certainly dangerous. Consider the next examples.