Collapse store Url/SecureUrl/SslEnabled onto a single Url

[KrzysztofPajak]

Type: feature

Issue

A store describes one address with three fields: Url, SecureUrl and SslEnabled. Every consumer resolves the effective address the same way — SslEnabled ? SecureUrl : Url — in 15+ places (all DotLiquid drops, GetSitemapXMLCommandHandler, InstallDataRobotsTxt, StoreContextSetter, CommonController, StoreViewModelService, both order PDF templates). There is effectively already only one URL; the pair is just a redundant way of writing it down.

The pair is a leftover from mixed http/https sites, where only login and checkout ran over TLS. That layout is gone — sites are HTTPS end to end — and the store owner is left with a checkbox whose only real effect is to select which of two text boxes is read.

Forcing HTTPS on an incoming http:// request is not the shop's job either: it belongs to the host. GrandNode already exposes it as SecurityConfig.UseHttpsRedirection, UseHsts and UseForwardedHeaders (GrandCommonStartup, ForwardedHeadersStartup), and in production a reverse proxy usually does the 301 + HSTS anyway.

To reproduce the redundancy: open Administration → Configuration → Stores → edit, and note that SSL enabled + Secure URL never produce an address the store does not already have.

Solution

Store.Url becomes the single address field and holds the full URL including the scheme. SslEnabled and SecureUrl are removed from the entity, StoreDto, StoreModel, StoreValidator and the admin view (together with the JS that toggled #pnlSecureUrl).

Url stays on the entity for the one reason it is genuinely needed: emails, sitemap.xml, robots.txt and order PDFs are built outside a request and have no Request.Scheme to read.

Two places were not a straight substitution:

• GetProductDetailsPageHandler rewrote http:// to https:// inside the share button code when SSL was on. Removed — a mixed-content workaround from before HSTS.
• The 1.1 domains migration read SslEnabled; it now takes the scheme from new Uri(store.Url).Scheme, with identical behavior.

The validator accepts any absolute http/https URL, so dev and intranet installations can still run over plain http. Startup/security configuration is untouched.

MigrationStoreSingleUrl (2.4) copies the primary DomainHost url back onto Store.Url. That is exactly the value the old ternary produced — the installer, the admin store editor and the 1.1 domains migration all wrote the resolved address there — so an installation that ran on HTTPS keeps generating HTTPS links. Stores without a usable primary domain are logged as a warning rather than guessed at. The now-unmapped SslEnabled/SecureUrl elements are left in the documents: the global IgnoreExtraElementsConvention skips them on read, and they disappear on the next store save.

Breaking changes

• Store.SslEnabled and Store.SecureUrl are removed from the domain entity. Plugins or custom code reading them will not compile.
• StoreDto.SslEnabled and StoreDto.SecureUrl are removed from the API module, so the store endpoint's payload shape changes.
• StoreModel.SslEnabled / StoreModel.SecureUrl are removed, which affects admin view overrides and any IValidatorConsumer<StoreModel>.
• The localization resources Admin.Configuration.Stores.Fields.SslEnabled, .SslEnabled.Hint2, .SecureUrl and .SecureUrl.WrongFormat are removed; .Url.WrongFormat has a new message, shipped in en_240.xml.
• Behavior for existing data is preserved by the 2.4 migration.

Testing

1. Install a fresh store over https and confirm Administration → Configuration → Stores → edit shows a single URL of the store field, with no SSL enabled checkbox and no Secure URL field.
2. Save the store with https://yourhost/. Open the Domains tab and confirm the primary domain's url matches, with a trailing /.
3. Request /sitemap.xml and confirm every <loc> uses https://yourhost/. Request /robots.txt and confirm the Sitemap: and Host: lines do too.
4. Place an order and check the queued order email — the store link and the product links must be https://.
5. Download the order PDF and confirm the store logo renders (it is fetched through the store url).
6. Try saving the store with yourhost (no scheme) and with ftp://yourhost/ — both must be rejected with the URL format message. http://localhost:5001/ must be accepted.
7. Upgrade path: take a 2.3 database whose store has SslEnabled: true and SecureUrl: "https://yourhost/" while Url is "http://yourhost/". Run the 2.4 upgrade and confirm Store.Url is now https://yourhost/, then re-check steps 3 and 4.
8. Confirm forcing HTTPS still works where it belongs: set Security.UseHttpsRedirection to true in appsettings.json, request the storefront over http, and confirm the 301 to https.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.