Feed Protection — Secret Key and Generator Basic Auth
The module uses two separate protection mechanisms: a secret key that gates who can trigger feed generation, and HTTP Basic Auth credentials that let the generator pass through a server-level .htaccess password on your site.
Available since v2.4.5
Overview
Feed generation is triggered by an HTTP request to your store's front end (/module/facebookproductsfeed/GenerateFeed). Without any protection, anyone who knows that URL could start a generation at any time, consuming server resources. The secret key prevents this by requiring a matching token in the URL before the module does any work.
Separately, many hosting setups — especially staging environments and some shared hosts — protect the entire site or wp-admin-equivalent paths with .htaccess HTTP Basic Authentication. When the module makes its internal cURL call to continue a cycle, that cURL request hits the same .htaccess wall and fails silently. The generator Basic Auth credentials tell the module what username and password to include in those internal cURL requests so they can pass through.
These are two independent settings that solve two different problems.
The Secret Key
The secret key is a token derived from your store's _COOKIE_KEY_ and the module name. It is stored globally (FPF_SECRET_KEY) and must be present as a URL parameter (fpf_secret_key) for any web-based generation request to proceed.
The generator controller checks this at the very start:
?fpf_secret_key=<value>
If the value is missing or wrong, the controller exits immediately with no output. CLI-based generation (cron via PHP CLI) bypasses this check entirely — the key is only required for web requests.
The module pre-populates the secret key in all the URLs it shows you: the cron URL on the Cron Jobs tab, the console URL on the Dashboard tab, and the URL the generator uses internally for cycle continuation. You never need to look up or copy the key manually.
Resetting the Secret Key
If you suspect your generation URL has been exposed or you want to rotate the key, you can regenerate it by visiting your Back Office URL with fpf_reset_secret=1 appended:
https://yourstore.com/admin/index.php?controller=AdminModules&configure=facebookproductsfeed&fpf_reset_secret=1
The module regenerates the key from md5(_COOKIE_KEY_ . 'facebookproductsfeed') and stores the result globally. After the reset, any old cron job URLs you have set up on your server will stop working — you need to copy the new cron URL from the Cron Jobs tab and update your server's cron entry.
The secret key is stored as a global PrestaShop configuration value, meaning it applies to all shops in a multistore setup. Resetting it invalidates existing cron URLs for every shop at once.
Generator Basic Auth
This section is found on the Feed Protection tab (#fieldset_security), under the heading Basic Auth for generation.
| Field | Description |
|---|---|
| Basic Auth Username | The HTTP Basic Auth username the module sends in internal cURL requests during cycle generation |
| Basic Auth Password | The corresponding password. Once saved, the field shows a badge instead of the value — the password is never displayed again |
When both fields are filled, every internal cURL call made by the generator includes an Authorization: Basic ... header. This allows cycle continuation to succeed on servers that require credentials to access the front office.
To remove the Basic Auth credentials, clear the Basic Auth Password field and save. When the password field is empty on save, the module clears both the username and password.
These credentials are for the module's own internal cURL requests only. They are not related to the Protect the feeds URL? switch described below, which controls access to the finished feed XML files.
Feed URL Protection (Related)
The Feed Protection tab also contains a separate Protect the feeds URL? toggle (FPF_SECURITY). When enabled with a username and password, the module writes a .htaccess and .htpasswd file into the feeds/ folder, requiring HTTP Basic Auth credentials to download the feed XML files.
This is a different protection layer — it restricts who can read the finished feed files, not who can trigger generation. Facebook Commerce Manager needs to be able to fetch the feed URL, so if you enable feed URL protection you must also provide those credentials to Facebook when configuring your catalogue.
| Config key | Default | Purpose |
|---|---|---|
FPF_SECURITY | Disabled | Whether the feeds/ folder requires HTTP Basic Auth |
FPF_SECURITY_USER | — | Username for feed file access |
FPF_SECURITY_PASS | — | Password for feed file access |
FPF_BASIC_AUTH_USERNAME | — | Username for the module's own internal cURL requests |
FPF_BASIC_AUTH_PASSWORD | — | Password for the module's own internal cURL requests |
FPF_SECRET_KEY | Auto-generated | Token required in the generation URL |
Important Notes
- The secret key is not stored per-shop — it is a global value. In multistore setups, all shops share the same key and the same generation URL format.
- Resetting the secret key does not affect feed file access (FPF_SECURITY), only the ability to trigger generation.
- The Basic Auth credentials for the generator are stored per-shop (using
Configuration::getrather thanConfiguration::getGlobalValue), so different shops can have different credentials. - The secret key is generated once on module install. It changes only if you explicitly reset it via
?fpf_reset_secret=1or reinstall the module.
Troubleshooting
| Problem | Solution |
|---|---|
| Cron job stopped working after resetting the secret key | Copy the new cron URL from the Cron Jobs tab and update your server's cron entry |
| Feed generation starts but stops after the first cycle | Your server has .htaccess Basic Auth protection. Fill in Basic Auth Username and Basic Auth Password in the Feed Protection tab so the generator can continue cycles |
| "You can't access this page" when visiting the generation URL | The fpf_secret_key parameter in the URL is missing or outdated. Copy the correct URL from the Cron Jobs tab |
| Feed URL returns 401 to Facebook | Feed URL protection (FPF_SECURITY) is enabled. Provide those credentials to Facebook Commerce Manager when setting up the catalogue |
| Saving Basic Auth password shows the "password has been set" badge but generation still fails with auth error | Confirm the credentials match what your server expects — test with curl -u username:password <generation-url> from your terminal |
Frequently Asked Questions
Do I need to set up any protection at all?
The secret key is always active and generated automatically — you do not need to configure anything for basic protection. Generator Basic Auth is only needed if your hosting environment requires HTTP credentials to access the front office at all.
Where do I find the current generation URL with the secret key?
Go to the Cron Jobs tab. The module displays the full generation URL including the fpf_secret_key parameter. Copy it from there rather than trying to construct it manually.
I reset the secret key and now my cron job does nothing. What happened?
The old URL's fpf_secret_key value no longer matches what the module expects, so every request is silently rejected. Go to the Cron Jobs tab, copy the new URL, and update the cron entry on your server.
What is the difference between the Basic Auth fields and the 'Protect the feeds URL?' switch?
The Basic Auth Username/Password fields are credentials the module sends in its own outgoing cURL requests so that cycle generation can continue through a server-level auth wall. The Protect the feeds URL? switch creates its own auth wall around the finished XML feed files so that external visitors need credentials to download them. They are independent features.
Can I use the same credentials for both the generator Basic Auth and feed URL protection?
Yes, if your server already requires auth for all requests, using the same credentials for both makes sense. The two settings are stored separately and can differ if needed.
Does resetting the secret key affect any shop other than the current one?
Yes. The secret key is stored globally, so resetting it invalidates cron URLs for every shop in your multistore setup simultaneously. Update all cron jobs after a reset.