User profile development

User profiles define areas of the database available for access for groups of users. Conversely, you may think of profiles as defining areas of the database which users are prevented from accessing. By setting up user profiles, you can limit the amount of data that users work with, and protect sensitive financial or sales information you don't want to be generally known.

The DbNet system will stricly enforce the restrictions you place on the database. The client program will alter its display and behavior in accordance with the restrictions set on the server. Fields to which the user is prohibited access will not be shown on the client, and fields which are read only on the server will be displayed as read only on the client.

Restrictions

User profiles are built around the concept of restrictions. Initially, all areas of the database are accesible, there are no restrictions. The system has been designed this way so that you can get started using the system without being hassled with setting up database permissions before you have even learned to use the system. As your use of the system becomes more sophisticated, you can add restrictions to user profiles and allow more people in your office onto the database.

Restrictions are associated with fields in the database. Database fields correspond to data entry fields on the screens on the DbNet program. You can set a field to be read-only, hidden, or to be restricted by a data filter. Once you have set the restrictions, you tell the system to build the user profile and instruct the server to start enforcing it. Users added to the system under this profile will then be constrained by the conditions you have set.

Server enforcement of restrictions

Many traditional data systems have security features built around the concept of permissions. In that model, all fields must be explicitly allowed permission in order for a user to access them. In the DbNet system, the opposite approach has been taken, in that all fields are allowed access, and users must be explicitly prevented from accessing them in order to be denied access. The DbNet system was designed this way because it more closely resembles the decision process that managers make when deciding what access to allow to information.

It is important to note, however, that the DbNet approach to security as restrictions rather that permissions is merely a GUI device for the benefit of the manager setting user profiles. The actual decision to allow or deny access by a client to the database is still permission based. The DbNet system will review the user profile restrictions and convert them into a permission based rule set used by the server to enforce access to the database.

The conversion of the user profile from a restriction based model to a permission based model takes place when the Update Server File button is invoked on the Profile Screen. The system will perform an analysis of the restriction settings of the profile and build a permission based profile on the server for enforcement.

Administrator profile

An Administrator profile allows full access to all areas of the system. There must always be an Administrator on the system so someone may perform critical maintenance operations. The only relevant setting for an Administrator is the Administrator Priveleges check box on the profile screen. This setting will allow the user to completely bypass all security mechanisms on the server.

Default user profile

The DbNet system comes with a default user profile setting. This profile is not intended to be deployed for actual users on the system, but rather as a baseline profile from which working profiles may be built. The proper course of action is to copy the default user profile to a working profile which is then built up for a particular user group.

The default user profile contains the baseline restrictions that would prevent a user from accessing those parts of the system which would allow then to alter the system in such a way as to gain access to parts of the database to which they do not have permission. For exmaple, if users were able to access their own profiles, they could give themselves permission to database areas that you did not want them to have.

File permissions

The DbNet system requires access to files on the server in order to function properly. Most important is the program.jar file which is the executable code used by clients. The clients check the version of the program.jar file on the server, and then verify that they have the correct version on the local machine. This is the mechanism by which the system maintains proper version control on clients. If the client finds that it's version does not match the server version, it will update itself by downloading the program.jar file.

Another example of file access is the picture files associated with inventory items. These files are stored on the server and downloaded by clients when viewing item screens. Clients may set the picture for an item.

User profiles must explicitly allow access to files in order for the server to process requests. The default user profile is set with the minimum permissions needed for system function.

Pass through queries

Requests for database information made by the client to the server are in the form of Structured Query Language (SQL) transmissions. The server will analyze the SQL stream from the client to verify that it is requesting information which is allowed by the user profile. In some cases, however, the client may legitimately request information which does not conform to a strict interpretation of the user profile permission rules. In these cases, the designer may set a pass-through query that is allowed to bypass the SQL checking mechanism of the server.

Filter restrictions

The DbNet system has a special form of restriction called a filter restriction. This type of restriction can be used to segregate database information based on a quality of the data set in a field rather that on the field itself. The basic idea is to allow access to some of the data in a table based on a setting in one of the fields so that multiple parties with different interests can use the same database without viewing or altering each other's information.

Perhaps the best real world example of this type of restriction would be a database of sales orders made available to a group of sales reps. Each rep would be able to access their own orders, but would not be able to see any other rep's orders. Each of the rep's profiles would have a filter set on the Sales Order table for their own office.

The image below shows an example spreadsheet of the Sales Orders which is not restricted in any way. There are orders from two different offices, Wholesale Widgets Inc. and Yellow Dog Sales.

If you wanted to set up a profile for Yellow Dog Sales so that they could view and edit their own Sales Orders without having any access to other sales orders, you would set a filter on their profile.

Now when Yellow Dog Sales log into the system, they will see only their own orders, and will have no access to any other orders on the system.