[NCN-438] Manage hub secret

[jsperhac]

Dependencies

This work is part of Epic NCN-434, whose PRs should all be deployed together:

• 1693, NCN-633 plgUserHubzero (on user login, ensure user has a secret in the DB)

• 1683 NCN-439 com_members (manage user secret)

• 1676 NCN-437 com_newsletter (manage campaign secret)

• 1675 NCN-438 com_config (manage hub secret)

• 1695 NCN-702, NCN-440: com_newsletter (update access verification)

Summary

As part of the Nanohub Epic [NCN-434] we will create and maintain a unique Hub secret (32 random characters). This PR provides an interface for the Admin user to reset the Hub secret.

Motivation

This development was undertaken for Nanohub, as part of the Epic "Salesforce Newsletter Expiration Token Rewrite", NCN-434. The card for the present development task is NCN-438. This is general enough functionality to justify its inclusion in core.

The goal is to enable the admin user to reset the unique Hub secret. This secret is stored in a database table (presently, badly named campaign_hub). This Hub secret can be hashed together with a user's unique secret and a unique email campaign secret to create a unique code. This code can be used to form a URL that will be emailed to the user to provide them with access to a Hub newsletter.

Note that resetting the Hub secret will invalidate any existing campaigns. Resetting this secret will be a rare event!

Code Description

This development makes use of com_config. It adds a drop-down ('hub_secret') to the Global Configuration admin page. The Admin user can select 'Update Hub Secret' in the drop-down. This will trigger the change of the Hub secret on save of the page.

Several changed files provide text, explanation, and information about the interface.

This screenshot shows the default view of the control:

In this work, the application controller in com_config is expanded to add a private function that generates and saves a 32-character random string. This is called if the user has prompted for a new Hub secret. If the save occurs correctly, the hub_secret config value is saved as 'noop' so that it is not changed again on subsequent load of the page.

The hub_secret setting and other Hub configuration values are saved both in /var/www/hubname/configuration.php and in app/config/. For all other config settings, only the files are used. In order to tag along with this mechanism, hub_secret is also saved as a file, but only the value 'noop' should be saved. Note that the Hub secret itself is not exposed on this page. It is present only in the database.

A migration file is included. This file creates the required campaign_hub database table and populates it with a single record, on up migration; it drops the table on down migration.

Testing

This feature was tested by accessing the Admin page's Global Configuration, and by viewing the configuration files and the single value of 'secret' in the database table campaign_hub.

When the Admin user selects "Reset Hub Secret" and saves the configuration page, the secret value saved in the campaign_hub table will be updated to a new random string. The hub_secret value saved in both /var/www/hubname/configuration.php and in app/config/hub_secret.php will be 'noop'.

If the Admin user accepts the default setting of this configuration in the Admin UI, the database secret value will not be changed. Again, the value of hub_secret in the files is 'noop'.

Up and down migration should also be tested:

• down: php muse migration --file=Migration20230920000000ComConfig.php -d=down -f On down migration this script should drop the campaign_hub table

• up: php muse migration --file=Migration20230920000000ComConfig.php -d=up -f On up migration it should recreate and populate the table.

Deployment

This should be deployed together with PR #1663 as they are part of the same Epic. Additional work associated with this is still to be completed. The campaign_hub table needs to exist. (Should the table creation be added to a migration script for this work?)

Revisions

This section is TBA as it depends on what happens in the code review. ;-)

Questions for code review:

• improvement to the table name (campaign_hub)
• is a migration script to create the database table needed as part of this work?

[nkissebe]

Let's make a table jos_config and put a general purpose design to it for future use. Columns scope, key, value. This instance could be scope=global, key=secret, value=XXX. We can build a model around it, but for now this can be a one off for this variable and the next time we use it we can put in time for the general purpose infrastructure.

My only concern here is there is already a hub wide "secret" that is used to encrypt session info and I am afraid of confusing the two. We can't use the same value because changing the secret would mess up all active sessions and we wouldn't want that to be a side effect for this purpose. So maybe an alternate naming.

I would also like to avoid writing even the noop to the config file as thats a little confusing. Maybe in the xml we can add an option to indicate its a config value to only be stored in db and we can skip the file saving aspect. That might be a nice feature to have available. Not sure how feasible that is.

[jsperhac]

@nkissebe makes excellent points here. I've requested a meeting with him and @dbenham to talk over this work (and remainder of the Epic). TODO on this PR (1675):

• I will add the recommended generalized table. A timestamp indicating record creation time/date will also be appropriate here.
• I had forgotten about the hack I used to write the secret to the db but not the config file. All other configs go straight to the file, not to the database. I'll have a look in the branch to check whether there's a tidy way to avoid writing to the config file.
• I'm also not a big fan of the dropdown that controls reset of the Secret, since everywhere else in this feature Epic (com_members, com_newsletter) I am enabling the user to reset specific secrets with a checkbox. Consistency would be preferable. But, speaking of consistency, there are no other checkboxes used in this form, only Yes/No radio buttons. I'll think on this. What makes the most sense?

[jsperhac]

Superceded by #1704