The Frontend Login for Website Users (felogin) extension is a general
purpose extension for frontend logins. In addition to the actual login
box, it includes several methods for redirecting after login/logout
and includes forgot password functionality.
Screenshots
General Settings
The plugin's general settings
Redirect Configuration
Configuration of the redirection options
Hint
Be sure that in the overall Access tab under User Group Access rights the content
element and even the page itself is not set to Hide at login, otherwise the redirect
to the given page will not work.
Messages Tab
Configuration of the various messages (screenshot shows not all options)
Installation
This extension is part of the TYPO3 Core, but not installed by default.
The felogin extension requires no special configuration. All options
are available in the plugin's FlexForm as shown in the Screenshots.
Using the plugin
The felogin plugin is available through the Content Wizard as Login Form:
The Login Form plugin in the content element wizard
Choosing a User Storage Page for Website Users
In order for Website Users to be able to log in, the felogin plugin
must know where the records are stored. There are two possibilities
for setting this storage folder:
Edit the felogin plugin, setting the field for the User Storage
Page to your storage page.
Or set the UID of you storage folder through TypoScript in the setup
field of your TypoScript record:
plugin.tx_felogin_login.settings.pages = xxx
Copied!
Access restrictions on the felogin plugin
A very common issue is, that the felogin plugin is set to Access:
Hide at login. After the core has processed the login request, the
page will be rendered without the felogin plugin. If there are redirect options
active they will not be executed, simply because the felogin plugin is
hidden.
Of course setting the felogin plugin to Hide at login and having
redirect options together doesn't really makes sense.
Login mechanism
In order to properly use the felogin plugin and its advanced
capabilities (such as redirect options) it is important to understand
the mechanism of frontend user login in TYPO3 CMS.
If there is no frontend user logged in, the login form will be
shown.
If there is a logged in frontend user, the logout form is shown.
If the forgot password link was used, the form to reset a password
based on username or email address will be shown.
If the password reset link was followed from an email, the form to
change the password will be shown.
The login process
After the form is submitted the TYPO3 CMS authentication services will
validate the login credentials. After this process felogin will handle
the rest. This means that the felogin plugin must be visible for the
user who has logged in.
Felogin will then check any redirect options and generate the
appropriate content.
Caution
Do not use the login status of a frontend user as authorization,
but always rely on user groups.
Only use different storage folders for frontend users if this is really
necessary due to organizational reasons.
Redirect Modes
The following redirect options are supported.
Defined by Usergroup Record
Within a Website usergroup record, you can specify a page where
usergroup members will be redirected after login.
Defined by User Record
This is identical to the redirection option for "defined by Usergroup
Record" but applies to a single website user instead of an entire user
group.
After Login (TS or Flexform)
This redirect page is set either in TypoScript
(
plugin.tx_felogin_login.settings.redirectPageLogin) or in the
FlexForm of the felogin plugin.
After Logout (TS or Flexform)
Defines the redirect page after a user has logged out. Again, it can
be set in TypoScript or in the felogin plugin's FlexForm.
After Login Error (TS of Flexform)
Defines the redirect page after a login error occurs. Can be set in
TypoScript or in the felogin plugin's FlexForm.
Defined by GET/POST Parameters
Redirect the visitor based on the GET/POST parameters redirect_url.
If the TypoScript configuration
config.typolinkLinkAccessRestrictedPages is set, the GET/POST
parameter redirect_url is used.
The referrer page is used for the redirect. This basically means that
the user is sent back to the page he originally came from.
Defined by Domain entries
Same as Defined by Referrer, except that only the domains listed in
plugin.tx_felogin_login.domains are allowed. If someone is sent to the
login page coming from a domain which is not listed, the redirect will
not happen.
By using the option Use First Supported Mode from Selection you can
define several fallback methods.
Note
It is only possible to use domains, which are known to TYPO3. This means,
that domains must be configured as base in site settings for websites
in the current TYPO3 instance.
Configuration
All configuration options are available in the FlexForm or TypoScript,
with the FlexForm settings taking precedence.
If set, the section in the template to display the link to the forgot
password dialogue is visible.
Important
Be aware that having this option disabled also prevents the plugin to
display the forgot password form. For instance if you access the link
directly.
showPermaLogin
showPermaLogin
Type
bool
If set, the section in the template to display the option to remember
the login (with a cookie) is visible.
showLogoutFormAfterLogin
showLogoutFormAfterLogin
Type
bool
If set, the logout form will be displayed immediately after successful
login.
.. note::
Setting this option will disable the redirect options!
Instead of redirecting the plugin will show the logout form.
pages
pages
Type
string
Default
{$styles.content.loginform.pid}
Define the User Storage Page with the Website User Records, using a
comma separated list or single value
recursive
recursive
Type
int
Default
{$styles.content.loginform.recursive}
If set, also any subfolders of the User Storage Page will be used
at configured recursive levels
redirectMode
redirectMode
Type
string
Default
{$styles.content.loginform.redirectMode}
Comma separated list of redirect modes. Possible values:
groupLogin, userLogin, login, getpost, referer,
refererDomains, loginError, logout
See section on redirect modes for details.
redirectFirstMethod
redirectFirstMethod
Type
bool
Default
{$styles.content.loginform.redirectFirstMethod}
If set the first method from redirectMode which is possible will be
used
If set and the user account cannot be found in the forgot password
dialogue, an error message will be shown that the account could not be
found.
.. warning::
Enabling this will disclose information about whether an
email address is actually used for a frontend user account! Visitors
can find out if a user is known as frontend user.
Time in hours how long the link for forgot password is valid
domains
domains
Type
string
Comma separated list of domains which are allowed for the referrer
redirect mode
passwordValidators
passwordValidators
Type
array
Deprecated since version 12.3
The TypoScript does not include validators any more by default. Instead, the
extension uses global password policies
to ensure password requirements are fulfilled.
Array of validators to use for the new user password.
Migration
Special password requirements configured using custom validators in
TypoScript must be migrated to a custom password policy validator as
described in password policies.
Before creating a custom password policy validator, it is recommended to
evaluate, if the
CorePasswordValidator used in the default
password policy suits current password requirements.
GET and POST parameters
The extension uses several GET and POST parameters to define or override
redirect settings.
noredirect
Parameter
noredirect
Evaluation
GET and POST
Data type
string
Description
If set to
1, no redirect will be processed after a successful
login.
PSR-14 events
The following PSR-14 events are available to extend the extension:
BeforeRedirectEvent
Notification before a redirect is made.
More details
LoginConfirmedEvent
A notification when a log in has successfully arrived at the plugin, via the
view and the controller, multiple information can be overridden in event
listeners. More details
LoginErrorOccurredEvent
A notification if something went wrong while trying to log in a user.
More details
LogoutConfirmedEvent
A notification when a log out has successfully arrived at the plugin, via
the view and the controller, multiple information can be overridden in
event listeners. More details
ModifyLoginFormViewEvent
Allows to inject custom variables into the login form.
More details
PasswordChangeEvent
Event that contains information about the password which was set,
and is about to be stored in the database. Allows to mark the password
as invalid. More details
SendRecoveryEmailEvent
Event that contains the email to be sent to the user when they request a
new password. More details
Examples
In this section some common situations are described:
Send visitors to login page and redirect to original page
A common situation is that visitors who go to a page with access
restrictions should go to a login page first and after logging in
should be send back to the page they originally requested.
Assume we have a login page with id 2.
Using TypoScript we can still display links to access restricted pages
and send visitors to the login page:
(This option can also be set in the flexform configuration of the
felogin content element)
If visitors will directly enter the URL of an access restricted page
they will be sent to the first page in the rootline to which they have
access. Sending those direct visits to a login page is not a job of
the felogin plugin, but requires a custom page-not-found handler. In this sense,
we refer to Custom error handler implementation for 403 redirects.
Login link visible when not logged in and logout link visible when logged in
Again TypoScript will help you out. The page with the login form has
id=2:
Of course there can be solutions with
HMENU items, etc.
Custom error handler implementation for 403 redirects
This section explains how to utilize a custom error handler
to catch 403 restricted page errors and allow to forward
to a login form, and then redirect back to the originating
page after successful login.
You need the following site settings in the error handling
Error Handling tab of Site Configuration module
There you add the custom 403 error handler and configure
the error handler, you create in the following steps.
Look up the page ID where a login form (like with EXT:felogin) is placed
This page ID is needed in the following step, so that the error
handler will know, where to forward an unauthenticated user to, so
that a login can be performed.
Ideally, this should be done by configuring a page ID via the
site settings, and referring back to a named ID. See
PHP API: accessing site configuration
for more information. For reduced complexity, this example uses
a hard-coded page ID.
Create a new error handler RedirectLoginErrorHandler.php
Create a PHP error handler class like the following in a custom
extension, like your own sitepackage:
<?phpdeclare(strict_types=1);
/*
* This file is part of the TYPO3 CMS project.
*
* It is free software; you can redistribute it and/or modify it under
* the terms of the GNU General Public License, either version 2
* of the License, or any later version.
*
* For the full copyright and license information, please read the
* LICENSE.txt file that was distributed with this source code.
*
* The TYPO3 project - inspiring people to share!
*/namespaceMyVendor\MySitePackage\Error\PageErrorHandler;
usePsr\Http\Message\ResponseInterface;
usePsr\Http\Message\ServerRequestInterface;
useTYPO3\CMS\Core\Context\Context;
useTYPO3\CMS\Core\Controller\ErrorPageController;
useTYPO3\CMS\Core\Error\PageErrorHandler\PageErrorHandlerInterface;
useTYPO3\CMS\Core\Http\HtmlResponse;
useTYPO3\CMS\Core\Http\RedirectResponse;
useTYPO3\CMS\Core\LinkHandling\LinkService;
useTYPO3\CMS\Core\Site\Entity\Site;
useTYPO3\CMS\Core\Utility\GeneralUtility;
useTYPO3\CMS\Frontend\Page\PageAccessFailureReasons;
/**
* An error handler that redirects to a configured page, where the login
* process is handled. Passes a configurable URL parameter (`return_url` or
* `redirect_url`) to the target page.
*/finalclassRedirectLoginErrorHandlerimplementsPageErrorHandlerInterface{
privateconst PAGE_ID_LOGIN_FORM = 656;
private readonly int $loginRedirectPid;
private readonly string $loginRedirectParameter;
private readonly Context $context;
private readonly LinkService $linkService;
private readonly ErrorPageController $errorPageController;
publicfunction__construct(private readonly int $statusCode){
$configuration = [
// TODO: Replace with $siteSettings[...] or something else'loginRedirectTarget' => 't3://page?uid=' . self::PAGE_ID_LOGIN_FORM,
'loginRedirectParameter' => 'return_url',
];
$this->context = GeneralUtility::makeInstance(Context::class);
$this->linkService = GeneralUtility::makeInstance(LinkService::class);
$this->errorPageController = GeneralUtility::makeInstance(ErrorPageController::class);
$urlParams = $this->linkService->resolve($configuration['loginRedirectTarget']);
$this->loginRedirectPid = (int)($urlParams['pageuid'] ?? 0);
$this->loginRedirectParameter = $configuration['loginRedirectParameter'];
}
publicfunctionhandlePageError(
ServerRequestInterface $request,
string $message,
array $reasons = []
): ResponseInterface{
$this->checkHandlerConfiguration();
if ($this->shouldHandleRequest($reasons)) {
return$this->handleLoginRedirect($request);
}
// Show general error message with a 403 HTTP status codereturn$this->getGenericAccessDeniedResponse($message);
}
privatefunctiongetGenericAccessDeniedResponse(string $reason): ResponseInterface{
$reason = $reason ? ' Reason: ' . $reason : '';
$content = $this->errorPageController->errorAction(
'Page Not Found',
sprintf('The page did not exist or was inaccessible.%s', $reason),
0,
$this->statusCode,
);
returnnew HtmlResponse($content, $this->statusCode);
}
privatefunctionhandleLoginRedirect(ServerRequestInterface $request): ResponseInterface{
if ($this->isLoggedIn()) {
return$this->getGenericAccessDeniedResponse(
'The requested page was not accessible with the provided credentials'
);
}
/** @var Site $site */
$site = $request->getAttribute('site');
$language = $request->getAttribute('language');
$loginUrl = $site->getRouter()->generateUri(
$this->loginRedirectPid,
[
'_language' => $language,
$this->loginRedirectParameter => (string)$request->getUri(),
]
);
returnnew RedirectResponse($loginUrl);
}
privatefunctionshouldHandleRequest(array $reasons): bool{
if (!isset($reasons['code'])) {
returnfalse;
}
$accessDeniedReasons = [
PageAccessFailureReasons::ACCESS_DENIED_PAGE_NOT_RESOLVED,
PageAccessFailureReasons::ACCESS_DENIED_SUBSECTION_NOT_RESOLVED,
];
$isAccessDenied = in_array($reasons['code'], $accessDeniedReasons, true);
return $isAccessDenied || $this->isSimulatedBackendGroup();
}
privatefunctionisLoggedIn(): bool{
if ($this->context->getPropertyFromAspect('frontend.user', 'isLoggedIn')) {
returntrue;
}
return$this->isSimulatedBackendGroup();
}
protectedfunctionisSimulatedBackendGroup(): bool{
if (!$this->context->getPropertyFromAspect('backend.user', 'isLoggedIn')) {
returnfalse;
}
// look for special "any group"
$groups = $this->context->getPropertyFromAspect('frontend.user', 'groupIds');
return $groups[1] === -2;
}
privatefunctioncheckHandlerConfiguration(): void{
if ($this->loginRedirectPid === 0) {
thrownew \RuntimeException('No loginRedirectTarget configured for LoginRedirect errorhandler', 1700813537);
}
if ($this->statusCode !== 403) {
thrownew \RuntimeException(sprintf('Invalid HTTP status code %d for LoginRedirect errorhandler', $this->statusCode), 1700813545);
}
}
}
Copied!
Adapt the constant
PAGE_ID_LOGIN_FORM to match the
page ID from the previous step.
Since there is no proper way how to do it otherwise, we put in the page ID
of the login form hard-coded into the file RedirectLoginErrorHandler.php
and define a constant
PAGE_ID_LOGIN_FORM for it. In the example
above, this is set to 656.
Hint
This example code uses PHP 8.1 syntax. Depending on the PHP version you use in
your project, you may need to adapt language features like readonly to match your
used PHP version.
In your EXT:felogin plugin, make sure you selected "Defined by GET/POST
Parameters" as first redirect mode
Plugin > Redirects tab of Login Form content element
You need to configure the login form that receives your redirect in a
way, that allows to evaluate submitted URL parameters. In EXT:felogin,
this is achieved via this Redirect Mode (which can also be set
through TypoScript configuration, see redirectMode.
Your login form will probably also need to define a specific target page
for normal logins (independent from the error handler redirect), so you
should also add a redirectMode like login to your list, and set
a target page in redirectPageLogin.
Testing the custom error handler
Clear the caches, for example via the backend module
Admin Tools > Maintenance.
Then open any access-restricted page
in an incognito browser window to be sure that
you are not logged in yet. Here we will use the example
URL https://example.org/restricted/page.
When everything is configured correctly and if you are not logged in
yet, then you should be redirected to your login page like
https://example.org/login (example page ID 656).
After entering proper frontend user credentials, you should be redirected
back to https://example.org/restricted/page, the page where you
wanted to get to initially.
Hint
When you have multiple site configurations, be sure to access
the correct one. This means where both the login form is located,
and the custom error handler is configured for.
Hint
Do not copy the generated link from the address URL after you clicked
View webpage from the backend, and then just paste it into
the URL bar of the incognito window. The reason is that when
being logged in to the backend, a possibly simulated frontend user
login can affect your tests.
Hint
Do not get confused when the URL
https://example.org/restricted/page will be forwarded to a URL
like
when you want to access the restricted page in the first place.
These are the getpost redirect parameters that are evaluated by
EXT:felogin. Now type in the user credentials of the already created
frontend user and you should get redirected to the desired
page https://example.org/restricted/page.
If there is more than one felogin plugin on a page the password
recovery option can cause problems. This is a general problem with
plugins, but in this case the cause is a small hash in the forgot
password form which is stored in the frontend user session data.
With multiple instances on a page only one of the hashes is
stored and only one of the forgot password forms will work. Make sure
there is only one felogin plugin on the page where the password
recovery form is displayed.
If usergroup access rights of the plugin are defined to
Hide at login, all felogin code (e.g. redirects, PSR-14 events)
will not be executed after a user successfully logged in.
Sitemap
Reference to the headline
Copy and freely share the link
This link target has no permanent anchor assigned.The link below can be used, but is prone to change if the page gets moved.