Website application profiles

In an HTTP or HTTPS connection, open Protocol → Application. Choose a category, or keep All website applications to search across the available website profiles. The selector separates containers, virtualization, server management/BMC, networking/proxies, monitoring, business applications, and mail/storage. Native-only integrations are listed separately with an explanation; an API integration does not necessarily provide a website.

Selecting a profile starts in Manual browsing. It does not change the TLS/trust policy or saved credentials. First-party Google profiles supply their reviewed HTTPS address internally when the connection is blank, so their hostname and port do not need to be entered. Switching between Google profiles replaces only the previous managed Google address; an explicit custom destination is preserved. Google profiles also offer an explicit Automatic form login choice for the reviewed Google Account identifier/password flow; selecting the profile alone never enables it. Selecting Cloudflare Dashboard sets https://dash.cloudflare.com and port 443, replacing any existing address. Other profiles do not change the host or port. Basics shows a shortcut to Application settings instead of a second username/password editor. Choose Generic website to return to the existing HTTP Authentication and Advanced controls.

Application and Organize can suggest a matching existing icon. The preview is optional: select Use suggested icon to apply it. Changing the application never overwrites your current icon automatically; Custom application uses a generic website suggestion.

The hostname field also accepts a full HTTP(S) URL, such as https://portal.example.com/pt/Account/Login. The editor preserves its path, query and fragment and aligns the protocol and explicit port when pasted. Both browser views open that initial page through the internal proxy. A bare hostname still uses the application’s normal entry page; reviewed hosted sign-in routes retain precedence. A conflicting saved protocol or explicit port must be corrected before connecting. URL-embedded credentials are not accepted, and a saved path never grants access to a different origin.

Choose how to sign in

Business applications includes Activepieces Cloud and Activepieces (self-hosted). Both start in manual mode and offer explicit native password-form assistance. See Activepieces website login for address/port setup and interactive email-code or SSO sign-in.

Windmill and Windmill (self-hosted) support the developer automation platform’s reviewed native email/password form, with SSO, MFA and approvals remaining interactive. See Windmill connections for hosted password availability, self-hosted addresses and login behavior.

Use the website account, not an API key or bearer token. Dedicated Basic username/password fields take precedence as one pair; they are never mixed with an unrelated generic password. Form login requires both username and password. Saved credentials follow the existing connection database protection policy, which the user can configure; the application profile itself contains no secrets.

Portainer, Nginx Proxy Manager, Proxmox VE, and pfSense reuse the app’s existing reviewed login selectors. Nginx Proxy Manager uses the website email/password. Proxmox adds the selected realm only at runtime when the username does not already contain @realm; it does not rewrite the saved username. pfSense uses the WebGUI account, not REST API client credentials. Existing Open web UI actions use these same form-only or manual modes; API-token actions never turn tokens into web passwords.

HP/HPE iLO, other BMCs, and the other generic-form profiles use optional generic form detection. Their firmware/application-specific sign-in is not claimed verified. In particular, iLO Redfish/RIBCL sessions are not browser login sessions. Manual-only profiles do not offer unsupported automatic authentication. MFA, CAPTCHA, external SSO, and rejected passwords remain manual; this feature does not bypass them.

Google websites

Google Account, Cloud Console, Analytics, Business Profile, Search Console, Ads, YouTube, Gmail and Drive use fixed first-party entry points and a closed set of exact Google login/resource origins. Each origin receives a separate protected localhost alias behind the same native session. Redirects remain in the current tab and share the session’s native cookie jar; an unlisted origin, lookalike hostname, custom port, WebSocket, worker, WebRTC or WebTransport route is refused without a direct-network fallback.

First-party Google profiles resolve their built-in reviewed HTTPS entry point when the saved host is blank or already canonical. They do not require a user to enter a URL, hostname, IP address or port.

The first document opens the reviewed Google Account alias and carries the selected service URL as its exact return destination. This avoids depending on a service-specific passive-login redirect before the identifier page is ready; the service remains the owner of the native session and certificate policy.

When Automatic form login is selected, the native dispenser releases the saved Google Account email only to an exact reviewed identifier document, then releases the password once to the following exact password document. Either a connection credential or the explicitly selected application-vault credential can supply that pair. Grants are document-bound, single-use and short-lived. Account chooser, SSO, CAPTCHA, passkey, recovery, SMS and unknown challenge pages remain interactive.

Optional automatic 2FA recognizes only Google’s exact enrolled-authenticator page and the authenticator explicitly linked in Application settings. The code is generated after the page challenge is revalidated and submitted once; the secret is never sent to the page. Redirecting from the saved Google service to accounts.google.com does not change or discard the original database-owned consent. Other Google verification methods remain manual.

The proxy forwards the embedded WebView’s native User-Agent unchanged; it does not substitute a desktop Chrome string. Google can still reject embedded or software-controlled sign-in. That outcome does not permit bypassing the proxy or silently opening the system browser.

Webmin has reviewed username/password selectors for its classic and Authentic Theme session-login forms. The usual endpoint is HTTPS on port 10000, but selecting Webmin never changes an existing host, port, path, or TLS policy. Banners, two-factor codes, and password reset remain manual. This is a form-profile fixture check, not a live server sign-in guarantee. See the official connection instructions, classic form source, and Authentic Theme form source.

Mail / storage also includes self-hosted Bitwarden, community Vaultwarden and Nextcloud. They require your saved HTTPS origin and start in manual mode. Their explicit login flows, supported authenticator challenges and browser handoff limitations are documented in Website application login.

Cloudflare Dashboard automatic login and 2FA

Choose Networking / proxies → Cloudflare Dashboard to automatically set HTTPS, dash.cloudflare.com, and port 443, including when replacing an existing custom or stale address. Each explicit selection starts in Manual browsing with automatic login and automatic MFA disabled; saved credentials, vault references and TLS settings are preserved. Later address edits are retained until you select the profile again or click Use Cloudflare Dashboard address. Choose Automatic form login separately to use connection-local or vault website credentials. A different host, port, or plain HTTP address is refused before native preflight. Automatic mode starts at /login; it does not send API keys, Basic/Digest authentication or accept arbitrary selector overrides.

The adapter supports combined email/password forms and same-document email-then-password forms on /login. It waits for page readiness and stable controls, yields for controlled-input updates, and clicks the page’s submit button once. It can wait up to 90 seconds for an initially unresolved challenge without requesting credentials. Managed interstitial markers (_cf_chl_opt and challenge containers) block credential requests independently of Turnstile response fields; challenge iframe paths remain recognizable after their origin is rewritten to the local proxy. A challenge that appears after a credential request stops the attempt, and any password already filled by the adapter is cleared if the user has not replaced it. A later password continuation has a short, document-bound lifetime; navigation, cancellation and uncertain results stop it without repeated submissions. It does not solve CAPTCHA or emulate security keys.

For a supported authenticator prompt, explicitly enable Automatic 2FA, select Cloudflare authenticator app, and choose your local or vault authenticator. A generic one-time-code input is insufficient: the page must identify the active factor as an authenticator app/TOTP. Email, SMS, recovery, enrollment and ambiguous challenges remain manual. The toolbar’s Credentials & 2FA panel also provides explicit Copy/Type actions. This does not enroll Cloudflare or create recovery codes. See Cloudflare’s sign-in options and two-factor authentication instructions.

The dashboard profile supplies an exact proxy route for https://challenges.cloudflare.com, including early script and iframe loads. That route uses the connection’s configured transport proxy and the WebView’s native user agent, with a separate challenge-only cookie jar and normal certificate validation. It does not receive the dashboard’s saved credentials, cookies, custom headers or configured query parameters. Its requests are cancelled when the owning document is replaced or the session closes. Other destinations are not automatically trusted, and no direct-network fallback is added.

The challenge route preserves same-origin relative redirect paths, opaque query encoding (including __cf_chl_tk), and its isolated cookies across redirect requests. Dashboard cookies remain on the dashboard route. The challenge handler preserves Cloudflare’s cf-mitigated: challenge response signal, including on HTTP 403 HTML responses. A remaining challenge query alone is not treated as proof that the current login form is still challenged. Foreign challenge redirects remain refused.

The login and MFA controls are covered by synthetic regression fixtures, not a current live-account sign-in. Local TLS/CONNECT fixtures include a Just a moment... managed page with a nonce-bearing meta-CSP, relative challenge script, and challenge iframe. For the reviewed dashboard route, an HTML response carrying cf-mitigated: challenge passes through the normal bounded rewriting and script-injection pipeline even on HTTP 403; ordinary error pages keep their existing treatment. Transport and rewriting checks alone do not establish successful execution or clearance in the production WebView. Cloudflare explicitly lists serving a challenge on a different domain and embedding a Challenge Page in a cross-origin iframe as unsupported. The local proxy and embedded tab have those limitations; preserving the HTML, nonce, query, cookies and native user agent cannot guarantee clearance. Unknown cross-origin requests stay blocked.

For security keys, Windows Hello, external SSO, or incompatible challenges, select Open Cloudflare in system browser in the session. This explicit action opens only the fixed public HTTPS dashboard address, with no saved credentials, proxy URL, or current-page query attached. The system browser uses separate cookies and its own network route and TLS policy, outside this app’s proxy and Trust Center. Signing in there does not authenticate the embedded tab. Embedded/custom browsers have limited Cloudflare challenge support, so this preset does not promise a successful embedded login. See supported browsers.

Joomla versions and administrator path

Under Protocol → Application, choose Joomla Administrator and select Joomla version: auto-detect reviewed Joomla 3–6 forms (the default), or a specific major version. This selects the reviewed password-form controls, not server version discovery, an upgrade, or permission to submit credentials. Choose Automatic form login separately; selector overrides remain authoritative. An unmatched override does not fall back to another field. Changing the version stops the previous protected session; reload explicitly.

• Joomla 3 and 4.0–4.1: the optional secretkey field shares the password form. With automatic form login, the reviewed username/password can be filled, but the client pauses before submission whenever that field is present, even if it already contains a code. Enter the required code and select Log in yourself. It never infers that the field is a TOTP provider.
• Joomla 4.2+, 5 and 6: the password form is followed by the site’s separate captive MFA flow when required. Complete that challenge manually. The core email and authenticator providers use overlapping controls, so this preset does not offer automatic Joomla MFA. A code prompt or completed fill is not proof of successful authentication.

The latest official release checked on 13 September 2026 was Joomla 6.1.3 (18 August 2026), alongside 5.4.8. See the official release listing. Compatibility here means source-reviewed core templates and synthetic tests, not live acceptance of every installation. Old Joomla compatibility is not a recommendation to deploy an obsolete server. CAPTCHA, passkeys, SSO, security extensions and customized templates can still require manual sign-in.

The Joomla Administrator preset opens /administrator/ by default, not the public site root. Under Protocol → Application → Administrator path, enter /site/administrator/ for a subdirectory install, or an existing custom entry such as /staff-entry/. Leave it blank to use the default. This changes only the entry path on the configured host and port, for both the embedded viewer and original-origin browser action; it does not rename Joomla’s administrator folder.

Only a path is accepted: no full URL, query string, fragment, percent-encoded characters, backslash or . / .. segments. Do not put a security extension’s secret URL parameter here. Query-secret extensions, custom templates and access checks may need manual sign-in. The same reviewed username/password form is used only when present, with the site’s POST action and CSRF controls preserved. Changing this path stops the previous protected session; reload explicitly to use it. Selecting a path never enables automatic login.

Joomla’s official guide calls this the website address “appended with /administrator” and notes that security extensions may require an alternative login URL. See Logging in to Joomla and the reviewed administrator templates for 3.10.12, 4.1.5, 4.2.0, 5.4 and 6.1.3.

Analytics, CMS and database administration

The following six presets start in Manual browsing and require HTTPS. The configured host remains authoritative; selecting a brand does not redirect to a hosted service, select a database server, or enable credentials. Login paths are suggestions for the original-origin browser action, not a promise that every subdirectory installation uses the same path.

Use the existing 2FA Codes panel for manual copying when an authenticator is configured. These six profiles do not add automatic OTP challenge selectors. Unsupported embeddings, passkeys and identity-provider flows may require the original-origin system browser; that browser’s sign-in does not sign the embedded proxy session in automatically. Subdirectory deployments may require an explicit connection path. No API endpoint is called to bypass the website’s login flow.

Reviewed upstream sources: Matomo login template, Plausible login and 2FA verification, Odoo 19 login and authenticator form, Ghost current staff sign-in, Strapi administrator login, phpMyAdmin 5.2 login and 2FA documentation. Source review and isolated DOM regressions are not live-deployment certification.

Tactical RMM Take Control tabs

Take Control opens alongside connection tabs with the normal browser controls: history, URL, bookmarks, credentials, dark mode, and print. It shares the parent connection’s proxy and cookies, but the child cannot clear or restart the parent session. Each child has its own native document sequence, independent of the root document. Parent navigation, parent closure, or loss of database access expires the child. The tab title uses the computer name when available, otherwise a generic title. These tabs cannot be detached or persisted, and their control URLs are not stored in saved records.

Form overrides and safety

Tactical RMM, WordPress, Joomla Administrator, Drupal, Payload CMS, MeshCentral, and Apache Guacamole have source-reviewed password-form presets. Automatic authenticator codes require a separate explicit, saved HTTPS-origin opt-in and support only the reviewed Tactical, WordPress Two-Factor plugin, Guacamole TOTP-extension and Gitea local-account challenges. Other providers remain manual. See the website login and 2FA guide for setup, exact scope, source references, and proxy/true-origin limitations.

For a website without a preset, choose Custom websites → Custom application. It also starts in Manual browsing. After opting into form login, enter all three CSS selectors—for example input[name="username"], input[type="password"], and button[type="submit"]. The selectors identify visible controls in the same login form, not API endpoints. Custom form login refuses missing, invalid, or unmatched selectors and never falls back to generic detection. Each selector is limited to 512 characters; no script or custom JavaScript is accepted.

Optional CSS selector overrides are bounded and validated. Leave them blank to use a reviewed preset or generic detection. Explicit selectors must match visible controls in the intended form; an unmatched override is not permission to fill a different field. Delayed single-page-app forms can receive the one-shot fill during the bounded attempt window; private in-memory credential copies are cleared after completion, timeout, or cancellation. Fill-only intentionally leaves values in the selected website controls for your review.

Custom websites also offers dedicated Generic login form, HTTP Basic authentication, and HTTP Digest authentication profiles. Each starts in manual mode. Generic login form permits conservative detection; Custom application requires all three explicit control selectors. Generic website retains the legacy Authentication controls, including explicitly selected custom headers. Digest supports MD5/SHA-256 and their -sess variants, qop=auth or legacy no-qop, and UTF-8; unsupported algorithms and auth-int-only challenges are not silently downgraded. HTTPS remains recommended.

Under Protocol → Advanced → Advanced form automation, you can set one exact form selector, a delay before filling and a delay before submission (each 0–30 seconds), and an overall 1–60 second deadline covering both delays. Defaults preserve the existing eight-second attempt window. Turning Submit after filling off fills only. These options do not enable automatic login by themselves. The client captures the exact form and controls, then rechecks them and the same-origin action around input events and delays. A replaced form, changed destination, page navigation, disabled control, timeout, or unavailable guarded client stops the attempt; it never reacquires another form after filling. Implicit-method SPA forms retain their JavaScript handlers, but the client suppresses a fallback native GET that could place credentials in a URL.

Additional explicit fields support existing same-form text, hidden, and single-select controls for values such as tenant/domain. No field is guessed or created. Password, username, OTP, file, CSRF and token controls are refused; normal CSRF tokens remain site-managed. Select values must match an enabled option. Adding an extra field switches to fill-only; re-enable submission only after reviewing it. Limits are 16 fields, 512 characters per selector, 4096 characters per value, and 16 KiB total UTF-8 value bytes. Values are secret-capable connection data, masked in settings, and sent only in the protected one-use, no-store credential response—not injected HTML or proxy logs. Credential-free exports remove these fields and disable automatic submission.

Changing an application’s login settings stops its old protected web session. Reload explicitly to use the revised settings. Malformed or unknown imported profiles and unsupported modes block connection rather than falling back to legacy Basic authentication. Invalid selectors block automatic form login; manual mode does not use them.

HTTPS inspection, trust approval, accepted-certificate pinning, and configured outbound proxy routing remain in force. Selecting an application does not weaken TLS or create an external-browser SSO session. Credential-origin checks cannot be disabled by browsing policy; blocking page scripts also disables automatic form login. See Web viewer trust and authentication for diagnostics and transport details.

Reviewed reverse-proxy redirects

Under Protocol → Advanced → Internal proxy controls, Allow reviewed cross-origin redirects is off by default. Enable it to review a server’s top-level GET/HEAD redirect on the browser page itself. Choose Stay here, Continue in this tab, or Open anonymous tab. The current-tab option preserves the tab’s position and database owner, not the previous origin’s trust or cookies. The destination path is retained; query parameters and URL fragments are removed and the review warns when this happens. Form POSTs are never replayed to another origin.

Allow reviewed HTTPS-to-HTTP downgrades is a separate, default-off security exception for temporary HTTP handoffs. It requires the first checkbox and is overridden by Require HTTPS upstream. Untrusted destinations show HTTPS to unencrypted HTTP and require an explicit click; a saved exact HTTP destination skips repeat address review only while this downgrade option permits it. HTTP has no TLS: information subsequently entered there can be observed or modified in transit. Prefer correcting the reverse proxy or opening its secure final address instead. No Synology/QuickConnect hostname gets an automatic exception.

HTTP-to-HTTP can also be reviewed, with an unencrypted-connection warning. HTTP-to-HTTPS and HTTPS-to-HTTPS destinations undergo a fresh certificate inspection and normal trust approval. Each untrusted destination requires review, with a limit of five handoffs. Enabling the redirect flags alone does not trust a destination; saving its exact origin skips repeat destination reviews.

Accepting consumes a short-lived, single-use receipt and stops the source proxy. Cancel leaves the source usable. By default both choices start signed out. Existing transport routing is retained; the temporary destination is not saved as a connection. Opening or closing databases, changing navigation/settings, or changing the network route invalidates a pending review.

Carry saved login through reviewed redirects is an independent per-connection option, off by default. With this enabled, the page offers to use the saved username/password (Basic, Digest or application form login) when continuing in the current tab. The choice can be turned off for that handoff. Subsequent redirects retain the setting but still require their own review and fresh HTTPS trust; there is no automatic cross-origin redirect loop. Open anonymous tab always strips authentication, regardless of this setting.

Forwarding that login to HTTP additionally requires Allow saved login to be sent to unencrypted HTTP in settings and a separate acknowledgement for the exact HTTP destination on the review page. The ordinary downgrade checkbox alone never permits password forwarding.

Browser cookies, social login sessions, passkeys, authentication headers, secret query parameters, POST bodies, MFA seeds, scripts and favorites are not transferred. Form login may sign in again. Query-based SSO and some portal handoffs may require manual sign-in; this is not shared-cookie SSO support.

Both review flags survive saved-connection export/import; credential-free exports still remove secret query values. Missing flags in older records mean off, and malformed non-boolean flags are refused.

Trusted redirect destinations

Under Trust Center → Redirect destinations, search and filter the open database’s saved redirects, add an origin for a saved web connection, or forget destinations individually or in a reviewed selection. The connection’s Protocol → Advanced → Trusted redirect destinations section edits the same list. Origins belong to their original saved connection, not every connection in the database. The list accepts at most 32 unique HTTP(S) origins per connection, such as https://nas.example:5001. Scheme and port must match; paths, query parameters, fragments, credentials, wildcards and subdomain matching are not allowed.

Saving an origin means future redirects to that exact origin skip destination review; there is no second automatic-continuation switch. Anonymous handoffs continue in the same tab with the reviewed-redirect option enabled. Certificate inspection and normal trust checks still apply. HTTP handoffs must satisfy the existing downgrade and HTTPS-only settings. Configured saved-login forwarding still requires separate credential approval, shown as Review sign-in options for an already trusted destination. The five-hop limit remains in force. This list does not grant TLS certificate trust, permit downgrades, or share cookies or login credentials.

Save the connection to retain editor changes; Trust Center actions save through the same database and verify the result. Redirect consent belongs to that saved connection in its database: ordinary imports, exports and connection/database copies remove this list, even when credentials are included. Existing consent remains on normal saves and reloads of the same database. Imported addresses must be reviewed locally again; this is separate from Trust Center certificate records.

Save, export, and compatibility

Profiles are versioned, non-secret connection metadata. JSON/clone and native CSV/XML portability retain the selected profile and bounded selector overrides; credential-free exports still remove passwords. Exports that include credentials may contain plaintext secrets and must be protected. Third-party formats do not gain application-profile support automatically.

Existing saved generic HTTP connections and Quick Connect retain their previous authentication behavior. The new no-Basic form mode requires a matching updated native backend; older backends reject an unsupported mode rather than silently treating it as Basic. Tests use synthetic connections, mocked native boundaries, and isolated native proxy fixtures—not live device sign-ins or user vault data.