Public Access
jaap-janandClaude Opus 5
c270f3fe39
An estate on Hetzner is already described somewhere: the project lists every server, its addresses, its plan and where it runs. Getting that into a keychain meant copying forty addresses out of a browser by hand, which is the same work the ssh_config importer exists to remove for the machines described in a file. ◆ A WIZARD RATHER THAN A SCREEN, AND THE DIFFERENCE IS WHAT EACH STEP COSTS. ImportScreen reads a file that is already on this machine, so it scans on open and shows a list. This cannot: it needs a credential that has to be made in another company's console first, and then it makes a request over the internet. Those are two moments rather than one, and a screen that mixed the token box in with the list would ask for the credential again every time somebody came back to look at the list. So three steps — token, choose, done — and the first two write nothing. Step two carries one address choice, one login user and one port for the whole import, because an estate is reached the same way throughout and a per-server dropdown would be forty answers to one question. ◆ THE TOKEN IS USED ONCE AND CLEARED, INCLUDING WHEN IT WORKED. The half worth stating is the success path. Clearing only on failure would leave a credential capable of listing somebody's whole estate sitting in a text box for as long as they spend reading forty rows, which is the longest anybody stands on this screen. Nothing writes it to the vault, to settings or to a log, and reopening the wizard restarts at step one rather than resuming — a resumed step two would be a list nothing on screen has the means to refresh, going on looking current for as long as the application stays open. Read is the only permission it needs and the note above the box says so: a Read & Write token would work identically here and would be a credential capable of deleting the estate, pasted in for no gain. The note also says a token belongs to one project — there is no API call that will say which, and none that lists the others — so an account with four projects runs this four times. Without that sentence the wizard looks like it lost most of the estate. ◆ THE ADDRESS IS A CHOICE, AND TWO OF THE THREE FALL BACK WHERE THE THIRD MUST NOT. Public IPv4 and public IPv6 fall back to each other: the same machine over the same internet, so the worst case is a route nobody picked, and the row says which. Private does not fall back at all. A server on no private network is simply not importable under that choice — its tickbox is disabled, and neither direction of the header's tick-all can reach it — because falling back would put an address on the open internet into a bookmark that was asked to stay off it. IPv6 needs saying twice over. Hetzner routes a whole /64 and the API reports the network, which nothing can dial; the address a stock image answers on is the first one in it. That is a convention of Hetzner's own images rather than a fact the API stated, so every use of it carries a warning on the row and in the stored note, and it is computed by setting the low byte rather than by string surgery on the prefix. It is not an edge case either — IPv4 is billed separately now and a project built since then can be entirely IPv6-only. ◆ NOTHING IMPORTED HERE AUTHENTICATES, AND THAT IS SAID BEFORE THE BUTTON. Hetzner has never held the private half of an SSH key. The API will name a project's keys and hand over their public halves; there is no private half to bring. So every host arrives bound to nothing and asks for a password until somebody points it at a key already in the keychain — the same shape an ssh_config import has with its key tick off, and stated above the button on the same reasoning: somebody who is not told will conclude the import was broken. What the note keeps is what does not go stale — the id, the plan, the location, the image, the labels. The power state is a column and never a note: "running" about a machine somebody switched off last March is worse than no note. ◆ WHERE IT LIVES: TWO FLAGS OVER ONE CONTENT COLUMN. Drawn over the Preferences page inside settings mode exactly as ImportScreen is, with SettingsNav unmoved and the titlebar offering "Back to preferences". IsHetznerImportOpen is a second flag rather than a "which importer" enum, because they are two independent facts about the content column and a single value would need a "neither" member IsImportOpen already expresses; what keeps them from both being true is that every path that opens one closes the other. The titlebar and the Preferences page ask IsImporterOpen, which is written against both. Preferences grows a second importer row beside the first rather than one row that asks "from where?", which would put a question in front of the far more common answer. ◆ WHAT IS NOT HERE. Hetzner's Robot — dedicated servers and Storage Boxes — is a different API behind a different credential, and nothing in this touches it. Said on the Preferences row and on the token step rather than left to be discovered by an account that has both. And there is no phone layout. This one would work on Android, unlike the ssh_config importer beside it: it is a token and a network request, the view model is shared already, and scoped storage has nothing to do with it. What is missing is a screen — the desktop draws a five-column table, and the phone version of that is a different layout rather than the same one narrower. Recorded in android-port.md and on the phone's own Preferences screen, because the note there previously read as though no import of any kind could work. ◆ TESTS, AND WHAT IS LEFT FOR A PERSON. HetznerCloudClientTests is 16 cases over the shapes the API actually returns, against a stubbed HttpMessageHandler: paging followed, the token in a header and never a query string, a refused token distinguished from a fault at Hetzner's end, a token with a line break refused before anything is sent, the /64, the private-network asymmetry, and a server the API described without a name. ShellFlowTests.Hetzner.cs is 11 more against this fixture's real vault, real cache and real server — split into a file of its own, as FakeVaultServer keeps its team endpoints. What they establish beyond the reader's own suite is the half it cannot reach: that reading stores nothing, that importing goes through the ordinary create-and-push path and lands on the server with nothing pressing Sync, that a server the keychain already has arrives unticked, and that the token does not outlive the request. Two layout cases measure both steps against the same content budget every other settings page gets, which is also what proves the markup binds to names that exist. Manual checks 2.11a–2.11d are what no test in this repository can do, because there is no account, no token and no network in the ordinary suite: a real project listed against the real console, a wrong token, the private choice, and what an imported host does when you connect to it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
79 lines
3.7 KiB
XML
79 lines
3.7 KiB
XML
<UserControl xmlns="https://github.com/avaloniaui"
|
|
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
|
|
xmlns:vm="using:DodoSSH.Client.Shell.ViewModels"
|
|
xmlns:views="using:DodoSSH.Client.App.Views"
|
|
x:Class="DodoSSH.Client.App.Views.SettingsView"
|
|
x:DataType="vm:MainWindowViewModel">
|
|
|
|
<!--
|
|
v5c: the settings MODE — the full-window chrome swap the design calls Settings, built as one control so
|
|
MainWindow.axaml can show or hide the whole thing behind MainWindowViewModel.IsSettingsMode with a single
|
|
IsVisible, the same way it already does for the unlocked application and the setup half of the window.
|
|
|
|
Titlebar, then a row of the 340px SettingsNav beside whichever page ActiveSettingsPage names. Seven pages
|
|
now, all of the design's — v5c-2 added Groups and Tags and retired the old VaultsScreen; see
|
|
SettingsNav.axaml and design-notes/v5c-fidelity-notes.md.
|
|
|
|
Every page including Vaults is wrapped in the 1100px centred column now. SettingsVaultsPage replaces the
|
|
old VaultsScreen's own 268px-list-beside-a-full-bleed-pane layout with the design's card idiom — see that
|
|
page's own remark for what changed and why.
|
|
|
|
v5c-3: ImportScreen joined the Panel, drawn over SettingsPreferencesPage rather than beside it — see
|
|
MainWindowViewModel.IsImportOpen. SettingsNav stays lit on Preferences the whole time, per Import.dc.html,
|
|
because ActiveSettingsPage never actually leaves SettingsPage.Preferences; only IsImportOpen and the pair
|
|
of IsVisible bindings below move. Its data context is ImportScreen rather than this control's own, the
|
|
same split MainWindow.axaml drew before the importer moved in here.
|
|
|
|
HetznerImportScreen joined it on identical terms. Two flags rather than one "which importer" value,
|
|
because they are two independent facts about the content column and every path that opens either closes
|
|
the other; what the Preferences page below asks is IsSettingsPreferencesContentShowing, which is written
|
|
against both.
|
|
-->
|
|
|
|
<Grid RowDefinitions="Auto,*" Background="{StaticResource Canvas}">
|
|
|
|
<views:SettingsTitleBar Grid.Row="0" />
|
|
|
|
<Grid Grid.Row="1" ColumnDefinitions="Auto,*">
|
|
|
|
<views:SettingsNav Grid.Column="0" />
|
|
|
|
<Panel Grid.Column="1">
|
|
|
|
<views:SettingsGeneralPage IsVisible="{Binding IsSettingsGeneralPage}" />
|
|
|
|
<views:SettingsVaultsPage IsVisible="{Binding IsSettingsVaultsPage}" />
|
|
|
|
<views:SettingsAccountPage IsVisible="{Binding IsSettingsAccountPage}" />
|
|
|
|
<views:SettingsSecurityPage IsVisible="{Binding IsSettingsSecurityPage}" />
|
|
|
|
<views:SettingsPreferencesPage IsVisible="{Binding IsSettingsPreferencesContentShowing}" />
|
|
|
|
<views:SettingsGroupsPage IsVisible="{Binding IsSettingsGroupsPage}" />
|
|
|
|
<views:SettingsTagsPage IsVisible="{Binding IsSettingsTagsPage}" />
|
|
|
|
<!--
|
|
Wrapped, like MainWindow.axaml wraps every screen whose data context is its own rather than this
|
|
control's: IsVisible has to resolve against the ambient MainWindowViewModel, and putting it on the
|
|
same element as the DataContext override below would have it resolve against ImportViewModel
|
|
instead, where IsImportOpen does not exist.
|
|
-->
|
|
<Panel IsVisible="{Binding IsImportOpen}">
|
|
<views:ImportScreen DataContext="{Binding ImportScreen}" />
|
|
</Panel>
|
|
|
|
<!-- The Hetzner wizard, on exactly the same terms. See MainWindowViewModel.IsHetznerImportOpen. -->
|
|
<Panel IsVisible="{Binding IsHetznerImportOpen}">
|
|
<views:HetznerImportScreen DataContext="{Binding HetznerImportScreen}" />
|
|
</Panel>
|
|
|
|
</Panel>
|
|
|
|
</Grid>
|
|
|
|
</Grid>
|
|
|
|
</UserControl>
|