Web application development these days is a very common task but not always could be solved in an easy way. Especially when we are talking about a fully functional dynamic web application with an unlimited number of pages, as well as the ability to withstand the high performance in projects of this kind. The use of general-purpose programming languages for implementing the logic of the server side has a large entrance threshold, and traditional CMS and frameworks do not provide sufficient flexibility. The most correct solution in such situation would be to use DSL-like languages, which are easy to use and at the same time have extensive capabilities due to the fact that they are pre-oriented for solving domainspecific problems. However, at the moment there are very few ready-made solutions. Most known of them is WebDSL, but despite its purpose it has a number of disadvantages inherited from the implementation language of this project -- Java, such as, for example, little flexibility, high performance costs and the need to install a Java machine. The development process was carried out using a relatively low-level general-purpose programming language C++ that resolved the problems faced by competitors, ensured high performance of the interpreter and cross-platform nature of the entire system. The authors described in detail the chosen permissions meta-management tools of the BlockSet project, as well as the syntax of their application in the declarative highly abstract domain-specific language BML (BlockSet Modeling Language), using simple and accessible examples to demonstrate the concise, but expressive syntactic solutions. The obtained results can significantly simplify the further process of administering a web resource and it's also one of the main features of the BlockSet project. Thus, the BML language, coupled with the permissions system, provides flexible, powerful, and at the same time quite simple and understandable methods for organizing the necessary system configuration, which corresponds to the project paradigms of flexibility and low entrance threshold, and also significantly optimizes the development process.
The use of general-purpose programming languages for implementing the logic of the server side has a large entrance threshold, and traditional CMS and frameworks do not provide sufficient flexibility. The most correct solution in such a situation would be to use DSL-like languages, which are easy to use and at the same time have extensive capabilities due to the fact that they are preoriented for solving domain-specific problems. However, at the moment there are very few readymade solutions. When studying existing solutions, WebDSL turned out to be the closest to BlockSet in functionality, but it has a number of disadvantages inherited from the implementation language of this project -- Java, such as high-performance costs and the need to install a Java machine.
The BlockSet project compares favorably with competitors, solving the problems described above
without loss of flexibility and performance and provides tools for implementing each of the stages of
creating dynamic web applications. The most basic of such tools is the declarative, high-level,
domain-specific language BML [
In addition to the tool for describing the logic of the server side, the BlockSet project also provides
a flexible permissions meta-management system, it is important to provide the user with the
opportunity to implement the system in such a way that for each user from whom an http request
comes, the permissions for each information fragment in the database are strictly defined. This
problem has already been raised in [
The main goal of BlockSet architecture is to provide simple, easy-to-use and limited number of entities. The idea is to make possible to work with it without providing additional attributes and properties for the entities. The developer will provide qualifying attributes later if it necessary. So, it’s strictly satisfied the requirements of declarative and domain-specific principle where we are already have some entity and we could work with it “from the box”. Thus, the developer who is just trying to learn something about BlockSet could achieve the milestones step-by-step by using additional attributes which makes the result project is flexible and more complex.
For a more understandable presentation, in the future, it is necessary to describe in general terms the main architecture of the BlockSet project and the entities it operates with. At first it is necessary to define the BlockSet in general. BlockSet is a web applications development toolkit. It provides a stack of technologies that can be collated to the common ones used everywhere for such purposes (figure 1).
In the common development of a dynamic web application, the obvious solution is often to write the logic of rights as part of the server side itself, that is, such code will be written in advance, taking into account the specifics of the application being developed, it will have the capabilities, the need for was described in advance. The difficulty of developing such a system for such a project as BlockSet is conditioned by the fact that requirements are not known in advance, and given the paradigm of the flexibility of this project, it is necessary to take into account all, or almost all, possible requirements for creating such systems and create tools for their implementation. 2.3.
Permissions verification is performed on the server side, which complies with data security principles. At the entrance from the client, the server receives two blocks of information. First of all, this is a request for an operation that the user wants to perform with some data in the database. The data itself transmitted by the client is actually just the value of some variables that are used in the algorithm of actions with the database described using the BML language on the server side. For example, a username can be transmitted from a client, which will be used as a selection criterion for obtaining the age that we want to receive, but the transfer of a login in order to find a user by login will not lead to success, since the selection is described in the location exactly by the username, and not by his login (figure 2)
In addition to the attribute values, the client also transmits the session key [
This system is a specialized database configuration by different kind of permissions: for each cell
(except for the primary key), in addition to the piece of information itself, users' permissions for
CRUD operations (create, read, update, delete) [
Almost any permissions system is based on such fundamental concepts as users and groups. Groups are needed to manipulate the permissions of several users at once, since it is not best practice to separately determine the permissions of each individual user, but such a possibility is still present in the calculation for cases when it is really necessary.
To store groups and users in the database, the corresponding system entities _groups and _users are used, as well as the connecting entity _groups $ _users, which describes the belonging of each user to one or another group. It is important to mention that each group has such a parameter as priority. Of all the groups in which the user is a member, group permissions with the highest priority will be applied first to determine the actual rights. Groups are of three types: system, static and scoped.
The logic of system group processing is predetermined. The functionality of adding new groups of this type is not provided, since their logic is closely related to web entities that are not defined at the BML level. These groups include: all applies to all users, but has the lowest priority users applies to all authenticated and authorized users сreator applies to the user initiating the creation of the current row in the database
A user's membership in such a group is determined only from the strictly specified presence of a user in this group in a _users$_groups table.
Membership in a group of this type is determined separately for each scope. A good example of implementing a group of this type is the obvious implementation of the forum_moderator group. Implementation of such a group will provide to its members the opportunity for special operations in a whole subtree of topics and messages of this special one forum (figure 4).
The differentiation of permissions by operation type is carried out between four main generally
accepted operations: create, read, update, delete, abbreviated as CRUD [
Access rights are a priori associated with data, and data are stored in the database, therefore, within
the framework of this article, various types of rights will be described based on the database entities to
which they refer. To solve the problem of flexibility, stored permissions are located directly in the
database itself in such a way that each piece of information can be associated with a separate set of
permissions. To store such a complex structure, the PostgreSQL DBMS, which is gaining popularity
in recent years, is used, which, by means of composite data types [
The BlockSet toolkit provides two types of permissions. These include local and remote. Local permissions are stored in the database per each entity, while the remote ones resolved by referencing to the permission-interface blocks in the same on another database table. They can be very useful to grant some set of users the availability to determine users activities permissions on something. (figure 5)
Local permissions for attributes are a set of permissions for a user or group in the following format: unit:ru, where unit is a user ID or group name, r is the ability of the specified unit (user or group) to read the attribute, and u is the ability to change it. r and u can take the values y, n or -, which respectively declares allow, deny or inheritance for corresponding operation. For example, the line @users: nn will prevent the registered users group from reading and changing the selected attribute, and the line 355: y- will allow the user with ID 355 to read the data, but the ability to update will be inherited from the lower priority rule.
Remote rights for attributes are a collection of links. Each link must point to an interface cell, from which static rights will be taken, which will be applied to the attribute data. This links are not stored in the database in order to maintain sets structure consistency. 3.5.
Local permissions for tables are a set of permissions for a user or group. The logic of their work corresponds to the logic of work of local permissions for attributes, but unlike them, the rights here use a full-fledged crud and have the format unit:crud. r defines the ability to select rows, u defines the ability to modify them, when c and d define the ability to create and delete, respectively. Such permissions are stored in a special table, where a row is provided for each other table, local rights are required for.
Remote permissions for attributes are a collection of links. The logic of their work is completely similar to the logic of the remote permissions for attributes, however, the storage of such rights is implemented in the same way as the storage of remote permissions for attributes. 3.6.
Local and remote permissions for one-to-many and many-to-one relationships are implemented in the same way as for attributes. But in this case, the permission target is the table's foreign key. Only have read and update permissions. In the case of a many-to-many relationship, the programming logic of such rights is a special case of rights for tables, since the rights to join tables are stored alongside the permissions to other tables.
The permissions for a particular block are stored directly in the database, as described above. The task of the BML language in this case is precisely meta-management, that is, the providing of environment for convenient permissions system implementing and managing. We are talking about default permissions, i.e. permissions that should be automatically set for a particular block or set during its creation, as well as on the generation of interface blocks. For example, a popular solution would be to declare the posts_interface block in the _users set and provide the appropriate user with the necessary permissions to edit this block, as well as assign default rights to all posts, which will be represented by links to the block user interface on whose page it is located. Thus, the defined system will allow the user to edit the permissions for posts on his profile page.
In the example above, there are seven main BML permissions meta-management tools that must be implemented: Interface block definition tool Attribute default local permissions definition tool Attribute remote permissions definition tool Table default local permissions definition tool Table remote permissions definition tool Relation default local permissions definition tool Relation remote permissions definition tool
Also, for the functioning of local permissions and convenient manipulation of them, it should be possible to create scoped groups and indicate which sets belong to them. Thus, to the list of required funds are added: Scoped groups definition tool Scope membership definition tool
For clarity, we will consider tools using the example of a set of users _users, which has several blocks and belongs to the sets games_rates and games_reviews with an one-to-many relationship (figure 6) 4.1.
The tool for interface blocks definition is represented by a tool whose syntax is similar to the syntax for describing other blocks (Fig. 1). In the model, a block must be declared inside the required set. We must specify the desired block name as the value of the name attribute, and the block type grants as the value of the type attribute. If necessary, define the default imported permissions (those that will be generated upon creation). The ability to set the permissions to operations with the block itself, both local and remote, is also implemented, as well as for any other block, it will be discussed below (figure 7).
Due to the fact that the functionality of these tools partially overlaps (for example, when creating a scoped group, you must specify a set that is the root of the scope), it was decided to implement them within one tool: to work with groups, the set attribute groups is used, within which, it is necessary to indicate the scoped groups it belongs to, separated by a space. In this case, it is also necessary to indicate the name of the relation with another set belonging to the specified group. If a set needs to be made root of a scope, the root keyword should be used instead of the relation name. Thus, the host@root entry in the groups attribute of the _users set will create the host scoped group (the profile owner) and make the _users set root within its scope, and the host@rater entry in the groups attribute of the rates will indicate that the rates set is a part of the host scope and is attached via the rater relation (figure 8).
The definition means for local permissions for attributes, tables and relations is presented in a laconic and convenient tool: for the necessary block, set or relation, it is enough to define the value of the grants attribute, which must be represented by a line that includes local permissions listed in the format for a set or block separated by a space respectively. The format is as follows: first, the name of the group, the permissions are defined to, specialized, and then the necessary permissions are indicated after the colon. Each permission is a letter (c, r, u, or d) and the permission value itself is “+” for allow permission, “-” for deny, and “~” for inheritance. Moreover, for blocks and links, only the letters r and u are allowed, and for sets - all four (figure 9).
The means for defining remote permissions for attributes, tables and relations are represented by a similar tool, but instead of the grants attribute, you need to work with the links attribute in this case, in its value you should also specify links, separated by a space. Each link works only within the specified scope. This restriction allows us to significantly simplify the syntax since there is no need to specify the path to the interface and all that remains is to specify the scope name and interface name due to the fact that the hierarchy of sets within the scope has already been established using the tool for specifying scoped groups. Thus, each link is a zone-interface pair separated by a colon. When parsed and stored in sets structure, links have a slightly more complex syntax and structure, allowing, on their own, to carry out independent transitions without unnecessary operations. Remote permissions have the lowest priority, so only those permissions that have received inheritance status at the lowest priority of local permissions will be calculated based on them. Thanks to such a hierarchy, it becomes possible to use local permissions as a mask for remote ones, limiting the ability of the user to regulate rights (figure 10).
The design of the permissions metamodeling is the essential part of any project based on domainspecific and model-driven principles which processing a data based on different criteria. It’s important to provide easy-to-use and at the same time flexible abstract system of permissions handling. As the whole project BlockSet permissions system provides high-abstract and declarative syntax implemented in BML language.
Ensuring information security is an integral part of the development and administration of a web application, for the organization of which it is necessary to spend a significant amount of time and effort, as well as to have the necessary knowledge and development experience using the appropriate low-abstract general-purpose programming languages.
Thanks to the work done for the BML language, it was possible to design tools for metamanagement of access rights, that is, tools with which the possibility of creating a system is realized, within which it will be possible to configure access rights for a specific web application. During the design and development, it was possible to comply with the principles of the BlockSet project about flexibility and a low threshold of entry. 6. References