A node may define a number of properties as credentials
. These are properties
that are stored separately to the main flow file and do not get included when
flows are exported from the editor.
To add credentials to a node, the following steps are taken:
Add a new credentials
entry to the node’s definition:
credentials: {
username: {type:"text"},
password: {type:"password"}
},
The entries take a single option - their type
which can be either text
or
password
.
Add suitable entries to the edit template for the node
<div class="form-row">
<label for="node-input-username"><i class="icon-tag"></i> Username</label>
<input type="text" id="node-input-username">
</div>
<div class="form-row">
<label for="node-input-password"><i class="icon-tag"></i> Password</label>
<input type="password" id="node-input-password">
</div>
Note that the template uses the same element id
conventions as regular
node properties.
In the node’s .js
file, the call to RED.nodes.registerType
must be updated
to include the credentials:
RED.nodes.registerType("my-node",MyNode,{
credentials: {
username: {type:"text"},
password: {type:"password"}
}
});
Within the runtime, a node can access its credentials using the credentials
property:
Within the editor, a node has restricted access to its credentials. Any that are
of type text
are available under the credentials
property - just as they are
in the runtime. But credentials of type password
are not available. Instead,
a corresponding boolean property called has_<property-name>
is present to
indicate whether the credential has a non-blank value assigned to it.
Whilst the credential system outlined above is sufficient for most cases, in some circumstances it is necessary to store more values in credentials then just those that get provided by the user.
For example, for a node to support an OAuth workflow, it must retain server-assigned tokens that the user never sees. The Twitter node provides a good example of how this can be achieved.