Search results for "User"

There are three main properties you can change to control the two factor authentication behaviour for a specific user node.

The Users and Groups tab has two subsections: The left section lists all system users that exist in the database. Users can be created by clicking on the "Add User" button on top of the list and deleted by clicking on the delete button which appears when you hover over the user element.

A user’s attributes like name, eMail or password can be edited via the Edit Properties dialog. Here a user can be given admin permissions by activating the isAdmin flag.

In the section on the right, user groups can be created and managed. Groups can contain users and other groups which can be added and removed via drag-and-drop. This allows the creation of a group hierarchy and thus a very flexible and versatile security system.

The About Me section displays information about the user that is currently logged in to the system.

In addition to these information, Structr also stores the UI preferences of the logged-in user. They can be reset by clicking on “Reset stored UI settings”.

This part of Structr’s backend UI is the place where the entry points of Structr’s HTTP REST Service can be configured.

While the security system of Structr is focused on users and their security context (i.e. does the user has access to a given database entity?), the checking of resource access grants is focused on the URL path (the resource) of an HTTP request.

More precisely, if a user requests all entities of a given schema type via Structr’s REST interface with a call to the URL /structr/rest/SchemaType, Structr will check if the user is logged into the system and if a GET request on the resource /SchemaType is permitted for authenticated users. If the user is not logged into the system the GET permission for non-authenticated users has to be set for that resource.

Only when the permission for the resource is set, Structr will then check if user has grants for the actual database content and the entities of the type SchemaType.

When the user accessing a node is no admin user and the first check didn’t return, Structr will check the two flags visibleToPublicUsers and visibleToAuthenticatedUsers on the data nodes themself. The flag visibleToPublicUsers makes a node visible to all users, both to those who are authenticated and the non-authenticated ones. The flag visibleToAuthenticatedUsers only makes a node visible to authenticated users.

In the above example, the schema is configured in such a way that users with the maintains relationship to a ProductGroup will have access to any Product object in the group they maintain, but not to the subgroups of the given group.

Schema relationships that are configured to allow domain permission resolution are called active relationships. Active relationships are displayed in a different color than normal relationships in the schema editor.

When a non-admin user accesses a private object (e.g. a Product node from the above example schema), Structr tries to find a path which ADDs the requested right or KEEPs the requested right from a node the user has the specific right on.

In detail: We assume that a user who has a read permission grant to a ProductGroup tries to access a Product contained in that group (for which the user does not have direct rights).
Structr will then traverse the active relationship(s) until a path is found which ADDs or KEEPs the requested right.

Successful path evaluation:

• The (ProductGroup)-[:contains]->(Product) relationship is configured to keep read and write
• The effective permissions at the end of the evaluation process are read and write

Unsuccessful path evaluation:

• If a user who has a read permission grant to a product that is not contained in the product group he has access to, but in a subgroup of the given group, Structr will not be able to find a connected path of active relationships and will fail the permission resolution.
• The user does not have any permission grants set on any node or only visibility flags are set on the data nodes.

The Cascading Delete settings allow configuration of what happens when either end of the relationship is deleted. The possible values are explained in-depth in the help popup in the dialog.
Automatic Creation of Related Nodes configures if it is allowed to include nested nodes in a REST POST request for this relationship. A node with the given property set is automatically created and linked to the node. If the nested node contains an id attribute (or another property marked as unique) a node is searched for that property and linked if found.

Permission Resolution allows configuration of rights propagation in the graph. If NONE is selected, no rights propagation is applied for this relationship. If SOURCE_TO_TARGET is selected the rights are propagated along the relationship direction to the next node. For TARGET_TO_SOURCE the rights propagation is works against the relationship direction. For ALWAYS the direction of the relationship does not matter and rights propagation is always applied.
Specific rights (Read, Write, Delete, AccessControl) can be added, kept or removed according to the propagation configuration. If a user has read rights to the previous node and Read is configured to Keep, the user also has read rights for the next node. (Specific User/Group rights are applied before using permission propagation - i.e. if a user has specific rights configured for a node, permission resolution is not evaluated as user rights are more specific).
Along the way of permission propagation, properties can be hidden in order to hide sensitive information from users who get rights from permission propagation. The property names can be separated by comma , or space character.

There are 3 tabs where the functionality of the type can be configured:

• Local Attributes
  A Custom Type can be extended with dynamic properties to provide the data model for the intended use-case. This list contains all local properties (meaning they are defined on this type directly).
• Views
  The properties of a type can be combined into named Views, which are accessible under an individual REST URL. Access to these URLs can be configured independently for each HTTP method using Resource Access Grants, which makes them an ideal tool to create specialised endpoints for different client applications (e.g. mobile clients etc.).
• Methods
  There are different kinds of methods - callback methods and entity methods. Callback methods are automatically executed by the framework upon certain lifecycle events and have a strict naming convention. Entity methods are called by the user/programmer.
  Entity methods are not automatically run by the framework and must be called manually. This either means making a POST request to /structr/rest/(Type)/(<a data-id="7c9c8218bced42bab66868373e64d885" class="mention">UUID</a>)/(methodName) or in serverside JavaScript as node.methodName();

The SECURITY relationship can have different combinations of permissions in its allowed attribute:

Instead of creating users in the Structr backend manually in the Users and Groups section of Structr’s admin UI, you can allow users to sign-up/self-register. The registration process uses double-opt in by default. All you need is a simple page where new users can enter their e-mail address so Structr can send them an e-mail with a confirmation link.

The following pre-defined MailTemplate keys can be used to configure the self-registration process. In version 4.0 they have been renamed to have a more uniform structure.

Note: The Mail Configuration Settings have to be done for self-registration mails to be sent.

Notes:

• The visibility flags of these MailTemplates are ignored because the self-registration mail is created as a privileged user.
• A special link variable is provided for the TEXT_BODY and HTML_BODY templates and can be output with the usual syntax: ${link}
  • Example link: https://support.structr.com/confirm_registration?key=<CONFIRM_KEY>&target=/dashboard&onerror=/register-error
• From v4.1 scripting is enabled in two templates: CONFIRM_REGISTRATION_TEXT_BODY and CONFIRM_REGISTRATION_TEXT_BODY. The script is being run in the context of the user (me keyword points to the user).
• In any version prior to 4.1 scripting can not be used and simple text replacement is done

The self-registration should be done via the registration resource. It is available under /structr/rest/registration.

An un-authenticated user can issue a HTTP POST to that resource to begin the registration process. The accepted input attributes are configured in the configuration registration.customuserattributes. eMail is always supported and often used as a single attribute for registration.

The registration is then started by the user by making a HTTP POST request (via a signup form) to /structr/rest/registration with the following body:

fetch("http://localhost:8082/structr/rest/registration", {
  method: "POST",
  body: JSON.stringify({
    eMail: "user.name@mail.com"
  })
})

The self-registration process would then send a mail using the above templates.

Notes:

• A resource access grant must be configured for public users to allow the POST method to the grant with signature _registration
• jsonrestservlet.user.autocreate must be enabled in structr.conf to enable automatically creating users