Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DataProtection Keys folder doesn't sync on Azure Web Sites distribution slots #1582

Closed
tmm360 opened this issue Jun 18, 2016 · 1 comment
Closed

Comments

@tmm360
Copy link

tmm360 commented Jun 18, 2016

I'm running an Asp.Net Core RC2 application on Azure Web Sites, and I noted that every time that I switch staging and production environments, all users log off. So I've tried to test what happened, and I've discovered that on staging and production's "%HOME%\ASP.NET\DataProtection-Keys" folders the keys were different. Reading this page https://docs.asp.net/en/latest/security/data-protection/configuration/default-settings.html they should be synced.

I supposed that keys may be synced by slot, so when I switch slots the keys should keep under original environment. To test this I've created a new Azure web site with two new empty slots, but when I switch environments the "%HOME%\ASP.NET" folder follows its server. This implies that keys of staging are used under production, and keys of production are used under staging. I've discovered the origin of my issue.

Two options here: I didn't understand how DataProtection is synced between distribution slots, and in this case I'm asking you to tell me how I can solve this problem, or this is a bug and the sentence on documentation is wrong. What do you think? Thank you

@tmm360 tmm360 closed this as completed Dec 6, 2016
@guardrex
Copy link
Contributor

guardrex commented Dec 6, 2016

@tmm360 This looks like a good issue (that fell through the cracks). I suggest you re-open this in the docs repo issues at https://github.com/aspnet/Docs/issues and ping [@]blowdart on it.

natemcmaster pushed a commit that referenced this issue Nov 14, 2018
#1582).

- Changes the design to have one ConnectionHandler per endpoint.
natemcmaster pushed a commit that referenced this issue Nov 14, 2018
…ibuv (#1582).

- Put everything in the libuv transport package under `Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.*` namespaces.
- Move stuff in Transport.Libuv/Internal/Http and Transport.Libuv/Internal/Infrastructure to Transport.Libuv/Internal (keep the Networking directory for the libuv wrappers).
- Add `Libuv` prefix to most libuv internal classes.
- Rename `KestrelEngine` to `LibuvTransport`.
- Rename `SocketOutputConsumer` to `LibuvOutputConsumer`.
- Rename `SocketOutputProducer` to `OutputProducer`.
- Fix namespaces in `Microsoft.AspNetCore.Server.Kestrel.Core.`
dougbu pushed a commit to dotnet-maestro-bot/AspNetCore that referenced this issue Sep 11, 2019
Close https://github.com/aspnet/AspNetCore-Internal/issues/1573
Close https://github.com/aspnet/AspNetCore-Internal/issues/1572

The triage bot started opening issue for aspnet/websdk. Let's ignore these configs since these configs are owned by @vijayrkn's and they track work somewhere else.
@dotnet dotnet locked as resolved and limited conversation to collaborators Dec 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants