in2code-de / femanager

Modern TYPO3 Frontend User RegistrationTYPO3 Frontend User Registration and Management based on Extbase and Fluid and on TYPO3 8 and the possibility to extend it to your needs. Extension basicly works like sr_feuser_register
https://www.in2code.de/agentur/typo3-extensions/femanager/
47 stars 118 forks source link

User deleted / refused on UserConfirm #328

Closed cyrotek closed 5 months ago

cyrotek commented 3 years ago

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

typo3rel commented 3 years 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

sbusemann commented 3 years ago

sorry, i can not reproduce it. Please provide further information, then I will reopen it.

akiessling commented 1 year ago

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?

stigfaerch commented 10 months ago

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.

stigfaerch commented 8 months ago

@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.

typo3rel commented 8 months ago

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

stigfaerch commented 8 months ago

@typo3rel Sounds good. Can you share the extension?

typo3rel commented 8 months ago

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

stigfaerch commented 8 months ago

@typo3rel thanks. @sbusemann I'm working on some changes regarding this issue, and will make pull request soon.

stigfaerch commented 8 months ago

@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"
}
sbusemann commented 5 months ago

Released in 6.4 a port for 7.x and 8.x is planned