DEV Community: QueryWrangler

Silent Login Failures After Every Azure Deploy? Check Your Data Protection Keys

QueryWrangler — Tue, 07 Jul 2026 15:11:36 +0000

If your ASP.NET Core app on Azure App Service randomly logs everyone out — or breaks anti-forgery tokens — after every deployment or restart, and there's no error message telling you why, there's a good chance the culprit is where your Data Protection keys are stored.

The symptom

Everything works fine right after a deploy. Then, at some point — after a restart, a scale event, or the next deployment — users start getting logged out unexpectedly, or you see anti-forgery token validation failures with no obvious cause. There's no clear exception pointing at the real problem. Cookies just silently stop validating.

The wrong assumption

The natural assumption is that ASP.NET Core's Data Protection system — which encrypts things like auth cookies and anti-forgery tokens — just works out of the box in Azure App Service, the same way it does in local development.

By default, it doesn't persist the way you'd expect in a cloud hosting environment.

The actual cause

ASP.NET Core's Data Protection system generates a set of cryptographic keys used to protect cookies and tokens. If those keys aren't stored somewhere stable, every time the app restarts, scales out to another instance, or gets redeployed, it can end up with a different set of keys than before — which means anything encrypted with the old keys (existing auth cookies, anti-forgery tokens) suddenly fails to validate. Azure App Service's default file system behavior doesn't guarantee key persistence across these events the way a traditional single-server deployment would.

The fix

Explicitly persist the Data Protection keys to a stable location — the App Service's HOME directory works well, since it's persisted storage that survives restarts and deployments:

services.AddDataProtection()
    .PersistKeysToFileSystem(new DirectoryInfo(
        Environment.GetEnvironmentVariable("HOME") + @"\ASP.NET\DataProtection-Keys"))
    .SetApplicationName("YourAppName");

Setting an explicit ApplicationName is also worth doing — it keeps the key ring scoped correctly if you ever have multiple apps sharing the same underlying storage.

The broader lesson

Anywhere your ASP.NET Core app runs across multiple instances, restarts, or redeployments — which is essentially every cloud hosting scenario — Data Protection key persistence isn't optional, even though the framework won't warn you about it. The failure mode is especially nasty because there's no exception with a clear cause; it just looks like intermittent, unexplainable auth problems. If you're seeing silent logouts or anti-forgery failures that seem to correlate with deploys or restarts, this is the first place to look.

5 Lessons from Migrating a Legacy WPF Desktop App to the Cloud

QueryWrangler — Tue, 07 Jul 2026 15:08:27 +0000

Migrating a legacy WPF desktop application to a cloud-based web platform is one of those projects that sounds straightforward in a planning meeting and turns out to be full of quiet traps in practice. Here are the lessons that mattered most.

1. The old app's UI logic is really business logic in disguise

Desktop apps built over many years tend to accumulate business rules directly inside event handlers and code-behind — validation, workflow decisions, calculations — because there was never a strong reason to separate them. When you move to the web, you can't just "reskin" the UI; you have to excavate the actual business logic buried inside years of button-click handlers first. Budget real time for this. It's usually much bigger than it looks from the outside.

2. Feature parity is a moving target, not a checklist

It's tempting to treat migration as "make the new thing do everything the old thing did." In practice, users only really tell you about the features they use after they hit a gap in the new system. Plan for an extended period of "wait, we also need X" discoveries, even after what felt like thorough requirements gathering.

3. Authentication and session models don't translate directly

A desktop app running under a Windows user's identity has a completely different security model than a web app serving many concurrent users over HTTP. Single sign-on, token-based auth, and session/state management all need to be rebuilt from first principles — not adapted from whatever the desktop app was doing, because in most cases it wasn't doing anything comparable at all.

4. Your database becomes a shared, concurrent resource for the first time

Desktop apps often assume single-user or low-concurrency access patterns, even when technically pointed at a shared backend. Moving to the web means real concurrent access, and that surfaces problems the old app never had to deal with — race conditions, locking assumptions, and queries that were "fast enough" for one user at a time but not for many.

5. The migration is also a chance to fix years of small compromises

Every legacy system carries small workarounds — a field repurposed for something it wasn't meant for, a status value that means three different things depending on context. Migration forces you to look directly at these because you have to explain them to a new codebase. Treat that as an opportunity, not just overhead: cleaning up a handful of these quietly pays for itself many times over during the life of the new system.

The takeaway

A desktop-to-cloud migration is rarely just a technology swap. It's an opportunity to separate business logic from UI, rebuild security properly for a multi-user world, and confront the small inherited compromises that never got addressed the first time around. The projects that go well treat it as an architectural rewrite with a familiar UI on top — not a lift-and-shift with a new coat of paint.

JWT Validation Against an RSA Public Key: The ValidAlgorithms Gotcha

QueryWrangler — Tue, 07 Jul 2026 15:06:10 +0000

If you're validating JWTs signed with RSA in .NET and getting a signature validation failure even though you're certain the public key is correct, there's a good chance the problem isn't your key at all — it's how you've configured ValidAlgorithms.

The symptom

You set up token validation like this:

var validationParameters = new TokenValidationParameters
{
    ValidateIssuerSigningKey = true,
    IssuerSigningKey = rsaSecurityKey,
    ValidAlgorithms = new[] { "RS256" },
    // ...other parameters
};

The public key is correct. You've verified it against the signing certificate. And yet token validation still fails with a signature error, as if the key were wrong.

The wrong assumption

The natural assumption is that "RS256" is "RS256" — a single, standard algorithm identifier that any RSA-signed JWT will use, and any validator will recognize.

Not every token issuer sends that identifier in the same format.

The actual cause

Some identity providers — particularly older or WCF-based token services — express the signing algorithm as a full URI rather than the short JWT-standard name. Instead of "RS256", the token's header may specify something like "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256". If your ValidAlgorithms list only contains the short-form name, tokens signed with the URI-form algorithm identifier get rejected outright — even though the actual cryptographic signature is completely valid.

The fix

Include both the short-form and URI-form algorithm identifiers in ValidAlgorithms:

var validationParameters = new TokenValidationParameters
{
    ValidateIssuerSigningKey = true,
    IssuerSigningKey = rsaSecurityKey,
    ValidAlgorithms = new[]
    {
        "RS256",
        "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"
    },
    // ...other parameters
};

Once both forms are present, tokens get validated correctly regardless of which identifier format the issuing service used to describe its signing algorithm.

The broader lesson

If you're integrating JWT validation with an identity provider you don't fully control — especially anything with roots in WCF or older enterprise SSO systems — don't assume the algorithm identifier will always arrive in the modern short form. Check the actual token header (a JWT decoder makes this trivial) before assuming your key or your validation logic is at fault. A "signature invalid" error can be entirely about algorithm identifier mismatch, with the signature itself being perfectly fine.

Getting Auto-Generated IDs Back from Oracle in .NET: The RETURNING INTO Trap

QueryWrangler — Tue, 07 Jul 2026 15:01:07 +0000

If you've ever inserted a row into Oracle from .NET and needed the auto-generated ID back immediately — say, to use in a follow-up insert — you've probably reached for RETURNING INTO. And you've probably also hit a confusing type mismatch or invalid cast error trying to read the value back out. Here's why, and the fix that actually works.

The symptom

You write an insert like this:

var cmd = connection.CreateCommand();
cmd.CommandText = "INSERT INTO MY_TABLE (NAME) VALUES (:p_name) RETURNING ID INTO :p_id";
cmd.Parameters.Add(new OracleParameter("p_name", name));

var idParam = new OracleParameter("p_id", OracleDbType.Int32, ParameterDirection.Output);
cmd.Parameters.Add(idParam);

cmd.ExecuteNonQuery();

int newId = (int)idParam.Value; // <-- blows up here

It compiles fine. It runs without SQL errors. And then the cast to int throws — or worse, silently gives you a value that doesn't behave the way you expect.

The wrong assumption

The natural assumption is that an Oracle NUMBER column maps cleanly to a .NET int or decimal, the same way it would with most other databases — declare the output parameter type, cast the result, done.

Oracle's NUMBER type doesn't map that simply through OracleDbType.Int32.

The actual cause

Oracle's NUMBER type is really a variable-precision decimal, not a fixed-width integer. When you bind an output parameter as OracleDbType.Int32, you're asking ODP.NET to coerce Oracle's native numeric representation into a shape it doesn't naturally fit — which is where the cast failures and unexpected values creep in, especially once IDs get large or the underlying sequence has any quirks.

The fix

Bind the output parameter as OracleDbType.Decimal, and cast through OracleDecimal instead of straight to int:

var cmd = connection.CreateCommand();
cmd.CommandText = "INSERT INTO MY_TABLE (NAME) VALUES (:p_name) RETURNING ID INTO :p_id";
cmd.Parameters.Add(new OracleParameter("p_name", name));

var idParam = new OracleParameter("p_id", OracleDbType.Decimal, ParameterDirection.Output);
cmd.Parameters.Add(idParam);

cmd.ExecuteNonQuery();

OracleDecimal oracleId = (OracleDecimal)idParam.Value;
int newId = oracleId.ToInt32(); // clean, safe conversion

Going through OracleDecimal respects Oracle's actual numeric type instead of fighting it, and gives you a safe, explicit path to whatever .NET type you actually need afterward.

The broader lesson

Any time you're pulling a value back out of Oracle via RETURNING INTO, default to OracleDbType.Decimal for numeric columns and cast through OracleDecimal, rather than assuming a direct match to Int32 or Int64. It's a small pattern, but it's the difference between a clean insert-and-return flow and a cryptic runtime cast exception that has nothing to do with your actual logic.

The ORA-01008 Trap: Why Your Oracle .NET Bind Variables Keep Failing

QueryWrangler — Tue, 07 Jul 2026 14:59:45 +0000

If you've worked with Oracle.ManagedDataAccess in .NET and hit ORA-01008: not all variables bound on a query that looks completely correct, you're not alone. This one cost me hours across a service with two dozen separate database calls — and the fix, once you see it, is almost embarrassingly simple.

The symptom

You write a query like this:

var cmd = connection.CreateCommand();
cmd.CommandText = "SELECT * FROM MY_TABLE WHERE ID = :p_id AND STATUS = :p_status";
cmd.Parameters.Add(new OracleParameter("p_id", id));
cmd.Parameters.Add(new OracleParameter("p_status", status));

It looks right. The parameter names match the bind variables. And yet: ORA-01008: not all variables bound.

The wrong assumption

The natural assumption is that Oracle matches parameters to bind variables by position — same as it would with a plain ADO.NET provider talking to SQL Server. So if you've added your parameters in the same order they appear in the SQL, you'd expect it to just work.

Oracle.ManagedDataAccess doesn't default to that behavior.

The actual cause

By default, OracleCommand in Oracle.ManagedDataAccess binds parameters by position, not by name — but only if you don't explicitly say otherwise. The moment your parameter count or order drifts even slightly from the SQL text (which happens easily once queries get edited, reordered, or grow additional conditions over time), the binding silently breaks, and you get ORA-01008.

The fix

Set BindByName = true explicitly on every command:

var cmd = connection.CreateCommand();
cmd.CommandText = "SELECT * FROM MY_TABLE WHERE ID = :p_id AND STATUS = :p_status";
cmd.BindByName = true; // <-- this line saves you hours
cmd.Parameters.Add(new OracleParameter("p_id", id));
cmd.Parameters.Add(new OracleParameter("p_status", status));

Once BindByName = true is set, Oracle matches parameters to bind variables by their names, not their position — which matches how everyone actually reads and writes the SQL. Order stops mattering.

The broader lesson

If you're working with Oracle.ManagedDataAccess in any non-trivial .NET application, make BindByName = true a non-negotiable line in every single command — consider wrapping it into a base helper or extension method so it's impossible to forget. One missed instance in a codebase with dozens of Oracle calls is all it takes to lose an afternoon to a cryptic error that has nothing to do with your actual SQL.