DEV Community: Mahmood Al Sarraj

Monitor and Manage Redis Without Ever Leaving Your ASP.NET Core Dashboard

Mahmood Al Sarraj — Sun, 13 Sep 2026 18:10:06 +0000

No RDM. No separate Redis GUI. No _redis-cli KEYS *_ against production.

In my last article, I showed how AsGuard drops a live request and exception dashboard into any ASP.NET Core app with four lines of config. This one covers what happens after someone on your team asks: “can we also see what’s actually in Redis?”

You already have Redis wired into your app somewhere — session state, a distributed cache, a rate limiter. And you probably already have a terminal tab open with redis-cli, typing KEYS user:* and hoping nobody notices the instance hang for a second.

That command is the problem. KEYS blocks the entire Redis server for as long as it takes to walk every key. On a small dev instance you won't notice. On a production cache with a few million keys, you just caused an incident.

AsGuard ships a Redis tab inside the dashboard you already have — and if AsGuard is already in your app for request and exception logging, turning it on costs one line.

What “Wiring Redis Into AsGuard” Actually Means

AsGuard doesn’t stand up a new service, a new port, or a new login screen. It adds a Redis tab to the dashboard you’re already authenticated into. That tab gives you:

A key browser that pages through your keyspace with SCAN — never KEYS
A value inspector and editor for String, Hash, List, Set, and Sorted Set types
TTL viewing and editing
Live server stats (memory, ops/sec, hit rate, clients) streamed over the same SSE connection the rest of the dashboard already uses

It’s opt-in. Every other AsGuard feature defaults to on. Redis management defaults to off, because it’s the one module that touches your application’s actual data instead of just observability data.

Step 1 — Turn It On

If AsGuard is already in your app, this is the entire integration:

builder.Services.AddRequestLogging(options =>
{
    options.DatabaseProvider = LoggingDatabaseProvider.Sqlite;
    options.ConnectionString = "Data Source=asguard.db";
    options.DashboardUsername = "ops";
    options.DashboardPassword = builder.Configuration["AsGuard:Password"]!;options.EnableRedisManagement = true;
});

No Redis connection string to type in. No second set of credentials. Which raises the obvious question.

Step 2 — Where Does It Get Your Redis Connection From?

AsGuard reuses the connection your app already built. It never asks you to configure Redis twice.

If you’ve registered a StackExchange.Redis IConnectionMultiplexer in DI — which almost every ASP.NET Core app wiring up Redis already does — AsGuard finds it automatically the first time you open the tab:

// Your existing Redis registration — nothing AsGuard-specific here
builder.Services.AddSingleton<IConnectionMultiplexer>(sp =>
    ConnectionMultiplexer.Connect("localhost:6379"));
builder.Services.AddRequestLogging(options =>
{
    options.EnableRedisManagement = true;
});

Discovery runs once, lazily, on first use, and checks several places in order:

**IAsGuardRedisConnectionProvider** in DI — custom connection abstractions AsGuard can't see any other way: token-refreshing wrappers (e.g. Entra ID), multi-tenant multiplexers.
**IConnectionMultiplexer** in DI — the common case: AddSingleton<IConnectionMultiplexer>, or Aspire's AddRedisClient.
Keyed **IConnectionMultiplexer** — Aspire's AddKeyedRedisClient("cache"), or multiple named instances.
**AddStackExchangeRedisCache(...)** — apps that only wired up IDistributedCache, nothing lower-level.
**options.RedisConnections** — no Redis client registered anywhere; AsGuard builds its own.

Every rung is additive and fault-isolated: if one source is misconfigured, it doesn’t take the others down with it. AsGuard also never disposes or reconfigures a connection it borrows from rungs 1 through 4 — closing your application’s own multiplexer to satisfy a dashboard tab would be a worse bug than the one you’re trying to fix.

Rung 1 is the escape hatch, and it’s the one you actually need if your app doesn’t hold a plain IConnectionMultiplexer in DI. If you connect to Redis through your own abstraction — a wrapper that lazily authenticates (say, against Azure Cache for Redis via Microsoft Entra ID, where there's a token to refresh instead of a static password) or picks an endpoint per tenant — implement the interface and hand AsGuard the multiplexer once it's built:

internal sealed class AsGuardRedisConnectionProvider : IAsGuardRedisConnectionProvider
{
    private readonly RedisConnectionProvider _connectionProvider;
    private readonly RedisOptions _options;
    public AsGuardRedisConnectionProvider(RedisConnectionProvider connectionProvider, IOptions<RedisOptions> options)
    {
        _connectionProvider = connectionProvider;
        _options = options.Value;
    }
    public IEnumerable<AsGuardRedisConnection> GetConnections()
    {
        if (!_connectionProvider.IsConfigured)
        {
            return [];
        }
        var multiplexer = _connectionProvider.GetAsync().GetAwaiter().GetResult();
        var name = string.IsNullOrWhiteSpace(_options.KeyPrefix) ? "matensa" : _options.KeyPrefix;
        return [new AsGuardRedisConnection(name, multiplexer)];
    }
}
builder.Services.AddSingleton<IAsGuardRedisConnectionProvider, AsGuardRedisConnectionProvider>();

Two things worth calling out. First, GetConnections() is synchronous by contract, but acquiring an Entra token is inherently asynchronous — blocking on GetAwaiter().GetResult() is fine here specifically because discovery runs lazily, once, on the first dashboard request, and the result is cached for the process lifetime. It never blocks startup and never blocks a real user request. Second, returning an empty sequence when the provider isn't configured is deliberate: AsGuard reports "no connection discovered" instead of the dashboard implying a Redis nobody is actually using.

Nothing registered yet? Rung 5 covers that — a plain connection string with no DI abstraction at all:

options.RedisConnections.Add(new RedisConnectionDescriptor
{
    Name = "sessions",
    ConnectionString = "localhost:6379,ssl=False"
});

Why This Matters More Than It Looks: Azure Cache With Entra ID

If your Redis is Azure Cache for Redis authenticated via Microsoft Entra ID, there’s no password to put in a connection string. The multiplexer authenticates with a short-lived access token that your app’s startup code refreshes on a timer, configured directly on a ConfigurationOptions object.

A connection string can’t reconstruct that. Reusing the multiplexer your app already built and already keeps authenticated is the only thing that works — which is exactly why AsGuard checks DI before it ever looks at a connection string.

Step 3 — Browse Keys Safely

Open the Redis tab, pick a connection, and page through keys. A few things happen under the hood that you’d otherwise have to build yourself:

Enumeration uses SCAN with cursor-based paging — never KEYS. AsGuard even checks the server version at connect time and refuses to enumerate on anything old enough that StackExchange.Redis would silently fall back to KEYS.
Type and TTL for each row are pipelined in a single round trip batch, so a 100-key page doesn’t cost you 200+ requests.
Binary keys (not valid UTF-8) show up base64-encoded instead of being mangled or hidden.

Click into any key to inspect and edit it. Strings, hashes, lists, sets, and sorted sets are all supported, with a MATCH filter for large hashes and sets, and a byte cap so one giant value can't blow up the dashboard.

options.MaxRedisValueBytes = 262_144; // default: 256 KB, larger values become read-only
options.RedisScanPageSize = 100;      // keys per SCAN round trip

Locking It Down for Production

Three settings decide how far the Redis tab can reach once it’s live:

options.EnableRedisManagement = true;
options.RedisManagementReadOnly = true;   // browse only — no edits, deletes, or flushes
options.AllowRedisFlushDatabase = false;  // FLUSHDB stays off unless you explicitly opt in

RedisManagementReadOnly is enforced server-side, in the same code path every mutating operation passes through — hiding the edit buttons in the UI is cosmetic on top of that, not the actual gate. And FLUSHDB, if you ever turn it on, requires the connection to have been built with allowAdmin=true by your own application code, plus a typed confirmation phrase on the request body naming the exact database. AsGuard never issues FLUSHALL, and there's no bulk pattern-delete — a mistyped filter against production shouldn't be a one-click mistake.

What You Get for Free

Because the Redis tab lives inside the dashboard you already authenticated into, it also inherits:

CSRF protection on every mutating request
Live server stats (memory, ops/sec, hit rate, connected clients, eviction rate) streamed over the dashboard’s existing SSE connection — no second polling loop, no extra background service

The stats sampler is demand-driven too. If nobody has the tab open, AsGuard isn’t quietly polling INFO against your Redis server every few seconds for no one.

Try It

If you already have AsGuard installed:

options.EnableRedisManagement = true;

If you don’t yet:

dotnet add package AsGuard

Then follow the Quick Setup in the README, add the line above, and open the Redis tab next to your request logs.

Full reference: docs/redis-management.md

GitHub: mahmood-alsarraj/asguard

If this saved you from typing _KEYS *_ in production one more time, give the repo a star.

[Boost]

Mahmood Al Sarraj — Sun, 09 Aug 2026 10:25:12 +0000

Mahmood Al Sarraj

Aug 9

Stop Letting Bots Register Accounts: Add Cloudflare Turnstile to Your .NET App

#dotnet #security #webdev #api

3 min read

Stop Letting Bots Register Accounts: Add Cloudflare Turnstile to Your .NET App

Mahmood Al Sarraj — Sun, 09 Aug 2026 10:23:17 +0000

Your signup form sends an SMS OTP. Each one costs you a few cents.

A bot loops POST /api/register with a rotating IP pool and throwaway numbers, and you pay for every message. Registration is the one endpoint you leave open to strangers — no auth, no API key, no rate limit that survives a fresh IP. It's the only place where someone else can spend your money in a loop.

Cloudflare Turnstile closes it. Free, invisible to most users, and it works even if your site doesn’t sit behind Cloudflare: the widget issues a token, and your backend asks Cloudflare whether that token is real.

That second half is the whole thing. A token you never verify server-side is decoration.

Step 1: Create the widget

Sign in at dash.cloudflare.com, open Turnstile, click Add Widget.
Hostnames: your domain, plus localhost for testing.
Widget mode: Managed, it decides per visitor whether to show anything.
Create, then copy the Site Key and Secret Key.

The site key is public. The secret key is not, keep it out of appsettings.json:

dotnet user-secrets set "Turnstile:SecretKey" "YOUR_SECRET_KEY"

In production it belongs in Key Vault or your platform’s equivalent.

Step 2: Add the widget to your form

<script src="https://challenges.cloudflare.com/turnstile/v0/api.js" async defer></script>
<form method="post" action="/api/register">
  <input name="email" type="email" required />
  <input name="password" type="password" required />
  <div class="cf-turnstile" data-sitekey="YOUR_SITE_KEY" data-theme="auto"></div>
  <button type="submit">Create account</button>
</form>

The widget injects a hidden field named cf-turnstile-response. On a SPA, read it with turnstile.getResponse() and send it as a header.

Step 3: Verify on the server

One reusable service, not an inline call in your handler:

private sealed record TurnstileResult
{
    [JsonPropertyName("success")] public bool Success { get; init; }
    [JsonPropertyName("error-codes")] public string[]? ErrorCodes { get; init; }
    [JsonPropertyName("hostname")] public string? Hostname { get; init; }
    [JsonPropertyName("challenge_ts")] public string? ChallengeTs { get; init; }
}
public sealed class TurnstileVerifier(
    HttpClient http,
    IOptions<TurnstileOptions> options,
    ILogger<TurnstileVerifier> logger)
{
    private const string VerifyUrl =
        "https://challenges.cloudflare.com/turnstile/v0/siteverify";
    public async Task<bool> IsHumanAsync(
        string? token, string? remoteIp, CancellationToken ct = default)
    {
        if (string.IsNullOrWhiteSpace(token))
            return false;
        var payload = new Dictionary<string, string>
        {
            ["secret"] = options.Value.SecretKey,
            ["response"] = token
        };
        if (!string.IsNullOrWhiteSpace(remoteIp))
            payload["remoteip"] = remoteIp;
        using var response = await http.PostAsync(
            VerifyUrl, new FormUrlEncodedContent(payload), ct);
        if (!response.IsSuccessStatusCode)
        {
            // Cloudflare unreachable — fail closed, on purpose.
            logger.LogWarning("Turnstile unavailable: {Status}", response.StatusCode);
            return false;
        }
        var result = await response.Content
            .ReadFromJsonAsync<TurnstileResult>(cancellationToken: ct);
        return result?.Success == true;
    }
}

builder.Services.Configure<TurnstileOptions>(
    builder.Configuration.GetSection("Turnstile"));
builder.Services.AddHttpClient<TurnstileVerifier>(c =>
    c.Timeout = TimeSpan.FromSeconds(5));

Step 4: Guard the endpoint

public sealed class TurnstileFilter(TurnstileVerifier verifier) : IEndpointFilter
{
    public async ValueTask<object?> InvokeAsync(
        EndpointFilterInvocationContext ctx, EndpointFilterDelegate next)
    {
        var req = ctx.HttpContext.Request;
        var token = req.Headers["cf-turnstile-response"].FirstOrDefault()
            ?? (req.HasFormContentType
                ? req.Form["cf-turnstile-response"].FirstOrDefault()
                : null);
        var ip = req.Headers["CF-Connecting-IP"].FirstOrDefault()
            ?? ctx.HttpContext.Connection.RemoteIpAddress?.ToString();
        if (!await verifier.IsHumanAsync(token, ip, ctx.HttpContext.RequestAborted))
            return Results.Problem("Human verification failed",
                statusCode: StatusCodes.Status403Forbidden);
        return await next(ctx);
    }
}

app.MapPost("/api/register", RegisterHandler)
   .AddEndpointFilter<TurnstileFilter>();

One line per endpoint. On MVC, the same logic fits into an IAsyncActionFilter behind a [VerifyHuman] attribute.

Three things that will bite you

Tokens are single-use and expire in about five minutes. A retry with the same token fails — call turnstile.reset() on error.

Pick your failure mode deliberately. If Cloudflare is unreachable, do you block signups or let them through? Payments product: fail closed. Newsletter: fail open. The wrong answer is not having thought about it.

Turnstile is not a rate limiter. It answers “human?”, not “how many times?”. Keep your rate limiting — Turnstile removes the cheap, high-volume noise, which is most of it.

For CI, Cloudflare publishes dummy keys: site key 1x00000000000000000000AA passes and 2x00000000000000000000AB blocks; secret 1x0000000000000000000000000000000AA passes and 2x0000000000000000000000000000000AA fails. Write the failing test first.

Registration, password reset, OTP resend — anything a script can call a thousand times at your expense.

A few minutes of work, and you stop paying for other people’s loops.

Add a Live Observability Dashboard to Your ASP.NET Core App in 5 Minutes — No External Services Needed

Mahmood Al Sarraj — Mon, 29 Jun 2026 14:56:34 +0000

No Grafana. No Datadog. No YAML. Just visibility.

You've shipped your ASP.NET Core API. It's live. And then your product manager pings you: "Something seems slow - can you check?"

You open the logs. Wall of text. No correlation IDs. No timing. No idea which request threw that exception at 2 AM.
Sound familiar?

That's the problem AsGuard solves.

What Is AsGuard?

AsGuard is a lightweight NuGet package that plugs directly into your ASP.NET Core middleware pipeline and gives you:

Full HTTP request/response logging with timing, method, status, and body capture
Exception tracking with stack traces, severity, and trends - no Sentry account required
Host ILogger capture - your existing LogWarning and LogError calls get stored and searchable
A built-in live dashboard with dark/light mode, SSE-powered real-time updates, and filtering

The entire thing runs inside your app. No external services. No Docker compose file with six containers. No licensing tiers. Just a NuGet package and four lines of configuration.

Getting It Running (For Real, Under 5 Minutes)

Step 1 - Install the package

dotnet add package AsGuard

Step 2 - Configure in Program.cs

using AsGuard.Extensions;
using AsGuard.Domain.RequestLogging;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRequestLogging(options =>
{
    options.DatabaseProvider = LoggingDatabaseProvider.Sqlite;
    options.ConnectionString = "Data Source=asguard.db";
    options.DashboardRoute = "/logs";
    options.DashboardUsername = builder.Configuration["AsGuard:Username"] ?? "admin";
    options.DashboardPassword = builder.Configuration["AsGuard:Password"] ?? "change-me";
    options.EnableExceptionLogging = true;
    options.CaptureHostLogs = true;
    options.LogResponseBody = true;
    options.LogRequestBody = true;
});
var app = builder.Build();

Step 3 - Register the middleware

The placement matters. Add UseRequestLogging() after HTTPS/CORS but before auth and your endpoints:

app.UseHttpsRedirection();
app.UseExceptionHandler();
app.UseRequestLogging(); // ← right here
app.UseAuthentication();
app.UseAuthorization();
app.MapControllers();
app.Run();

Step 4 - Hit the dashboard
Run your app, open a browser, and navigate to:

https://localhost:<port>/logs

Enter your credentials and you'll see a live dashboard with every request your app has handled. That's it.

The Middleware Order Actually Matters

One gotcha worth knowing upfront: where you place UseRequestLogging() in the pipeline determines what gets captured.

[HTTP Request In]
       │
       ▼
┌──────────────────────┐
│ Exception Handler    │  ← register first so AsGuard can intercept exceptions
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│ HTTPS / CORS / HSTS  │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│  UseRequestLogging() │  ← HERE: correlation IDs generated, body stream opened
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│  Auth & Authorization│  ← 401s and 403s will still be logged
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│  Your Endpoints      │
└──────────────────────┘

Placing it after auth means you lose logs for unauthorized requests. Placing it before exception handlers means unhandled exceptions won't have their HTTP context correctly linked. The order shown above gets you everything.

Choosing a Database

AsGuard supports four providers out of the box:

SQLite - zero setup, file-based; perfect for local dev, small apps, and quick demos
SQL Server - the natural fit for production on Azure or Windows-hosted workloads
PostgreSQL - ideal for Linux environments and cloud-native stacks
In-Memory - no persistence, no config; great for integration tests and ephemeral environments

Switching is one line:

// PostgreSQL
options.DatabaseProvider = LoggingDatabaseProvider.PostgreSql;
options.ConnectionString = "Host=localhost;Database=asguard;Username=postgres;Password=pass";
// In-Memory (no persistence, great for tests)
options.DatabaseProvider = LoggingDatabaseProvider.InMemory;
options.MaxInMemoryEntries = 10000;

No migrations to run manually. AsGuard auto-creates its tables on startup.

Masking Sensitive Data

If you capture request bodies (and you should, for debugging), you don't want passwords showing up in your log viewer. AsGuard gives you two ways to handle this.
Per-property attribute:

public class LoginRequest
{
    public string Username { get; set; }
    [AsGuardMasked]
    public string Password { get; set; } // stored as "[REDACTED]"
}

Global key list in config:

options.SensitiveBodyKeys.Add("creditCardNumber");
options.SensitiveBodyKeys.Add("ssn");
options.SensitiveBodyKeys.Add("token");

This runs at the middleware level before anything hits the database - you're never storing what you shouldn't.

What You'll Actually Use It For

Debugging slow requests in development

The request log view shows method, path, status code, and duration for every call. You can filter by status, search by path, and click into any row to see the full request/response bodies, headers, and the correlation ID chain.

Tracking down production exceptions

Exception logging captures the full stack trace, the HTTP context it occurred in, the severity, and when it happened. The dashboard includes trend charts so you can see if your error rate just spiked after a deploy.

Capturing ILogger output

With CaptureHostLogs = true, any LogWarning or LogError your existing services emit gets stored alongside the HTTP logs. You don't need to change a single line of your existing logging code - AsGuard just intercepts the host ILogger pipeline.

APM for EF Core and HttpClient

AsGuard auto-instruments EF Core queries and outbound HttpClient calls, showing them as Gantt-style trace timelines per request. If one endpoint is slow because it's firing 12 database queries, you'll see exactly which ones and how long each took.

Seeing what's live, right now

The dashboard uses Server-Sent Events for real-time updates - no page refresh, no polling interval to configure. While you're load testing or manually poking an endpoint, the request log updates in front of you.

Production Notes

A few things to know before deploying:

Change the default credentials. AsGuard actively rejects the literal string "admin" as a username. Store credentials in environment variables or user secrets:

# environment variable approach
ASGUARD__USERNAME=your_secure_user
ASGUARD__PASSWORD=your_secure_password

The write path is non-blocking. AsGuard uses a queue-based architecture - logs are written to an in-process channel and flushed asynchronously. Your API response times are not affected by database write latency.

Set up retention policies. For high-traffic apps, configure auto-cleanup so the log table doesn't grow unbounded:

options.RetentionDays = 30;

SQLite is fine for low-to-medium traffic. For anything handling hundreds of requests per second in production, switch to PostgreSQL or SQL Server.

The Bigger Picture

Most .NET teams reach for Sentry for exceptions, Datadog or Azure Monitor for metrics, and a custom Kibana setup for logs. That's three services, three SDKs, three dashboards, and three monthly bills.

AsGuard doesn't replace that stack for large-scale production systems. But for the majority of apps - internal tools, SaaS products under 100k requests/day, staging environments, side projects - it gives you 80% of the observability value at 0% of the infrastructure overhead.

Install it in your existing app today and you'll have a searchable, live view of every request and exception by the time your coffee's ready.

GitHub: mahmood-alsarraj/asguard
NuGet: nuget/AsGuard

If this saved you a debugging session, give the repo a star ⭐ - it helps.