Security Provider — Reference

Define a provider whose user lookup, password format and access rules match your application.

Before you begin

• A Server Connect project. For a database provider, an available database connection and a test user table with a stable identity column.

One definition, several authentication actions

A Security Provider defines how users are found and validated and how named permissions are checked. Login, Identify, Logout and Restrict select this provider. Creating a provider alone does not protect every page or endpoint.

Definition and cookie settings

Setting	Meaning
Name / Provider	When editing the provider module, Name identifies the provider configuration. An action selects an existing provider file; the Globals context offers a Provider selector instead. These fields are generated for the current editor context and were missing from the earlier static reference.
Secret Key	The provider secret used to protect remember-me credentials. The editor initializes a random value for a new definition. Keep it server-side and stable for the deployed provider. Changing it affects the ability to read existing persistent login cookies.
Type	Single uses one configured username/password pair. Static uses configured users and permission membership. Database looks users up through a database connection. These are different user sources; switching Type does not migrate accounts.
Username / Password	Shown for the Single provider. These are server configuration credentials, not a registration form or a database of users. Use a disposable pair for demonstrations.
Connection	Shown for Database. Select the database connection that contains the user and permission data. The provider needs the correct connection in each deployment target.
Use Password Hash Verify	Shown for Database. Enable it when the password column contains supported encoded password hashes. Pass the original password to Login. Node.js uses Argon2 verification for a stored hash beginning with $; PHP uses password_verify. Do not assume legacy bcrypt, phpass or custom hashes are portable to Node.js.
Users & Permissions	Configures the source appropriate to Type. For Database, map the users table, unique identity column, username column and password column. Define named permission conditions using the correct identity and table. For Static, configure user entries and their permission membership. A permission name alone does not create an access rule.
Allow Basic Authentication	Allows the provider to attempt HTTP Basic authentication. Default off. This uses incoming request credentials and is distinct from the API Action’s outgoing remote-service authentication. Use HTTPS when enabling it.
Realm	The name used for Basic authentication challenges where the runtime supplies one. It is not a user role, cookie domain or database name.
Domain	Optional domain scope of the remember-me cookie. Omit it for the response host unless a deliberate shared-domain setup is required.
Path	Path scope of the persistent login cookie. Default /. Keep it consistent across login and logout so cookie removal targets the same scope.
Expires	Remember-me cookie lifetime in days; the default is 30. This setting is not a guarantee of an active server session for the same duration and does not override server session-expiry policy.
Secure	Marks persistent login cookies for secure transport when enabled. Check cookies over HTTPS on the deployment target.
Same Site	Choose the cookie’s cross-site behavior: Default, None, Lax or Strict. The installed Node.js provider falls back to Strict when omitted; PHP behavior depends on the saved cookie options. Test the actual browser flow and headers for your target.

Example: a database-backed provider

Use a test users table with id, email and password_hash. Define a Database provider, select its connection, and map id as identity, email as username and password_hash as password. Store an Argon2 hash generated by Password Hash and enable Use Password Hash Verify. Name the provider security. A Login action using security should accept the original test password and reject a different one.

Example: protect an administration action

Define a named permission such as admin using a condition that matches the authenticated identity and your stored role data. Add Security Restrict with provider security and permission admin before the administration query. Test logged out, a normal user and an allowed administrator. Add record-ownership filters separately where the query accepts an item id.

Verify persistence and logout

After a successful Login, call Identify in another request with the same browser session, then Logout and test again. Repeat with Remember enabled. The provider’s persistent cookie is not a plain client-readable role flag; both runtimes use protected credential data and HTTP-only cookie behavior. Check cookie scope and target configuration when login works for one request but not the next.

Limits of the provider check

Single and Static providers do not provide automatic registration or user-table migration. A valid provider identity does not authorize every record. The Database provider checks all requested named permissions; omitted or misspelled definitions do not grant access. Protect both server endpoints and rendered pages where required, and avoid relying on a hidden page button as an access control.

Build the full login flow

Use the working-login guide to connect the provider to an incoming login action and a page form with success and error handling.

Check your result

You can select the correct provider definition, map the user fields, and test identity and permission checks separately.