Closed cyrotek closed 5 months ago
that was with us too .. I think it was the antivirus check on the mail server that followed the links and triggered them. we have replaced the template so that a button has to be clicked
sorry, i can not reproduce it. Please provide further information, then I will reopen it.
Hi @sbusemann
didn't @typo3rel describe the problem quite good? Some antivirus scanner checks the links and thus causes the profiles to be deleted. That happened repeatedly to a customer of mine for a few days now where the registration is instantly deleted.
It would be a lot safer to link the delete-action to a confirmation page where the user has to press a button or better enter "confirm" or the mail address again before the record gets deleted.
@typo3rel can you provide your patched template?
I have created a small extension which you can configure to use an event in fe_manager and divert from executing the links. It's possible to compare on the request method and on the user agent. https://gitlab.com/dkm-extensions/divert_request Have a look at Configuration/Example/fe_manager.php to see how to configure. The example should work for Outlook verifying links. This will however not work for invitation e-mails, as there are no events before things are stored.
@sbusemann
This has become more difficult for us to handle now. I have found that after the mail is sent, and before it is shown in my mailbox, the links in the mail are requested. I guess this is the Exchange server doing some verification or virus/malware test. Even though we might be able to disable this on our Exchange server, we cannot disable this on our customers users exchange servers. And unfortunately there is no good way to detect and divert the request as the user agent does not reveal much: (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36".
The only way I can think of, to overcome this problem, would be that link directs to a page where he/she confirms the action.
We had created an extension that connects to 'confirmCreateRequestActionBeforePersist'. If the status is 'userConfirmationRefusedHook' it redirects to the own controller which then displays a deletion link back to femanager... or something like that
@typo3rel Sounds good. Can you share the extension?
Yes in parts: ext_localconf.php:
$signalSlotDispatcher = TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\\Extbase\\SignalSlot\\Dispatcher');
$signalSlotDispatcher->connect(
In2code\Femanager\Controller\NewController::class,
'confirmCreateRequestActionBeforePersist',
Vendor\Extname\Slot\CreateRequestBeforePersist::class,
'beforeConfirmCreateRequest'
);
Classes/Slot/CreateRequestBeforePersist.php:
<?php
namespace Vendor\Extname\Slot;
use In2code\Femanager\Utility\HashUtility;
use In2code\Femanager\Utility\UserUtility;
class CreateRequestBeforePersist {
/**
* action for every confirmation request
*
* @param int $user User UID (user could be hidden)
* @param string $hash Given hash
* @param string $status
* "userConfirmation", "userConfirmationRefused", "adminConfirmation",
* "adminConfirmationRefused", "adminConfirmationRefusedSilent"
*
* @return void
*/
public function beforeConfirmCreateRequest ($user, $hash, $status, $femanagerClass) {
// we used our extended Model based on \In2code\Femanager\Domain\Model\User
if (is_a($user, 'Vendor\Extname\Domain\Model\User')) {
if (HashUtility::validHash($hash, $user)) {
switch ($status) {
// this plugin is on page id=592 located
case 'userConfirmationRefusedHook':
header('Location: ' . 'index.php?id=592&tx_extname_pi1[user]=' . $user->getUid() . '&tx_extname_pi1[hash]=' . $hash . '&tx_extname_pi1[status]=userConfirmationRefused', TRUE);
exit();
case 'adminConfirmationRefused':
// Admin refuses profile
break;
case 'adminConfirmationRefusedSilent':
break;
default:
break;
}
}
}
}
}
Classes/Controller/ConfirmController.php:
<?php
namespace Vendor\Extname\Controller;
class ConfirmController extends \TYPO3\CMS\Extbase\Mvc\Controller\ActionController {
/**
* Status action: User confirmation refused
*/
public function confirmRefusedAction() {
$arguments = $this->request->getArguments();
$this->view->assignMultiple([
'user' => $arguments['user'],
'hash' => $arguments['hash'],
'status' => $arguments['status']
]);
}
}
Template Resources/Private/Templates/Confirm/ConfirmRefused.html:
<html xmlns:f="http://typo3.org/ns/TYPO3/CMS/Fluid/ViewHelpers" data-namespace-typo3-fluid="true">
<f:layout name="Default" />
<f:section name="Main">
<f:comment>femanager plugin is on page id 20 located</f:comment>
<f:link.action class="btn btn-u" pageUid="20" action="confirmCreateRequest" controller="New" extensionName="femanager" arguments="{user: user, hash:hash, status:status}" >delete profile </f:link.action>
</f:section>
</html>
i don't know if it still works the same way but it did for a while replace Vendor\Extname, change the page uids and you would also have to set femanager as a dependency in the extension emconf and composer.json
@typo3rel thanks. @sbusemann I'm working on some changes regarding this issue, and will make pull request soon.
@sbusemann I made some changes implementing a step for confirmation by form submission. I have made it for v7 and not v8, as the project where I need this is TYPO3 v11. I tried to compare with the develop branch, and it seems like it could be merged directly.
I have set i enabled as default, but it can be disabled by setting plugin.tx_femanager.settings.new.email.activateEmailLinkFormConfirmation = 0
I have implemented this for mails when creating a new user profile and for invitation, though I haven't tested it for invitations.
https://github.com/stigfaerch/femanager/tree/7.2.3-emailLinkFormConfirmation
If you use cweagans/composer-patches you can implement it as patch on 7.2.3 by adding following to the extra>patches part of the composer.json file and then updating in2code/femanager:
"in2code/femanager": {
"https://github.com/in2code-de/femanager/issues/328": "https://github.com/stigfaerch/femanager/commit/d557efd193202078d8232503b3441360d24a73d5.patch"
}
Released in 6.4 a port for 7.x and 8.x is planned
Typo3 9.5.22 FEManager 5.2.0
We have a weird behavior, once a user registered and confirms his account, he recieves his accepted message and will be refused by the Admin right after, two times going by the Log. For one reason or another it seems to redirect to that in the background before going to the final, as I have implented an exception when the status adminConfirmationRefused is called but I dont get any exceptions when confirming my account.
?tx_femanager_pi1%%5Baction%%5D=confirmCreateRequest&tx_femanager_pi1%%5Bcontroller%%5D=New&tx_femanager_pi1%%5Bhash%%5D=c7b2664e3280d613&tx_femanager_pi1%%5Bstatus%%5D=adminConfirmationRefused&tx_femanager_pi1%%5Buser%%5D=5824&cHash=669cb48389e84937e376a81719cdc930
I debugged it up to the createAdminNotify function, but also when I change the admin mail to another, it works as well. Also once I deactivate the said function, I'll be logged in automatically and the flash message appears that my account has been activated.
Any hints?
Best wishes