using System.Reflection;
using Microsoft.AspNetCore.Authorization;
using Shouldly;
using Xunit;
using ZB.MOM.WW.OtOpcUa.AdminUI.Components.Pages;
using ZB.MOM.WW.Secrets.Ui;

namespace ZB.MOM.WW.OtOpcUa.AdminUI.Tests;

/// <summary>
///     Pins the side-rail link to <c>/admin/secrets</c> and its role gate. The page has worked since
///     lmxopcua#483, but reachability is a separate property from correctness: before this, the only
///     way to the secrets UI was typing the URL, which is the same orphaned-surface shape as Gitea
///     #546 (<see cref="HostsPanelWiringTests"/>) — everything builds, tests and deploys while no
///     user can get there.
/// </summary>
/// <remarks>
///     Source scan rather than a rendering assertion: the repo has no bUnit (the central
///     <c>PackageVersion</c> for it is referenced by no project), and razor layout markup — unlike
///     a page's <c>@page</c>/<c>@attribute</c> directives — does not survive into class metadata
///     any form a reflection guard can read. So this proves the link and its gate are *written*;
///     that the gate actually admits an Administrator and hides the item from a Designer is
///     live-verified on the docker-dev rig, per this repo's Razor convention.
/// </remarks>
[Trait("Category", "Unit")]
public sealed class SecretsNavLinkTests
{
    private const string NavItem = "<NavRailItem Href=\"/admin/secrets\"";

    private static string ReadMainLayoutSource()
    {
        var dir = new DirectoryInfo(AppContext.BaseDirectory);
        while (dir is not null && !File.Exists(Path.Combine(dir.FullName, "ZB.MOM.WW.OtOpcUa.slnx")))
            dir = dir.Parent;
        dir.ShouldNotBeNull("could not locate the repository root (no ZB.MOM.WW.OtOpcUa.slnx above the test binary)");

        return File.ReadAllText(Path.Combine(
            dir!.FullName, "src", "Server", "ZB.MOM.WW.OtOpcUa.AdminUI",
            "Components", "Layout", "MainLayout.razor"));
    }

    /// <summary>The reachability pin: without this the secrets UI is URL-only.</summary>
    [Fact]
    public void The_rail_links_to_the_secrets_page()
    {
        ReadMainLayoutSource().ShouldContain(
            NavItem,
            Case.Sensitive,
            customMessage:
                "the side rail no longer links to /admin/secrets — the secrets UI is reachable " +
                "only by typing the URL, which is how it shipped before this test existed");
    }

    /// <summary>
    ///     The link must sit INSIDE the AuthorizeView, not merely somewhere in the same file — an
    ///     unnested pair would leave the item visible to every authenticated user while reading, to
    ///     a scan for both strings, exactly like a gated one. Ordering is the strongest structural
    ///     claim a text scan can make; whether the gate actually hides the item is live-verified.
    /// </summary>
    [Fact]
    public void The_secrets_link_is_nested_inside_the_authorize_view()
    {
        var source = ReadMainLayoutSource();

        var open = source.IndexOf("<AuthorizeView Policy=", StringComparison.Ordinal);
        var item = source.IndexOf(NavItem, StringComparison.Ordinal);
        var close = source.IndexOf("</AuthorizeView>", open + 1, StringComparison.Ordinal);

        open.ShouldBeGreaterThanOrEqualTo(0, "the rail has no policy-gated AuthorizeView at all");
        close.ShouldBeGreaterThanOrEqualTo(0, "the gating AuthorizeView is never closed");
        item.ShouldBeInRange(open, close,
            "the /admin/secrets rail item is outside the AuthorizeView — it is visible to every " +
            "authenticated user, and a scan that only looked for both tags would not notice");
    }

    /// <summary>
    ///     The gate must be expressed as the page's own policy constant. <c>Roles="Administrator"</c>
    ///     or a "secrets:manage" literal would render identically today and then silently drift the
    ///     moment the RCL changed its policy — the rail would advertise a page that rejects the user,
    ///     or hide one that would have admitted them, with nothing failing.
    /// </summary>
    [Fact]
    public void The_gate_is_the_pages_own_policy_constant_not_a_role_or_a_literal()
    {
        var source = ReadMainLayoutSource();

        source.ShouldContain("SecretsAuthorization.ManagePolicy", Case.Sensitive);
        source.ShouldNotContain($"\"{SecretsAuthorization.ManagePolicy}\"", Case.Sensitive,
            customMessage: "the rail hard-codes the policy string instead of referencing the constant");
        source.ShouldNotContain("<AuthorizeView Roles=", Case.Sensitive,
            customMessage: "the rail gates on a role name instead of the page's policy");
    }

    /// <summary>
    ///     Cross-check that the constant the rail references is the one the page actually enforces.
    ///     The two assertions above are satisfiable by a rail gated on a policy no page uses; this is
    ///     what makes them mean "the rail shows exactly who the page will admit".
    /// </summary>
    [Fact]
    public void The_rails_policy_is_the_one_the_page_enforces()
    {
        var page = typeof(SecretsAdmin).GetCustomAttributes<AuthorizeAttribute>(inherit: false).Single();

        page.Policy.ShouldBe(SecretsAuthorization.ManagePolicy,
            "the rail gates on SecretsAuthorization.ManagePolicy, so the page must enforce it");
    }
}