Search results for "link"

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

To allow users to regain access to their account when they forgot their password we need to enable them to reset their password.

Note: The Mail Configuration has to be done for password retrieval 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/reset-password?key=<PASSWORD-RESET-KEY>&target=/reset-password
• From v4.1 scripting is two templates: RESET_PASSWORD_TEXT_BODY and RESET_PASSWORD_HTML_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 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();

This type-awareness is also available for the remote properties of the entities in the graph database. Entities (or nodes in the graph database) can be linked in the table by clicking on the “+” icon in the cells and selecting the node that should be linked.

You can define directed edges between node types and annotate then with a name and cardinality (1:1, 1:n, n:m). Structr uses the structure defined by nodes and relationships as a blueprint for the datastructures in the database. It also takes care that the data is consistent by preventing the creation of invalid structures. In a 1:1 relationship for example, an object can only ever be linked to exactly one other object. If another object is assigned, the previous relationship will be removed. Structr also maintains the type safety of related objects by allowing only those types to be linked to each other that match the schema.

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

In our structr instance we navigate to the data section and select the type MQTTClient.

We create a new object with the following attributes (the default settings for RabbitMQ)

mainBrokerURL = 'ws://localhost:15675/ws'
username = 'guest'
password = 'guest'

Afterwards we check the isEnabled checkbox which triggers the client to connect to the server. If everything is configured properly it will blink green - otherwise it will blink red and result in an error.

Then we select the type MessageSubscriber and create a new MessageSubscriber with the following attributes:

topic = '*'
callback = "{ $.log($.topic, ': ', $.message) }"

This instructs the subscriber to listen to any topic and simply log the messages to the server log. We could also forward the messages to any global schema method - for example handleIncomingMQTTMessage like this:

{
  $.call('handleIncomingMQTTMessage', { topic: $.topic, message: $.message });
}

There are 5 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>/<UUID>/<methodName> or in serverside JavaScript as <node>.<methodName>();

• Remote Attributes
  Custom types can be linked to other types, including base types. Structr will automatically create Remote Attributes on either side of the link, which can then be used to create, update or remove the relationships between instances of the two types. In this tab the configuration of the remote attributes can be viewed and edited. The names configured here are used throughout the application to refer to the other side of the relationship(s).

• Inherited Attributes
  The content of this tab is of informative character. All inherited attributes are shown with an information from where it was inherited.

The reset password process should be done via the reset password resource. It is available under /structr/rest/reset-password.

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 reset password process is then started by the user by making a HTTP POST request to /structr/rest/reset-password with the following body:

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

The reset password 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 _resetPassword
• the configuration setting JsonRestServlet.user.autologin must be set to true to enable auto-login with the link in the email
• the link in the mail is only valid once