Resource → Web Application

For resources that are web applications reached over HTTP/HTTPS — an admin console, a dashboard, an internal portal — the Connect button in the location tree opens the site in a live, browser-based session right inside MisterShell. As with the remote desktops, the session runs on a worker in the resource’s location, so there is no direct network path from your workstation to the application: you drive a browser that lives next to the target.

This is a graphical session: you see and interact with the real rendered page using your keyboard and mouse. When recording policy enables capture, MisterShell retains a visual replay; graphical sessions do not produce text transcripts.

Each connection opens its own pin. Only one graphical connection (RDP, VNC, or Web) is allowed per user/resource. Resume it from its connection pin, or disconnect it before opening another graphical connection.

Graphical-only resources open on Notes; snapshot-based Summary, Facts, and Compliance are unavailable.

What you can do

• Open the web application in a live session and use it with your keyboard and mouse.
• Exchange clipboard text when enabled for the resource.
• Have MisterShell sign you in automatically — via HTTP Basic, the site’s login form, or a custom key-sequence macro.
• Share the live session with teammates or external guests, and hand control of the mouse and keyboard to a participant.
• Disconnect cleanly when you are done.

Common tasks

Start a session

1. Click the Connect terminal icon beside the resource in the location tree.
2. A status label tracks progress — Starting session…, then Connecting to web application…; the canvas shows Connecting to live screen… until the page appears.
3. The page appears in the canvas once it loads, opened at the resource’s configured start URL. The view scales to fit the panel, up to MisterShell’s 1920×1080 graphical-session limit.

Work in the application

Click into the canvas and use the keyboard and mouse as you normally would in a browser, including right-click and editing keys such as Backspace. When the resource permits clipboard exchange, Paste and/or Copy appear in the session toolbar next to Disconnect. To paste, first focus an editable field in the remote page, then click Paste. To copy, use the remote page’s normal copy action, then click Copy. MisterShell retrieves the text and writes it to your local clipboard; if the browser requires a fresh permission gesture, click Copy once more when prompted. Browser security can refuse remote clipboard reads on insecure, unfocused, or permission-denied pages; MisterShell reports the reason. Clipboard exchange is explicit, text-only, limited to 256 KiB, and is never added to the recording. External guests may paste when enabled but cannot copy remote text out.

If credentials are available for the connection, MisterShell can sign you in automatically when the session opens — see How sign-in works for the available modes.

Share the session and hand off control

Use Invite in the session toolbar to share the live session with internal teammates or external guests — exactly like a shared shell or desktop. Everyone you invite sees the same live page.

Like the remote desktops, a web session has a single controller: one person drives the mouse and keyboard at a time, you by default. From the Invite menu you can hand control to any accepted participant (give-control) and reclaim it at any time. A ”… has control” indicator shows who is driving; everyone else watches read-only until control is handed to them. Handing control off releases any keys the previous controller was holding, so nothing sticks.

See Sharing a session & external guests for the full sharing walkthrough — inviting internal users, one-time guest links, and in-session chat.

End a session

Click Disconnect. The browser session closes and the canvas goes dark. Click Connect to start fresh.

How sign-in works

When the session opens, MisterShell can sign you in automatically using the credentials supplied for the connection. How it signs in is set by the resource’s Auth Mode, chosen in the resource’s create/edit modal under Connection (see Browsing & managing resources):

• Auto (default) — respond to an HTTP Basic challenge, or detect and fill the page’s login form. The right choice for most sites.
• Basic — HTTP Basic authentication only.
• Form — fill the site’s HTML login form only. If the form isn’t detected automatically, set explicit CSS field selectors (username, password, submit) in the modal’s Advanced section.
• Sequence — play a custom keystroke macro into the page (see below). Use this for multi-step logins or any flow the form-filler can’t drive.
• None — no automatic sign-in; type your credentials into the page yourself.

By default, MisterShell uses the resource’s configured credential. If it is a template requiring personal credentials, your saved credential for the template is used automatically. Without a saved credential, Authentication required offers Enter manually or Use vault before the session starts. Vault choices must support this resource’s web connection. See providing credentials when connecting. Auth Mode determines how those credentials are used in the remote application; it does not change the template requirement.

Automatic sign-in uses credentials only on the configured start origin (scheme, host and port), even when navigation locking is off. Configure the resource with the application’s final sign-in origin if it redirects to another origin. Basic authentication preserves authorization headers the application sets itself; form-only pages receive no Basic header.

Key-sequence login (Sequence mode)

A key sequence is a short macro of keystrokes that MisterShell types into the page after it loads. Set it in the Advanced section when Auth Mode is Sequence. It automates logins that have several steps (for example username → Next → password → Sign in) or fields the form-filler can’t target.

The macro is read left to right and understands these tokens — anything else is typed verbatim:

Token	What it does
{{username}} / {{password}}	Type the connection’s username / password
<TAB> <ENTER> <SPACE> <ESC> <BACKSPACE>	Press that key
<UP> <DOWN> <LEFT> <RIGHT>	Press an arrow key
<SLEEP:n>	Wait n seconds (decimals allowed, e.g. <SLEEP:1.5>; capped at 30s per sleep)

Example — tab into the username field and type it, tab on and wait two seconds for the next step to render, then the password, and submit:

<TAB>{{username}}<TAB><SLEEP:2><TAB>{{password}}<ENTER>

Tips:

• The macro waits up to 45 seconds for the initial page to finish loading. If an app renders its fields later, begin with a sleep — e.g. <SLEEP:3>. Same-origin frames and framesets are supported; credential tokens stop the macro if the focused frame or page has moved to another origin.
• Playback has a 120-second budget: no further steps start after it expires. Keep the sum of your sleeps and keystrokes within that budget.
• The supplied password is typed only when the macro reaches {{password}}; MisterShell never writes it to a transcript or typed-event log. As with any visible secret, it can still appear in the visual recording if the remote page displays it.
• If the macro contains a misspelled token (e.g. <TABB>), it is rejected and the session simply opens without auto-login, so you can sign in by hand.

Good to know

• Opens at a fixed start URL. The session always begins at the URL configured on the resource — it is not a general-purpose browser.
• Navigation is normally locked to the start origin. By default the session blocks top-level navigation away from the start site, so a stray link can’t carry the session off to an unrelated origin. (An administrator can turn this lock off per resource.)
• Remote identity follows the connection credential. This can be the service account credential, your saved credential for the template, or the manual/vault credential chosen at connect time.
• Invalid certificates are rejected by default. If the application presents a self-signed or otherwise invalid certificate, the session refuses to load it. An administrator can turn on Ignore certificate errors in the resource’s connection settings to accept it anyway — see CA Certificates → Web-resource “Ignore certificate errors” for the security caveat before doing so.

Conditions and blockers

• You do not have permission to open Web Application sessions — you lack the app.resources.execute permission.
• Connection error — a red banner reports the reason. Common causes:
  • the application host is unreachable or timed out — confirm the start URL and that a worker in the resource’s location is online;
  • the session browser failed to start on the worker — if web sessions fail for every web resource while other session types still work, the worker container is likely missing the security options the session browser needs; ask your administrator to check the deployment guide’s web-session prerequisites;
  • navigation was blocked — for example a redirect that left the locked start origin;
  • automatic login failed — check the credential used for the connection and, depending on the resource’s Auth Mode, its form-field selectors (Form mode) or its key sequence (Sequence mode).

Reviewing a web session afterwards

Completed, recorded web sessions appear in Review → Sessions with a visual, video-like Replay of the session.

Administrators can also watch a web session live and read-only while it is in progress — see Live session observe.

Permissions

• Open an interactive session: app.resources.execute.
• Share a session and hand off control: app.session.execute.
• Replay or review a recorded session: app.session.read.