Skip to content

Add authentication toggles to IIS deploy step (Phase 3)

Placeholder ppxd requested to merge feat/iis-deploy-auth-toggles into main

Summary

  • The PS1 already had the appcmd.exe plumbing for the three IIS auth modes (Anonymous / Basic / Windows) — lines 433-435 read the flags, lines 778-806 commit them via appcmd set config /section:.../XAuthentication /enabled:<value> /commit:apphost. Phase 3 adds end-to-end coverage of the flag flow + verifies the IIS metabase actually reflects the configured state through real appcmd list config round-trip.
  • Windows CI install step expanded to include Web-Basic-Auth and Web-Windows-Auth Windows-features. Without them, appcmd set config /section:basicAuthentication errors out with "the configuration section 'basicAuthentication' cannot be read because it is missing a section declaration" — Anonymous comes with the base Web-WebServer feature, the other two don't.

What ships

Component Notes
Workflow update Install-WindowsFeature now adds Web-Basic-Auth,Web-Windows-Auth (idempotent; adds ~1m to install step)
Unit tests (9 new) Theory across true/false + case variants for each of the three flags; Build_AllThreeAuthFlagsSet_LandInPreambleIndependently Fact pins the independence of the three flags (guards against a regression where someone "helpfully" makes Anonymous default-true when Basic+Windows are false)
Pipeline-tier E2E (1 new Theory, 2 cases) Variable substitution: action property #{AnonEnabled} etc. resolves to operator's variable value BEFORE the builder serialises. Defence-in-depth ShouldNotContain("#{AnonEnabled}") so a partial-resolution regression surfaces
Real-host E2E (7 new tests, 🟢 high-fidelity) Theory across 6 realistic flag combinations (dev/enterprise/locked-down/wide-open) + idempotence-flip test (deploy 1 sets anon=true/win=false, deploy 2 flips to anon=false/win=true, both states verified via appcmd list config). Uses appcmd for round-trip readback (same tool the PS1 uses to set) so we see exactly the apphost-committed value, not an inherited one

Test plan

  • dotnet test --filter FullyQualifiedName~IISDeploy on macOS — 48 unit tests green (39 → 48, +9 auth tests)
  • dotnet test --filter Category=IISDeployE2E on macOS — 16 real-host tests skip cleanly via OS guard + per-test Web-Basic-Auth / Web-Windows-Auth feature probes (9 → 16, +7 auth tests)
  • dotnet build clean across Squid.UnitTests, Squid.E2ETests, Squid.WindowsTentacleE2ETests — 0 errors
  • CI run on windows-latest: install Basic+Windows auth modules, run new auth tests against real IIS, verify appcmd round-trip

Out of scope (future phases)

  • Phase 4: WebApplication + VirtualDirectory deployment types — toggles + PS1 branches exist (dormant in Phase 1+2+3), tests deferred
  • Cert-variable system: Octopus-style first-class cert variables (#{MyCert.Thumbprint}, #{MyCert.PfxData}). Squid doesn't have it yet; the certificateVariable field in HTTPS bindings JSON is preserved as a forward-compat passthrough.

Breaking-change risk

None. Tests are additive. Workflow change is additive (more feature installs). No public-API signatures changed. No PS1 functional change. No DB migration.

Merge request reports