Customer portals: Mail, DNS and S3

Since 4.1.0 a server can offer three small web apps to its customers beside the hosting panel (2083) and the admin panel (2087):

Each portal is its own Next.js app, running as the unprivileged user hitechcloud-portal on loopback, behind the server's front end. The front end serves it over TLS only, on its public port and on any extra hostname you add. The portals keep no data of their own: every read and write goes through the portal API (127.0.0.1:2094, loopback only) to the panel, so a change made in a portal is what 2083, 2087 and hitechcloudcli show, and the other way round.

The apps are in English and Vietnamese, load nothing from a CDN, and use no remote fonts.

The layout of a portal​

The three portals share one layout, in a light and a dark theme:

• A sidebar on the left. The portal's name is at the top, then its sections, each with an icon. The section you are in is marked.
  • Mail: Overview, Domains, Mailboxes, Aliases and forwarders, Filters, Devices, Restore, Settings.
  • DNS: Zones, Templates, Settings.
  • S3: Connections, Usage, Settings.
• The parts of what you opened, in the sidebar. In the DNS portal, inside a zone, the sidebar also lists the zone's parts: Records, Import and export, DNSSEC, Propagation and Nameservers. Nameservers checks which name servers the registry (the parent zone) delegates the domain to and compares them with the zone's NS records on this server: match, partly matching, delegated elsewhere or not delegated, with what to change at the registrar. In the S3 portal, inside a connection, it lists Buckets. A part chosen on the page is marked in the sidebar too.
• Your account at the bottom of the sidebar: the name you signed in with, the language (English or Vietnamese), the theme (follow the device, light or dark) and Sign out. The language and the theme are remembered in the browser, and are also on the Settings page.
• Collapse. On a wide screen the sidebar's collapse button shrinks it to icons (the names stay available to screen readers). The choice is remembered in the browser.
• Breadcrumbs above the page title show where you are and link back up.
• On a phone the sidebar becomes a drawer behind a menu button. It keeps the keyboard focus, closes with Escape and on a click of a link.
• Keyboard and screen readers. The first Tab stop is a "Skip to main content" link. The pages are checked against WCAG 2.1 level AA (axe-core) in both languages and both themes. A table that is wider than the screen scrolls sideways inside its own labelled area, not the whole page.

The sign-in page has no sidebar: a plain header with the portal's name, the language and the theme.

Who can sign in​

A customer signs in with the same username and password as on the hosting panel, including its two-factor code when the account has one. The lockout after failed attempts is the same one 2083 uses, counted per account.

From 4.1.2 every valid account gets in, unless the administrator has switched a portal off:

• Mail portal: every mail-only account (a mail service account, which 2083 refuses) and every hosting account. A plan no longer needs the mail_portal feature. mail_portal_hosting_accounts = off in hitechcloud.config keeps hosting accounts out of the Mail portal.
• DNS and S3 portals: every hosting account. A mail-only account is refused with "This is a mail service account: it can sign in to the Mail portal only."
• A portal switched off (mail_portal, dns_portal or s3_portal set to off, no, false or 0 in hitechcloud.config) refuses everyone with "This portal is not switched on for your account." A missing or empty key counts as on.

The rule is checked again on every request, so switching a portal off takes effect straight away, not when sessions expire.

Passkeys​

From 4.2 a customer can sign in to the Mail portal with a passkey (a fingerprint, face or device PIN) instead of the password. Mail service accounts, which cannot open 2083, get passkeys this way too.

• Add one: Settings > Passkeys > Add a passkey. The portal asks for the account's password again, then the browser asks for the passkey. An account keeps up to 20 passkeys; each can be removed from the same list.
• Sign in: Sign in with a passkey on the sign-in page. No username is typed: the passkey names its account. No authenticator-app code is asked after it, as on 2083: the device has already checked the person.
• Where it works: a passkey belongs to an address. It works on the portal's own hostname from hosts.conf (port 443), or on the server's hostname on the portal's port (for example https://server.example.com:2091). A passkey added on the server's hostname also signs in to 2083 on that hostname, and the reverse, because both use the same store. On an IP address or any other name the portal says passkeys are not available there.
• Safety: the device must verify the person (PIN or biometric), a passkey whose signature counter goes backwards (a sign of a copied key) is refused, and the sign-in counts towards the same limits and lockout as a password. Every passkey added, removed or used is written to the account's activity log, and adding or removing one sends the "two-factor changed" notification when the account has it on.

There is no administrator page for a customer's passkeys yet.

Single sign-on​

From 4.1.2 a customer, an administrator or a reseller can open a portal already signed in, without typing the password again:

• From the hosting panel (2083): the dashboard has a Customer portals card with one button per portal the account may open. The button opens the portal in a new tab, on its /sso page with a one-time ticket.
• From HiTechAdmin (2087), for administrators and resellers: an account's page has Mail, DNS and S3 portal buttons. They open the portal signed in as that account, without opening a 2083 session; the sign-in is recorded as made by staff in the account's log. A mail service account gets the Mail portal button only.
• At a portal's sign-in page: Sign in with your hosting panel sends the customer to 2083 (to its own sign-in first, when there is no session). 2083 asks "Open the portal signed in as this account?"; its Open the portal button then returns the customer to the portal, on the address it came from, signed in. 2083 only returns to an address of this server's own portals.

The tickets behind these (hct1_...) work once, live for 30 seconds by default (60 at most), and are tied to the account, the portal and the host they were issued for. A ticket that has expired or was already used shows "We could not sign you in" with a link to the sign-in page. Apps can issue the same tickets through the 2083 API (POST /api/auth/ticket with "app": "portal-mail", "portal-dns" or "portal-s3"; needs the api feature): see App sign-in tickets.

Turning the portals on and off​

From 4.1.2 the three portals are on by default. A fresh install brings up Mail, DNS and S3 and opens 2091-2093, and every update installs and starts any portal that has not been switched off, on servers that never configured them too. To install a server without them, run the installer with HITECHCLOUD_NO_PORTALS=1: it writes an explicit off for each portal, which no update overrides.

Each portal is switched on and off on its own. From HiTechAdmin: Server > Portals. From a terminal:

hitechcloudcli portals status             # on/off, version, port, health, certificate
hitechcloudcli portals disable s3         # stop it, drop its vhosts, close its port
hitechcloudcli portals enable s3          # turn it back on (installs it when it is not)
hitechcloudcli portals install mail       # download, verify and turn on one portal

install downloads the app from the mirror and checks it against the release's signed SHA256SUMS before anything is unpacked. disable keeps the files and the hostnames, so enable brings the portal back as it was.

The firewall opens a portal's public port while that portal is on (2091-2093 unless changed), and closes it when it is switched off.

Every hitechcloudcli update runs portals converge, which moves every portal that is not switched off to the release being installed and puts the previous version back if the new one does not answer its health check.

Ports​

hitechcloudcli portals port mail 2491     # move the Mail portal to 2491

A public port must be 1024 or above and may not be one the panel or the portals use internally: 2083, 2087, 2090, 2094, 2096, 3091, 3092 or 3093. A port something else is already listening on is refused.

If a firewall in front of the server (a cloud security group, for example) filters traffic, open 2091, 2092 and 2093 there as well, or the ports you chose.

Hostnames​

Each portal can also answer on its own hostname on port 443, for example mail.example.com for the Mail portal:

hitechcloudcli portals host add mail mail.example.com
hitechcloudcli portals host add dns dns.example.com --owner reseller1
hitechcloudcli portals host list
hitechcloudcli portals host remove mail mail.example.com
hitechcloudcli portals host issue mail.example.com   # order the certificate again

The hostname's DNS must point at this server. It is served at once under the panel's certificate, and its own certificate is ordered in the background; host list shows the certificate state. --owner records the hostname as a reseller's or an account's own (resellers set theirs in their own settings). --no-issue adds the hostname without ordering a certificate.

There is no plain-HTTP fallback: with no certificate at all nothing is served for that hostname, and portals status says why.

When a portal does not answer​

hitechcloudcli portals status
hitechcloudcli portals logs mail -n 100
hitechcloudcli portals repair             # render everything again and restart

The units are hitechcloud-portal-mail, hitechcloud-portal-dns, hitechcloud-portal-s3 and the shared hitechcloud-portalapi. Logs are in /var/log/hitechcloud/portals/ and in each unit's journal. A portal that returns you to its sign-in page after a correct password has the same cause as 2083 doing so: see Troubleshooting.

Known limitations (4.1.x)​

• S3 portal: object versions can be viewed, downloaded and restored, but not deleted. (Since 4.3, objects larger than 5 GiB are copied and moved with a multipart copy on the provider's side, and a folder of any size is deleted in batches of 1000 with progress and a Stop button.)
• The two-factor step after a password asks for the authenticator code only; a passkey signs in on its own instead (see Passkeys). An account whose second factor is a code sent by email cannot sign in to a portal with its password yet: it is told to turn on an authenticator app in the hosting panel.
• Passkeys are managed in the Mail portal only.

See also: hitechcloudcli portals.