The product supports logging in programmatically by supplying login credentials which come from external application. In some cases, however, that approach might be not suitable, typical case is when WebMail Lite and external application run on different servers.

There is another way to log user in, it's done by sending POST data to WebMail Lite. Data can come from HTML form, from JavaScript application, etc.

Configuration

For security reasons, this option is disabled by default. You can enable it by setting AllowPostLogin to true in data/settings/modules/Core.config.json file:

    "AllowPostLogin": [
        true,
        "bool",
        null,
        "If set to true, credentials can be submitted via POST request" 
    ],

Then you can submit POST requests to WebMail Lite, with ?postlogin appended to its URL.

Login or Email parameter sent in POST request is used for authentication, along with Password parameter.

Usage example

The simplest way to test this approach is to have a basic HTML form which contains the login details:

<form action="http://yourdomain.com/webmail/?postlogin" method="post">
Email: <input type="text" name="Login"><br>
Password: <input type="text" name="Password"><br>
<input type="submit" value="Login">
</form>

Using GET requests

While using POST is usually convenient, we've added GET support as well. So you can direct user to URL of the following kind:

http://yourdomain.com/webmail/?postlogin&Email=test%40user.com&Password=12345

Note that parameters here need to be supplied in URL encoded way. For example, if email is test@user.com and password is 123&45, URL would look like:

http://yourdomain.com/webmail/?postlogin&Email=test%40user.com&Password=123%2645

Naturally, it's less secure compared to POST as credentials are visible in URL. Still, that might be an option in some cases.

Cross-domain iframe cookies

Passing credentials via POST/GET should work even if your application and WebMail Lite are in different domains. But in some cases, for example when Iframe is used, you may run into an authentication issue as some browsers are now enforcing SameSite cookie policy; so when setting cookies in the code, SameSite attribute must be explicitly set.

Currently, we can't add such an attribute in our code, as it's only possible as of PHP 7.3. But you can correct the issue on your installation by replacing the following code in modules/Core/Module.php file:

@\setcookie(
    \Aurora\System\Application::AUTH_TOKEN_KEY,
    $aResult['AuthToken'],
    \strtotime('+' . $iAuthTokenCookieExpireTime . ' days'),
    \Aurora\System\Api::getCookiePath(), null, \Aurora\System\Api::getCookieSecure()
);

with:

$aCookieOptions = array (
    'expires' => \strtotime('+' . $iAuthTokenCookieExpireTime . ' days'),
    'path' => \Aurora\System\Api::getCookiePath(),
    'domain' => null,
    'secure' => \Aurora\System\Api::getCookieSecure(),
    'samesite' => 'None'
);
@\setcookie(
        \Aurora\System\Application::AUTH_TOKEN_KEY,
        $aResult['AuthToken'],
        $aCookieOptions
);

You will also need to make a similar modification in statis/js/app.js file, locate the following code in it:

return (document.cookie = [
        encode(key), '=', stringifyCookieValue(value),
        options.expires ? '; expires=' + options.expires.toUTCString() : '', // use expires attribute, max-age is not supported by IE
        options.path    ? '; path=' + options.path : '',
        options.domain  ? '; domain=' + options.domain : '',
        options.secure  ? '; secure' : ''
    ].join(''));

and adjust it as follows:

return (document.cookie = [
        encode(key), '=', stringifyCookieValue(value),
        options.expires ? '; expires=' + options.expires.toUTCString() : '', // use expires attribute, max-age is not supported by IE
        options.path    ? '; path=' + options.path : '',
        options.domain  ? '; domain=' + options.domain : '',
        options.secure  ? '; secure' : '',
        '; SameSite=None'
    ].join(''));

You'll need to set UseAppMinJs to false in data/settings/config.json file for this to work (so that non-minified JavaScript is loaded instead of minified one), and clear browser cache to apply changes.