Setting up the Shopware extension

Setup

The DomainWarn extension for Shopware 6 adds the domains of every sales channel to monitoring, reports versions, pending updates and the mail setup every 15 minutes, and shows the state right in the shop admin.

Install and activate the extension in the shop (Extensions → My extensions).
Under Settings → Extensions → DomainWarn click "Connect with DomainWarn". You confirm in DomainWarn, and the token reaches the shop server to server – never through the browser, nothing to copy.
"Test connection", then "Add domains" under Settings → DomainWarn. From then on the scheduled task domainwarn.report reports every 15 minutes.

Prefer to do it by hand? Paste a token with write scope from DomainWarn (Settings → API) into the "API token" field. For deployments the same steps exist as commands: bin/console domainwarn:test, bin/console domainwarn:sync-domains and bin/console domainwarn:report.

For the heartbeat to work, the scheduled tasks of the shop must run (bin/console scheduled-task:run as a service or cron job) – which is exactly what it checks.

Requirements: Shopware 6.6.10 to 6.7, PHP 8.2 or newer and a DomainWarn account – the free one is enough.

What the extension reports

Shopware and PHP version: The exact version instead of a guess. Whether it is outdated or no longer gets security updates is judged by DomainWarn from the current releases.
Extensions with an update: Installed plugins and apps with the version Shopware itself knows as an update.
Mail setup: Sender address and mail server. Together with the DNS records this yields the finding "your shop sends through a server that is not in the SPF record".
Maintenance mode: If a sales channel is in maintenance mode, customers and search engines only see the maintenance page. DomainWarn points it out.
Scheduled task heartbeat: A scheduled task reports in every 15 minutes. If it stops, the message queue or the cron job has stalled – the shop looks healthy but processes nothing. The heartbeat sets itself up, there is no address to copy.
State in the shop admin: Under Settings → DomainWarn you find the domains of the shop with their state, domains not yet monitored with a button to add them, and the open incidents – without switching to the dashboard.

Data transferred

Transmitted are the domains of the sales channels, Shopware and PHP version, names and versions of installed extensions, sender address and mail server, and the maintenance mode. Not transmitted are customer data, orders, products, prices or shop content. The API token is stored in the shop only and never reaches the browser.

Hosting through the WordPress plugin and the Shopware extension

If the domain runs WordPress or Shopware 6, the security.txt needs no line in the web server: the plugin or extension serves the file itself. Switch on "Serve security.txt via DomainWarn" in its settings (default: off) – from then on the site fetches the file from DomainWarn and answers /.well-known/security.txt itself with 200 and text/plain, byte for byte and without a redirect. The file is kept for an hour; while DomainWarn cannot be reached, the last good copy is served as long as its Expires lies in the future. In Shopware this applies per sales channel domain.

It only serves where the file belongs: at the domain itself or with www in front of it (a site at blog.client.example serves nothing), only when the site sits at the domain root, and only from a file of the exact form https://domainwarn.com/security-txt/<token>/security.txt. That address comes from a stored status that the scheduled run refreshes every 15 minutes when due (GET /api/v1/orgs/<slug>/domains/<id>/hosting); a normal page view never contacts DomainWarn. Only content that looks like a security.txt is accepted (a Contact line, no HTML); without a usable file the site answers as it would without the plugin. If a security.txt already lies in the web root or another plugin answers the address, the settings page shows it as a conflict and serving stays off – nothing is overridden silently.

"Check security.txt" fetches the address like a researcher, compares the file byte for byte with the one at DomainWarn (Contact and Expires present) and shows the result of DomainWarn's own check next to it. If a cache still holds an older copy, the check says so.

MTA-STS cannot be served this way: RFC 8461 forbids sending mail servers to follow redirects when fetching the policy. The policy has to live at mta-sts.client.example itself – the CNAME to DomainWarn takes care of that. For MTA-STS and BIMI the plugin and the extension therefore only show the status (active, record missing, outdated, not set up), the records to copy and a button to the dashboard page where a connected DNS provider sets them with one click.

Frequently asked questions

Do I need a paid account?: No. The extension is free and works with the free DomainWarn account. What is charged is the monitoring service, once more domains or shorter check intervals are needed.
Is customer data transmitted?: No. Transmitted are domains, versions, installed extensions, sender address and mail server, and the maintenance mode. No customers, orders, products, prices or shop content.
Why does DomainWarn open an incident although the shop is up?: Because the heartbeat stopped. Then the message queue or the cron job has stalled: the shop still answers, but it sends no mail and processes nothing.
Does the extension work with a self-hosted DomainWarn?: Yes. The API address can be changed under "Advanced".