Adapt Shield's email2FA in Bonfire2

[dgvirtual]

Finishes the incomplete implementation in pr #416, fixes #352

[dgvirtual]

For existing projects, this will also mean updating manually

app/Config/Auth.php

If you fail to do that and turn on the 2FA, you will get locked out of the website.

To solve the problem, you will have to issue this command on db:

DELETE FROM settings WHERE class="Config\Auth" AND key="actions"

Does this count as breaking change, and should it be mentioned in the CHANGELOG, I wonder?

[lonnieezell]

I would definitely add a note about the breaking change on this.

I would love to get this repo to a point where we can get an official 1.0 out. And then start actual versions, but I don't have an ounce of free time lately.

[dgvirtual]

@lonnieezell, I am thinking about a partial solution to breaking updates: have composer create a file in the project on install/update with last update date, and then add a php file that would be executed on composer update, where we could put time-based messages to be printed by composer, so user knows he needs to do something manually.

I am thinking of adding this to scripts in composer.json:

    "post-update-cmd": [
      "php post-update-messages.php"
    ]

and then a file post-update-messages.php in the project root(?):

// Set the cutoff date or commit hash
$cutoffDate = new DateTime('2025-01-01 00:00:00');
$lastUpdateFile = 'last-update.txt';

// Check if the last update file exists
if (file_exists($lastUpdateFile)) {
    $lastUpdateDate = new DateTime(file_get_contents($lastUpdateFile));
    if ($lastUpdateDate >= $cutoffDate) {
        // Exit if the last update was after the cutoff date
        exit(0);
    }
}

// Display the warning message
echo "Warning: After this update, you need to do some manual changes (like copying theme files or editing config files). Please see [documentation link] for details ....\n";

// Update the last update file
file_put_contents($lastUpdateFile, (new DateTime())->format(DateTime::ATOM));

Do you see any drawbacks to such approach?

I think we could even automate this somehow, so that the script reads the dates from the file with breaking changes, so we do not need to specify the cutoffDate manually.

[dgvirtual]

Needed:

• documentation update;
• (prior to this) script to inform users of breaking changes at the end of composer update run