authenticationMethods¶
Path: authenticationMethods > {MethodName}.
api¶
booean
Defines that the method is to be used for pure API request, not from the front-end.
credentialsHeader¶
string
As of v7.3.
A header that is supposed to contain credentials. Actual only for API methods.
login¶
As of v7.3.
A framework providing the ability to call custom code on Sign-In button click on the login page.
{
"login": {
"handler": "my-module:handlers/login",
"fallback": true,
"data": {
"someKey": "someValue"
}
}
}
Parameters:
- handler – a front-end class (should extend the abstract class
handlers/login
). - fallback – defines that a regular username/password login method is also available on the login page.
- fallbackConfigParam – a config parameter name to be used to check whether fallback login is allowed.
- portal – whether the handler will be available for portals, (bool).
- portalConfigParam – a config parameter name to be used to check whether the handler will be available for portals.
- data – arbitrary data to be passed to the handler. Can be actual as application metadata is not yet available on the login page.
The handler class should have a method process that returns a promise that resolves with HTTP headers. These headers will be sent to the back-end to the App/user
endpoint.
The label for the Sign-In button can be defined in the language at signInLabels
> {MethodName}.
Compatible with 2FA.
On the login page only global config parameters are available. When implementing a custom login, consider having some global config parameters to access in the handler.
settings¶
Defines config parameters and a form on the admin UI. See application/Espo\Resources/metadata/authenticationMethods/LDAP.json
as an example.