You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Changed the default auth provider from SWA to AppService (#2943)
## Why make this change?
- Closes [#2943](#2644)
Change default auth provider to AppService from StaticWebApps. Azure
Static Web Apps EasyAuth is being deprecated, so DAB should no longer
default to
[StaticWebApps](vscode-file://vscode-app/c:/Program%20Files/Microsoft%20VS%20Code/resources/app/out/vs/code/electron-browser/workbench/workbench.html)
as its authentication provider.
- Moving the default to `AppService` aligns DAB with the long‑term
supported `EasyAuth` path while keeping behavior equivalent for existing
workloads. `StaticWebApps` remains supported when explicitly configured,
but new configurations and `dab init` flows should guide users toward
`AppService` instead of a deprecated option.
## What is this change?
-Config and runtime behavior
- Changed the default authentication provider from `Static Web Apps` to
`App Service` in the core configuration model and JSON schema.
- Added validation that logs a warning when Static Web Apps is
explicitly selected (since it’s deprecated as a default).
-CLI and `dab init`
- Updated `dab init` so that, when no auth provider is specified, it now
generates configs using App Service as the provider instead of Static
Web Apps.
- Adjusted CLI configuration generation and option handling so any
“default provider” usage now points to App Service.
- Updated end-to-end CLI tests and initialization tests so their
expected configurations and arguments reference App Service as the
default.
-Schema, samples, and built‑in configs
- Updated the JSON schema to set the default of the
`authentication.provider` property to `AppService`.
- Updated sample configuration snippets in the main documentation to
show App Service as the provider.
- Updated the built‑in `dab-config` JSON files (for all supported
databases and multi‑DAB scenarios) so their runtime host sections use
App Service.
-Engine tests and helpers
- Updated test helpers to generate EasyAuth principals appropriate for
the configured provider, and to treat App Service as the default in REST
and GraphQL integration tests.
- Adjusted configuration and health‑endpoint tests to no longer assume
Static Web Apps as the implicit provider and to accept App Service as
the default.
-Snapshots and expected outputs
- updated a large set of snapshot files (CLI snapshots, configuration
snapshots, entity update/add snapshots) so that anywhere the
authentication section previously showed Static Web Apps as the
provider, it now shows App Service.
-Note
We updated `AddEnvDetectedEasyAuth` so that it always registers both the
`App Service` and `Static Web Apps` `EasyAuth` schemes in development
mode, instead of only adding App Service when certain environment
variables are present. This aligns with the new default of using App
Service as the primary `EasyAuth` provider and makes dev/test/CI
behavior deterministic, while still letting configuration
(runtime.host.authentication.provider) choose which scheme is actually
used.
## How was this tested?
- [x] Integration Tests
- [x] Unit Tests
## Sample Request(s)
`dab init --database-type mssql --connection-string "<conn-string>"`
Generates,
`"runtime": {
"host": {
"authentication": {
"provider": "AppService"
}
}
}`
Users who still want Static Web Apps can override:
`dab init --database-type mssql --connection-string "<conn-string>"
--auth.provider StaticWebApps`
---------
Co-authored-by: Aniruddh Munde <[email protected]>
Co-authored-by: Souvik Ghosh <[email protected]>
Co-authored-by: aaronburtle <[email protected]>
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Anusha Kolan <[email protected]>
0 commit comments