Archived
218 lines
14 KiB
HTML
218 lines
14 KiB
HTML
<!DOCTYPE html>
|
|
<html>
|
|
<head>
|
|
<meta charset="utf-8">
|
|
<title>Signing In | HiAPI-C# 2025 </title>
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
|
<meta name="title" content="Signing In | HiAPI-C# 2025 ">
|
|
|
|
|
|
<link rel="icon" href="../../img/HiAPI.favicon.ico">
|
|
<link rel="stylesheet" href="../../public/docfx.min.css">
|
|
<link rel="stylesheet" href="../../public/main.css">
|
|
<meta name="docfx:navrel" content="../../toc.html">
|
|
<meta name="docfx:tocrel" content="toc.html">
|
|
|
|
<meta name="docfx:rel" content="../../">
|
|
|
|
|
|
|
|
<meta name="loc:inThisArticle" content="In this article">
|
|
<meta name="loc:searchResultsCount" content="{count} results for "{query}"">
|
|
<meta name="loc:searchNoResults" content="No results for "{query}"">
|
|
<meta name="loc:tocFilter" content="Filter by title">
|
|
<meta name="loc:nextArticle" content="Next">
|
|
<meta name="loc:prevArticle" content="Previous">
|
|
<meta name="loc:themeLight" content="Light">
|
|
<meta name="loc:themeDark" content="Dark">
|
|
<meta name="loc:themeAuto" content="Auto">
|
|
<meta name="loc:changeTheme" content="Change theme">
|
|
<meta name="loc:copy" content="Copy">
|
|
<meta name="loc:downloadPdf" content="Download PDF">
|
|
|
|
<script type="module" src="./../../public/docfx.min.js"></script>
|
|
|
|
<script>
|
|
const theme = localStorage.getItem('theme') || 'auto'
|
|
document.documentElement.setAttribute('data-bs-theme', theme === 'auto' ? (window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light') : theme)
|
|
</script>
|
|
|
|
</head>
|
|
|
|
<body class="tex2jax_ignore" data-layout="" data-yaml-mime="">
|
|
<header class="bg-body border-bottom">
|
|
<nav id="autocollapse" class="navbar navbar-expand-md" role="navigation">
|
|
<div class="container-xxl flex-nowrap">
|
|
<a class="navbar-brand" href="../../index.html">
|
|
<img id="logo" class="svg" src="../../img/HiAPI.logo.png" alt="">
|
|
|
|
</a>
|
|
<button class="btn btn-lg d-md-none border-0" type="button" data-bs-toggle="collapse" data-bs-target="#navpanel" aria-controls="navpanel" aria-expanded="false" aria-label="Toggle navigation">
|
|
<i class="bi bi-three-dots"></i>
|
|
</button>
|
|
<div class="collapse navbar-collapse" id="navpanel">
|
|
<div id="navbar">
|
|
<form class="search" role="search" id="search">
|
|
<i class="bi bi-search"></i>
|
|
<input class="form-control" id="search-query" type="search" disabled placeholder="Search" autocomplete="off" aria-label="Search">
|
|
</form>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</nav>
|
|
</header>
|
|
|
|
<main class="container-xxl">
|
|
<div class="toc-offcanvas">
|
|
<div class="offcanvas-md offcanvas-start" tabindex="-1" id="tocOffcanvas" aria-labelledby="tocOffcanvasLabel">
|
|
<div class="offcanvas-header">
|
|
<h5 class="offcanvas-title" id="tocOffcanvasLabel">Table of Contents</h5>
|
|
<button type="button" class="btn-close" data-bs-dismiss="offcanvas" data-bs-target="#tocOffcanvas" aria-label="Close"></button>
|
|
</div>
|
|
<div class="offcanvas-body">
|
|
<nav class="toc" id="toc"></nav>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="content">
|
|
<div class="actionbar">
|
|
<button class="btn btn-lg border-0 d-md-none" type="button" data-bs-toggle="offcanvas" data-bs-target="#tocOffcanvas" aria-controls="tocOffcanvas" aria-expanded="false" aria-label="Show table of contents">
|
|
<i class="bi bi-list"></i>
|
|
</button>
|
|
|
|
<nav id="breadcrumb"></nav>
|
|
</div>
|
|
|
|
<article data-uid="">
|
|
<h1 id="signing-in">Signing In</h1>
|
|
|
|
<p>The sign-in card is the <code>/login</code> route, and whether anyone ever reaches it is the service's decision
|
|
rather than the browser's. With the gate on, the service's data and its live updates stay closed
|
|
until a browser has signed in; with it off, the route sends every visitor straight back into the
|
|
application. A sign-in buys admission and nothing more — the service matches a name and a password
|
|
once, then carries the name only to label the sign-out button, and nothing it does afterwards
|
|
depends on which account was used.</p>
|
|
<h2 id="whether-the-gate-is-on">Whether the gate is on</h2>
|
|
<p>The <code>Auth</code> section of the service's configuration decides it, through its <code>Enabled</code> flag. The flag
|
|
falls back to off when nothing sets it, so a service whose configuration carries no <code>Auth</code> section,
|
|
or carries one with the flag off, runs with no login at all. The configuration as shipped turns the
|
|
flag on and supplies one account, so a service started from it asks for a sign-in.</p>
|
|
<p>The accounts are the <code>Users</code> list in that same section — username and password pairs, read once when
|
|
the service starts. Every entry grants exactly the same access: there are no roles, no group
|
|
memberships, and nothing at all is kept per account. There is also no way to create an account,
|
|
change a password or recover one from inside the application. All three are edits to the service's
|
|
configuration, made by whoever runs the service, and they take effect at its next restart.</p>
|
|
<p>What the gate closes is the service's own surface: the requests each screen makes for data, and the
|
|
live channels that keep those screens current. It does not close the page. The application shell,
|
|
the brand image and the sign-in card itself are served before authorization is consulted, which is
|
|
what lets the card be drawn for a browser that holds no session.</p>
|
|
<h2 id="signing-in-1">Signing in</h2>
|
|
<p>The card asks for one pair of credentials, under the prompt <em>Please sign in to continue</em>.</p>
|
|
<ol>
|
|
<li>Type the account name into <strong>Username</strong> and the password into <strong>Password</strong>. The username field
|
|
already holds the focus when the card appears, and the eye icon at the right of the password
|
|
field toggles the typing visible.</li>
|
|
<li>Submit with the <strong>Sign In</strong> button, or by pressing Enter in either field.</li>
|
|
<li>Neither field is checked in the browser, so whatever is entered — an empty pair included — goes
|
|
to the service, and a refusal comes from there rather than from the form. It arrives as one red
|
|
line under the password field, <em>Incorrect username or password</em>, and the card stays as it is.</li>
|
|
</ol>
|
|
<p>A successful sign-in reloads the application at the screen that was wanted. When the browser was
|
|
sent to the card while trying to reach a particular screen, that address travels with it in the
|
|
card's <code>redirect</code> query argument — <code>?tree=</code> selection included — and is where the sign-in returns
|
|
to. A browser that came to the card on its own lands on the Execution page.</p>
|
|
<p>Two smaller things the card carries. The grey line below the name is a version mark, the same
|
|
version the menu bar shows from inside. And the card's own language is whichever this browser last
|
|
used, or the browser's own language on a first visit, because the language setting belongs to the
|
|
service and is behind the gate like everything else there; after signing in, the interface follows
|
|
that setting — one value for everyone on the service — chosen in the <strong>Preference</strong> menu's language
|
|
submenu (see <a href="preferences.html">Preferences</a>).</p>
|
|
<p>The sign-in card at <code>/login</code>, in a browser holding no session. The card is all the screen holds —
|
|
none of the application frame is drawn behind it — with the version mark and the prompt under the
|
|
name, the focus already in <strong>Username</strong>, and the eye toggle at the right of <strong>Password</strong>.</p>
|
|
<p><img src="signing-in-img/login-card.en.png" alt="A plain grey page holding one white card: the HiNC brand mark and name above a version mark and the prompt Please sign in to continue, an empty Username field holding the focus, a Password field with an eye toggle, and a Sign In button at the lower right"></p>
|
|
<h2 id="when-the-sign-in-page-does-not-appear">When the sign-in page does not appear</h2>
|
|
<p>Three situations account for it, in the order they are likely.</p>
|
|
<p><strong>The gate is off.</strong> With no <code>Auth</code> section, or with <code>Enabled</code> off, the <code>/login</code> route redirects
|
|
every visitor back into the application instead of showing a form. From inside, the quickest tell is
|
|
the menu bar: a service with no gate carries no sign-out button.</p>
|
|
<p><strong>The browser is already signed in.</strong> Its session cookie is still good, so the card is skipped and
|
|
the screen that was asked for opens directly.</p>
|
|
<p><strong>The service could not say.</strong> The application asks the service once, on its first navigation,
|
|
whether a gate exists and whether this browser has passed it. If that question fails to get an
|
|
answer, the application assumes there is no gate and lets the browser through — it fails open. On a
|
|
service whose gate is in fact on, the result is a window that opens on the screen that was asked for
|
|
and can then load nothing: no project, panels that never fill, and requests the service is refusing
|
|
behind them. The menu bar is the giveaway — no version mark beside the brand image, and no sign-out
|
|
button at the right end, because both are filled in from the answer that never arrived. In this
|
|
state nothing offers a sign-in card and nothing redirects to one. Reloading the page puts the
|
|
question again; it is re-asked on every navigation until it is answered, and once the service
|
|
answers, the browser reaches the card in the ordinary way.</p>
|
|
<h2 id="signing-out">Signing out</h2>
|
|
<p>The sign-out button sits at the right end of the menu bar, after <strong>Show Log</strong>. It is labelled with
|
|
the signed-in user name — or with <strong>Logout</strong> when the service reported no name — and its tooltip
|
|
reads <strong>Log out</strong>. It is drawn only while the gate is on and this browser is signed in.</p>
|
|
<p>Press it to end this browser's session. The page is torn down and rebuilt at the sign-in card. If
|
|
the request to the service did not get through, the service still holds this browser as signed in, so
|
|
the card sends it straight back into the application — press the button again.</p>
|
|
<p>What ends is one browser's admission. Another browser signed in under the same account is untouched
|
|
and carries on working: the service keeps no register of who is connected, so there is no notice
|
|
that an account is in use elsewhere, and no limit on how many browsers may hold it.</p>
|
|
<h2 id="when-a-session-ends-on-its-own">When a session ends on its own</h2>
|
|
<p>A sign-in belongs to the browser session, so closing the browser ends it whatever the configuration
|
|
says. While the browser stays open it lasts up to the number of hours in the <code>Auth</code> section's
|
|
<code>SessionHours</code> setting — eight in the configuration as shipped, and never less than one whatever the
|
|
setting says. Sliding expiration is on by default, and the service describes that setting as
|
|
refreshing the expiry with activity.</p>
|
|
<p>Nothing announces that the end is near. There is no countdown, no prompt and no way to extend. The
|
|
first sign is the sign-in card, which arrives the moment a screen next asks the service for
|
|
something and is refused.</p>
|
|
<p>Recovery is a second sign-in. The screen that was open travels in the <code>redirect</code> argument, so
|
|
signing in comes straight back to it; what does not come back is anything entered or arranged on
|
|
that screen and not yet saved, because a sign-in reloads the application from scratch. The session
|
|
is the browser's admission and nothing else — ending it changes what that browser may ask for, not
|
|
what the service is holding.</p>
|
|
<h2 id="locked-out">Locked out</h2>
|
|
<p>A gate that is on over an empty account list admits nobody, and it looks exactly like a mistyped
|
|
password — the same single red line, for every name tried, in every browser. Nothing counts
|
|
attempts and nothing locks after a bad one, so a refusal that repeats for every account anyone can
|
|
think of is the symptom to read as a configuration problem rather than a credential one.</p>
|
|
<p>The way out is one entry. Add a username and password pair to the <code>Users</code> list in the <code>Auth</code> section
|
|
of the service's configuration, then restart the service — that list is read once at startup.</p>
|
|
<p>The state is neither permanent nor damaging. The service runs normally the whole time it is turning
|
|
browsers away; it simply has no credential to match one against.</p>
|
|
<h2 id="see-also">See Also</h2>
|
|
<ul>
|
|
<li><a href="index.html">Basics</a> — the rest of what is true on every screen</li>
|
|
<li><a href="the-app-window.html">The Application Window</a> — the menu bar the sign-out button sits at the end of</li>
|
|
<li><a href="finding-your-way.html">Finding Your Way</a> — the screens a sign-in returns to, and the addresses that name them</li>
|
|
<li><a href="preferences.html">Preferences</a> — the settings the service keeps for everyone on it, the language among them</li>
|
|
</ul>
|
|
|
|
</article>
|
|
|
|
<div class="contribution d-print-none">
|
|
</div>
|
|
|
|
<div class="next-article d-print-none border-top" id="nextArticle"></div>
|
|
|
|
</div>
|
|
|
|
<div class="affix">
|
|
<nav id="affix"></nav>
|
|
</div>
|
|
</main>
|
|
|
|
<div class="container-xxl search-results" id="search-results"></div>
|
|
|
|
<footer class="border-top text-secondary">
|
|
<div class="container-xxl">
|
|
<div class="flex-fill">
|
|
<span> Copyright © 2025 <a href='https://superhightech.com.tw'>Tech Coordinate</a>. All rights reserved. <a href='https://superhightech.com.tw'>超級高科技股份有限公司</a> © 2025 版權所有 </span>
|
|
</div>
|
|
</div>
|
|
</footer>
|
|
</body>
|
|
</html>
|