Sgcwebsockets HTML Auth

sgcHTML Accounts and Chat

Ten widgets covering the two things almost every application eventually needs on a page: signing people in and managing them, and letting them talk to each other or to a model.

Read sgcwebsockets-html-core first for the page builder and the edition gate. sgcHTML is All-Access only, needs Indy, and is absent on Android and iOS.

When to use this skill

• Put a sign-in form on a page
• Offer social sign-in, or passkeys
• Handle the redirect back from an OAuth provider
• Give an administrator a user list, and roles and permissions
• Show a banner while an administrator is impersonating someone
• Put a chat panel on a page, or an AI chat panel

Components in this skill

All are prefixed TsgcHTMLComponent_.

The important thing about the login widgets

They render a form. They do not authenticate anyone.

TsgcHTMLComponent_Login produces the markup for a sign-in form and posts it to wherever you tell it. Checking the credentials is your server handler's job, and the components that actually do authentication live elsewhere: sgcwebsockets-auth for OAuth2, JWT and WebAuthn, and sgcwebsockets-http for the REST server and its TsgcHTTPServer_Users.

FLogin := TsgcHTMLComponent_Login.Create(Self);
FLogin.PageBuilder := FPage;
FLogin.Title := 'Sign in';
FLogin.Subtitle := 'Use your work account';
FLogin.FormAction := '/session';        // your handler receives the POST
FLogin.FormMethod := 'POST';
FLogin.UserLabel := 'Email';
FLogin.UserPlaceholder := 'you@example.com';
FLogin.PasswordLabel := 'Password';
FLogin.ButtonText := 'Sign in';

Reading that as "the component logs the user in" is the single most likely mistake in this skill, and it produces a page that looks finished and authenticates nobody.

Before you start, ask the developer

Use a structured question tool if your host has one, for example Claude Code's AskUserQuestion. Otherwise ask in chat:

1. What verifies the credentials? There must be a handler at FormAction. If there is not one yet, that is the actual work, and the widget is the easy part.
2. Passwords, social, passkeys, or several? Each has a different widget and a different server-side flow. Offering all three is a bigger job than it looks on the page.
3. How is the session kept? A cookie, a JWT, a server session. The widget does not decide this and the rest of the application depends on it.
4. Is this over HTTPS? A password form on plain HTTP sends the password in clear text, and passkeys will not work at all outside a secure context.

Chat and AI chat

_Chat and _ChatBox render a conversation panel. _AIChat renders one shaped for talking to a model. As with login, they are the surface: the messages have to come from somewhere, which is usually a WebSocket connection from sgcwebsockets-core, and for _AIChat a model client from sgcwebsockets-ai.

A workable split is TsgcAIChat for the model call, a WebSocket connection to push tokens to the browser as they stream, and _AIChat to display them.

Things that catch people out

• The login widgets do not authenticate. They post a form to FormAction.
• FormAction pointing at nothing gives a form that appears to submit and then renders a 404. Wire the handler before the widget.
• A password field on plain HTTP is a real exposure, not a warning to defer. _WebAuthnLogin additionally requires a secure context, so localhost or HTTPS, and simply will not run otherwise.
• _OAuthCallback handles the redirect back from a provider. The redirect URI registered with that provider has to match the page's URL exactly, which is the same trap described in sgcwebsockets-auth.
• _UserManagement and _RolesPermissions render administrative screens. Put them behind an authorisation check, because rendering them to whoever asks hands over the whole administrative surface.
• The impersonation banner is a safety feature. If you implement impersonation without showing it, an administrator will eventually act as someone else without realising it.
• Every widget here still needs PageBuilder assigned.

Routing

• Find a component: reference/components-index.md lists every component, its unit, and its edition, grouped by Reg module.
• Uses clause: add the component's unit: value (shown on its API page) to your uses clause. Nothing compiles without it.
• API detail: reference/api/<Component>.md has the Properties, Events and Methods, each in both Delphi and C++Builder form.
• Option / enum / event types: property and event types link to reference/types/<TypeName>.md, which documents the sub-properties of option classes, the values of enums, and the parameter list of event handlers.
• Examples: examples/index.md is the full demo catalog; examples/<Component>.md is a focused, real usage snippet for the most-used components.
• Concepts: concepts/overview.md (getting started + uses-clause rule) and concepts/editions-and-features.md (which components your edition includes).
• Bundled resources: concepts/resources.md lists the browser-side assets (JavaScript, HTML, CSS) the server components serve or embed, so a browser client works without an external CDN.
• Version history: reference/history.md lists what changed in each sgcWebSockets release.

Editions

Components are gated by edition (Professional, Enterprise, All-Access) or by a feature define. Check the edition column in the components index, or concepts/editions-and-features.md, before relying on a component.

Only public and published members are documented. Method bodies, private fields and protected members are intentionally not included.