In support of [EPIC] Revisiting HTTPS defaults in ASP.NET Core
Update templates so that (asuming the --no-https option is false) two launch profiles are configured in the project's launchSettings.json file:
- The first, named "http" and configured with the
ApplicationUrls property set to just a non-HTTPS address
"http": {
"commandName": "Project",
"dotnetRunMessages": true,
"launchBrowser": true,
"applicationUrl": "http://localhost:5227",
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development"
}
}
- The second, named "https", and configured with the
ApplicationUrls property set to the usual two addresses, the first being HTTPS, the second being HTTP:
"https": {
"commandName": "Project",
"dotnetRunMessages": true,
"launchBrowser": true,
"applicationUrl": "https://localhost:7227;http://localhost:5227",
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development"
}
}
Selecting an auth option of anything other than None or Indvidual in relevant templates will still force HTTPS like today & only create a single launch profile due to issues with these auth schemes use of cookies and SameSite.
The Angular & SPA templates that utilize the SpaProxy are currently authored in such a way that only HTTPS works (irrespective of the auth option) so they wouldn't be changed.
When launching this project at the command line using dotnet run or dotnet watch, the default profile selected will be the first profile, which is not configured to use HTTPS, and as such the application will start without attempting to bind to HTTPS and thus not attempt to load the dev cert (which causes UX friction issues esp. on non-Windows systems). The HTTPS profile can be selected at launch time by passing --launch-profile <launch-profile> to dotnet run, e.g.:
$ dotnet run --launch-profile https"
We can we make this experience simpler by introducing an option alias for the --launch-profile option, e.g.:
The project will continue to have the HTTPS-aware code present so the project is ready for use with HTTPS.
Folks using VS/VSforMac will continue to get the experience they do today as we'll adjust the default logic there to select the launch profile set to use both HTTPS and HTTP and launching directly into the HTTPS address.
In support of [EPIC] Revisiting HTTPS defaults in ASP.NET Core
Update templates so that (asuming the
--no-httpsoption is false) two launch profiles are configured in the project'slaunchSettings.jsonfile:ApplicationUrlsproperty set to just a non-HTTPS addressApplicationUrlsproperty set to the usual two addresses, the first being HTTPS, the second being HTTP:Selecting an auth option of anything other than None or Indvidual in relevant templates will still force HTTPS like today & only create a single launch profile due to issues with these auth schemes use of cookies and SameSite.
The Angular & SPA templates that utilize the
SpaProxyare currently authored in such a way that only HTTPS works (irrespective of the auth option) so they wouldn't be changed.When launching this project at the command line using
dotnet runordotnet watch, the default profile selected will be the first profile, which is not configured to use HTTPS, and as such the application will start without attempting to bind to HTTPS and thus not attempt to load the dev cert (which causes UX friction issues esp. on non-Windows systems). The HTTPS profile can be selected at launch time by passing--launch-profile <launch-profile>todotnet run, e.g.:We can we make this experience simpler by introducing an option alias for the
--launch-profileoption, e.g.:The project will continue to have the HTTPS-aware code present so the project is ready for use with HTTPS.
Folks using VS/VSforMac will continue to get the experience they do today as we'll adjust the default logic there to select the launch profile set to use both HTTPS and HTTP and launching directly into the HTTPS address.