Feed Protection — HTTP Basic Auth

Protect your product feed XML files with a username and password so that only authorised crawlers — like Facebook's Catalog Manager — can download them.

note

Available since v2.4.5

Overview

By default, your generated feed files are publicly accessible to anyone who knows the URL. For most stores this is fine, but you may want to restrict access for privacy reasons, to prevent competitors from scraping your prices, or to comply with a platform policy.

When you enable Feed Protection, the module writes an .htaccess file and an .htpasswd file directly into the feeds/ folder inside the module directory. Apache (and compatible servers like LiteSpeed) then enforce HTTP Basic Authentication on every .xml file in that folder. Any request without valid credentials receives a 401 Unauthorized response.

Facebook and Instagram's Catalog Manager fully support this: you embed the credentials directly in the scheduled fetch URL, and the crawlers pass them transparently on every refresh.

Apache/LiteSpeed only. The .htaccess mechanism is not honoured by Nginx. If your server runs Nginx, this feature will not restrict access. See Server Requirements below.

Enabling Protection

1. Go to Modules > Module Manager, find Facebook & Instagram Product Catalogue Feed Pro, and click Configure.
2. Click the Feed Protection tab.
3. Set Protect the feeds URL? to Yes.
4. Enter a User and a Password.
5. Click Save Configuration.

As soon as you save, the module creates (or overwrites) .htpasswd and .htaccess in the feeds/ folder. The password is hashed with bcrypt before it is written — the plain-text value is never stored on disk.

Field	Values	Default	Description
Protect the feeds URL?	Yes / No	No	Writes .htaccess and .htpasswd into the feeds folder when enabled. Removes them when disabled.
User	Any string	(empty)	The username required to access the feed files.
Password	Any string	(empty)	The password. Stored as a bcrypt hash in .htpasswd — never in plain text.

Both User and Password must be filled in before you can enable protection. If either field is empty when you save with the toggle set to Yes, the module shows an error and leaves protection disabled.

To disable protection later, set Protect the feeds URL? to No and save. The module deletes both .htaccess and .htpasswd from the feeds folder so the XML files become publicly accessible again.

Adding Your Credentials in Facebook Catalog Manager

Facebook's Catalog Manager fetches your feed on a schedule. When the feed is protected, you need to embed the credentials in the feed URL you provide to Facebook.

The format for a URL with embedded HTTP Basic Auth credentials is:

https://username:password@yourstore.com/modules/facebookproductsfeed/feeds/feed_1_en.xml

Steps:

1. Copy your feed URL from the module's dashboard (the URL shown next to each language flag).
2. Insert your credentials before the domain name: https:// → https://USERNAME:PASSWORD@
3. Paste the full URL into the Content URL field when setting up a Scheduled Feed in Facebook's Catalog Manager.
4. Facebook will use this URL on every scheduled refresh and pass the credentials automatically.

Tip: Some special characters in passwords (such as @, /, ?, #) must be URL-encoded when embedded in a URL. For example, a @ becomes %40. If your password contains these characters, choose a simpler password to avoid encoding issues.

Instagram Shopping uses the same Catalog Manager backend. The same URL format with embedded credentials applies there too.

Server Requirements

Requirement	Details
Web server	Apache 2.4+ or LiteSpeed. The .htaccess mechanism is not supported on Nginx.
AllowOverride	The Apache virtual host must allow .htaccess overrides for the module directory (AllowOverride AuthConfig or AllowOverride All). If overrides are disabled, the .htaccess file will be ignored and access will remain open.
File write permissions	PHP must be able to write to the feeds/ folder inside the module directory. The module shows an error during save if it cannot create or write to .htpasswd or .htaccess.
mod_authn_file	The Apache module mod_authn_file must be enabled. It provides the AuthUserFile directive used in the generated .htaccess. Most shared hosting environments have this enabled by default.

If you are on Nginx, consider restricting access at the server configuration level instead (for example, using auth_basic in your Nginx site block). Contact your hosting provider or system administrator if you need help with that.

Important Notes

• Only .xml files are protected. The .htaccess the module writes uses a <FilesMatch "\.xml$"> block, so other files in the feeds folder (like progress.json) remain accessible without credentials.
• One credential set per shop. Protection settings (FPF_SECURITY, FPF_SECURITY_USER, FPF_SECURITY_PASS) apply to the current shop context. In a multi-shop setup, configure protection separately for each shop if needed.
• Changing credentials re-writes the files. If you update the username or password and save again, the module overwrites both .htpasswd and .htaccess with the new values immediately.
• Basic Auth for generation (separate feature). The Feed Protection tab also contains Basic Auth Username and Basic Auth Password fields. These are unrelated to feed protection — they are used when the module's internal feed generator makes HTTP requests to itself (for recursive cycle generation) and your server requires authentication to access the site. Do not confuse these with the feed-folder credentials.

Troubleshooting

Problem	Solution
"Security credentials are not valid or empty" error when saving	Both User and Password must be non-empty before you can enable protection. Fill in both fields and save again.
"Unable to create or write to the .htpasswd file" error	PHP does not have write permission on the feeds/ folder. Check the folder ownership and permissions on your server. The folder must be writable by the web server user.
Feed URL still accessible without credentials after enabling	Your server is likely running Nginx, or Apache has AllowOverride None for the module directory. The .htaccess file is present on disk but not being read. Ask your hosting provider to enable .htaccess overrides, or use a server-level auth restriction instead.
Facebook returns a "Couldn't fetch feed" error after enabling protection	The credentials embedded in the URL you gave Facebook are incorrect, or the URL format is wrong. Double-check the https://user:pass@domain/... format and confirm the credentials match those you set in the module.
Protection was disabled but feed still returns 401	The module failed to delete .htaccess or .htpasswd (a file permission issue). Manually delete those two files from the feeds/ folder via FTP or your hosting file manager.

Frequently Asked Questions

Do I need to update the URL in Facebook Catalog Manager every time I change my password?

Yes. The credentials are embedded in the feed URL you registered with Facebook. When you change the username or password in the module, you must also update the URL in Catalog Manager with the new credentials — otherwise Facebook's scheduled fetch will return 401 and the catalogue will stop updating.

Can I use any username and password, or are there restrictions?

You can use any non-empty string. For simplicity, avoid special characters such as @, :, /, ?, and # in your password, because these need URL-encoding when embedded in a feed URL. A password using only letters, numbers, and hyphens is easiest to work with.

Is the password stored securely?

Yes. The module hashes the password with bcrypt before writing it to .htpasswd. The plain-text password is never stored in the database or on disk.

Does this protect all feed languages and countries, or only one?

Protection applies to the entire feeds/ folder. All .xml files in that folder — regardless of language or country — require credentials once protection is enabled.

What happens to my feeds if I delete the .htpasswd file manually?

The .htaccess file still refers to the (now missing) .htpasswd file. Apache will return a 500 Internal Server Error for any feed URL. To recover, either re-enable and re-save Feed Protection in the module (which rewrites both files), or disable protection in the module and save (which deletes the orphaned .htaccess).

Related Features

• Automatic Generation — Cron Jobs
• Cycle-based Generation for Large Catalogues