Istanbul

ResearchCave.PasswordProtect (1.1.48)

Published 2026-07-28 15:45:59 +03:00 by admin

Set up this registry from the command line:

dotnet nuget add source --name ResearchCave --username your_username --password your_token http://git.researchcave.com/api/packages/ResearchCave/nuget/index.json

To install the package using NuGet, run the following command:

dotnet add package --source ResearchCave --version 1.1.48 ResearchCave.PasswordProtect

For more information on the NuGet registry, see the documentation.

Drop-in single-password beta gate for ResearchCave microservices. Shows a self-contained password page to unauthenticated visitors and remembers a correct entry via a hashed cookie. Not a real authentication system - intended only to keep newly deployed/beta services away from casual, anonymous visitors.

ResearchCave.PasswordProtect

ResearchCave.PasswordProtect is a drop-in single-password "beta gate" for ResearchCave microservices. It shows a self-contained password page to unauthenticated visitors and remembers a correct entry via a hashed cookie, so the password only has to be entered once per browser/host.

This is not a real authentication/authorization mechanism: there is one shared secret, no per-user identity, and the cookie only proves "someone once typed the password". It exists solely to keep a newly deployed or not-yet-public microservice away from casual, anonymous visitors while it's in front of beta testers.

Registration

using ResearchCave.PasswordProtect;

builder.Services.AddPasswordProtection();

var app = builder.Build();

// Register as early as possible, before UseRouting/UseAuthentication, so unauthenticated
// visitors never reach application endpoints.
app.UsePasswordProtection();

By default the password comes from the RcPassword configuration key, which every ResearchCave microservice already populates from the RcPassword environment variable. If no password is configured anywhere, the gate silently disables itself and every request passes through.

Configuration

builder.Services.AddPasswordProtection(options =>
{
    // Optional: override the password instead of relying on the RcPassword env var / config key.
    // options.Password = "...";

    options.PageTitle = "Sentient - Beta Access";
    options.LogoSvg = "<svg>...</svg>"; // optional service logo; defaults to the ResearchCave mark

    // Share access across subdomains of the same parent domain (e.g. entering the password on
    // app.researchcave.com also unlocks admin.researchcave.com). Leave null (default) for a
    // host-only cookie - required when the service is reachable on an unrelated domain, since
    // browsers never let a single cookie span unrelated domains.
    options.CookieDomain = ".researchcave.com";

    options.CookieName = "rc_beta_access"; // keep this consistent across services sharing CookieDomain
    options.CookieMaxAge = TimeSpan.FromDays(180);
});

Security notes

The cookie stores a SHA-256 hash of the configured password, never the plaintext password.
The cookie is HttpOnly, Secure, and SameSite=Lax.
Password/cookie comparisons use fixed-time equality checks.
A fixed, non-configurable list of infrastructure paths always bypasses the gate so machine-to-machine traffic isn't broken: /health, /healthz, /alive, /ready, /metrics, /.well-known, /signin-oidc, /signout-callback-oidc.
Common browser metadata paths also bypass the gate by exact match so missing favicons and manifests return their normal 404 instead of password-page HTML: /favicon.ico, /favicon.svg, Apple touch icons, web manifests, /browserconfig.xml, and /robots.txt.
The password page itself is an embedded resource (inline CSS, inline SVG logo) - nothing to map into wwwroot in the consuming application.