Knowledge Base

The Knowledge Base is a browser-based documentation area built into the server: a place to publish installation notes, operating procedures, partner onboarding guides, or any other reference material your file-transfer users need — next to the files they exchange, protected by the same accounts and groups. Moderators author rich pages organized in a topic tree; readers browse and search exactly the topics their groups are entitled to see.

Enabling the Knowledge Base

On Enterprise installations the Knowledge Base is enabled by default. It can be switched off with the <knowledge> block in admin-console.xml:

<knowledge>
    <enabled>false</enabled>
</knowledge>

The application is served from the admin console's web server at:

http://<server>:<admin-port>/knowledge/

Disabling takes effect immediately — no restart is required. While disabled, the Knowledge URL shows an informational page and all Knowledge API requests are refused.

Users, Sign-In, and Roles

Knowledge users are the server's regular SFTP accounts — the same identities that sign into SFTP and the Web File Transfer Portal. Two group capability flags control what a signed-in user can do:

Sign-in supports the same multi-factor authentication as the portal: if the account has MFA enrolled, the login prompts for the authenticator code. The Knowledge session is independent of portal and admin-console sessions — signing out of one does not sign you out of the others.

Reading

The reader view has three parts: the Index tree on the left, the article area in the middle, and a breadcrumb trail under the header showing where you are (Home › topic › page — every ancestor is clickable). The tree refreshes each time a branch is expanded, so newly published content appears without a page reload.

• Topics and pages are always shown by their titles; internal identifiers never appear in the interface.
• The header search box performs a full-text search across title and content of every published page the reader may see, with highlighted snippets in the results.
• Hyperlinks inside articles — external sites, server file links, and attachments — always open in a new browser tab; navigation within the Knowledge Base stays in the application.
• Hovering a table in an article shows a download button in its top-right corner that exports the table as CSV. The export dialog offers the field separator, line endings, character encoding, string marker, and whether to include the header row.

Topic Visibility and Publishing

Two independent gates decide what a reader sees:

Segregating Content by Organization

Because grants are given to groups, and groups belong to organizations (see Organizations, Groups, and Virtual Folders), the visibility model doubles as a multi-tenant content wall: each customer organization can be given its own documentation area that no other organization can see — or even discover.

A typical layout for a provider hosting two trading partners:

The enforcement is server-side and applies uniformly to the topic tree, page reads, search results, and attachment downloads — a reader outside the granted groups cannot reach the content by guessing addresses. The grant picker lists groups by their organization and display name (Organization / Group), so cross-tenant mistakes are easy to spot at a glance.

Authoring

Moderators see an author toolbar on the Index tree with four buttons that act on the current tree selection:

Ordering Topics and Pages

The topic editor contains two ordering lists — Order of topics and Order of pages. Drag entries into position, or select one and use Move up / Move down; Save applies the order everywhere the topic's contents appear: the Index tree, the topic view, and the Home page. Topics and pages are ordered independently because the Knowledge Base always groups topics before pages. To order the top-level topics, select Home in the Index tree and click Edit. Topics and pages that have never been ordered are listed after the ordered ones, alphabetically.

The Page Editor

The editor fills the content area (the Index tree stays visible) with the page title in the caption bar and Save, Publish, and Close at the right end of the toolbar. Save stores the page and keeps editing; Publish stores and makes the page visible to readers; Close returns to the article. The Save button is enabled only while there are unsaved changes, and every way of leaving a modified page — including navigation and sign-out — prompts with Save / Discard / Cancel so work is never silently lost.

Text and Headings

The Style drop-down applies paragraph styles (Normal, Heading 1–3) to the current block, Word-style, and follows the caret so it always shows the style you are in. The remaining toolbar controls cover fonts, size, colors, alignment, lists, and hyperlinks, plus a source-editing view for direct HTML work.

Code Snippets

Insert code snippet… in the paperclip menu opens the code snippet dialog: choose a language (Java, XML/HTML, JavaScript, JSON, SQL, Shell, PowerShell, Python, C#, CSS, YAML, or plain text) and paste the code. Published pages render snippets with syntax coloring; double-click a snippet in the editor to modify it.

The same dialog offers Mermaid Diagram (under Diagrams): write a diagram as Mermaid text — flowcharts, sequence diagrams, entity-relationship diagrams — and readers see it rendered as a real diagram. The editor shows the editable text source; the diagram is drawn fresh on every view, so the stored page stays plain, diffable text. Diagram text that fails to parse is shown as-is with an error note rather than disappearing.

Tables

The table button inserts a table by sweeping a row×column matrix, or via From CSV — upload a CSV file, choose its dialect (separator, line endings, encoding, string marker, first-line header), and the data becomes a table with a proper header row.

While the caret is inside a table, a floating toolbar appears beside it:

• Insert — column before/after, row before/after.
• Table style — a gallery of built-in looks (grid, striped, header row) in several color themes, shown as preview tiles.
• Borders — scope (cell, row, table frame, or the whole table at once), per-side checkboxes that reflect the current state, line width, line style, and line color.
• Auto-size columns — fits column widths to their content.
• Properties — dialogs for cell, row, column, and table (width, alignment, height, background).
• Delete — row, column, or the whole table.

Columns and rows also resize directly with the mouse: drag a column or row boundary, drag the table's right or bottom edge to scale all columns or rows proportionally, or drag the bottom-right corner to scale both at once. Borderless tables show faint guide lines while editing so they stay visible; readers never see the guides.

Pictures, Attachments, and File Links

The paperclip menu offers several ways to bring files and media into a page:

Attachment limits: 20 MB per file and 200 MB total per page by default. Uploads are restricted to a safe allow-list of content types (images, video, PDF, text, archives, Office documents, and a general binary fallback); HTML and SVG uploads are rejected because browsers would execute scripts inside them. File names are normalized to portable form automatically.

Diagrams

Insert diagram… in the paperclip menu opens the embedded draw.io editor — the full diagramming application with shapes, connectors, and stencil libraries — over the page. Saving exports the diagram into the page as an ordinary image that every reader sees, with the editable diagram source embedded inside the same file. To change a diagram later, select it and click the open button (or double-click it): draw.io reopens the original, fully editable, and saving replaces the image in place.

Version History

Every save of a page creates a new version — nothing is ever overwritten. In the page editor, expand the History panel on the right to see the page's versions (time, author, message). Clicking a version opens the compare view, which takes over the full width of the screen:

• The selected version renders on the left, the current page on the right, with a draggable divider between them.
• The raw change list sits below: additions in green, removals in red. Clicking a change line locates and highlights the corresponding section in the rendered page — and scrolls the other pane to the matching spot, so both sides stay aligned.
• Revert to this version restores the page to the selected version as a new version — history is preserved, and the revert itself can be reverted.

Connecting AI Assistants (MCP)

The Knowledge Base includes a built-in MCP server (Model Context Protocol) at /knowledge/mcp, so AI assistants such as Claude Code and Claude Desktop can search, read, and — for moderators — author content. Every connection acts as a real user account: the assistant sees exactly what that user's organization and groups are allowed to see, nothing more, and every action lands in the audit trail under that user's name. Changes an assistant saves are additionally marked generated by AI agent in the page's version history, so the History panel always shows which revisions came from an AI.

The AI Integration page in the Web Admin (and the matching desktop Admin Console tab) holds the master enable switch, ready-to-copy client registration commands, and API token management. The CLI equivalents are get-ai-integration / set-ai-integration. When AI integration is disabled, MCP clients receive a clear "disabled by an administrator" refusal; tokens and configuration are preserved for when it is re-enabled.

API Tokens

MCP clients authenticate with a personal access token sent as Authorization: Bearer <token>. Administrators create tokens in any admin surface — Web Admin (Knowledge page), the desktop Admin Console (Knowledge tab), or the CLI (token-create / token-list / token-revoke). Each token:

• is bound to one user account — disabling the account kills the token instantly, regardless of the token's own expiry;
• carries a scope: read (search and read) or read,write (authoring — the account also needs the manage_knowledge capability);
• expires after 90 days by default (configurable per token, including never);
• is prefixed ssskb_ so it is easy to recognize in client configuration files and logs;
• is shown once at creation — only a SHA-256 hash is stored on the server — and can be revoked at any time.

Browser Sign-In (OAuth)

Alternatively, register the server without a token and the client uses the built-in OAuth 2.1 flow: it discovers the server's authorization endpoints automatically, registers itself, and opens a browser page where the user signs in with their own SFTP credentials (MFA included) and approves the access — no token to copy or store. Access is short-lived and refreshed automatically; approvals appear in the token list (kind OAuth) and can be revoked there, which cuts off the client immediately. PKCE is mandatory, refresh tokens rotate on every use, and reuse of a rotated token revokes the whole grant.

Client Setup

The quickest path is to let the console generate the connection file for you. On the Web Admin AI Integration tab, use the download menu to save a ready-made config for your client: mcp.json for Claude Code / Claude Desktop, .vscode/mcp.json for Visual Studio Code with GitHub Copilot, or the Open WebUI tool-server import file. These files carry the endpoint URL but no token — the client completes browser sign-in (OAuth) on first use. Drop the file in the client's config location and connect. If you prefer to configure a client by hand, the equivalents are below.

Claude Code (either style):

# With a personal access token:
claude mcp add --transport http knowledge https://your-server:9980/knowledge/mcp \
    --header "Authorization: Bearer <token>"

# Or with browser sign-in (OAuth) — no token needed:
claude mcp add --transport http knowledge https://your-server:9980/knowledge/mcp

Claude Desktop: Settings → Connectors → Add custom connector and paste the endpoint URL. Desktop signs in through the browser OAuth flow — there is no field for a token header, so serve the endpoint over HTTPS and let OAuth handle it. Other MCP clients configure the endpoint as an HTTP server with either an Authorization: Bearer header or their OAuth support.

The assistant then has typed tools: search_knowledge, list_topics, read_page, and with a write-scope token create_topic, update_topic, create_page, update_page, publish_page, upload_image (attach an AI-generated image and embed it in the page), and list_server_files / find_server_files — bounded, names-only discovery of the token user's portal filesystem so the assistant can insert links to files on the server (readers' clicks are still governed by their own folder permissions; prefer shared virtual folders). Assistants can also author Mermaid diagrams, code snippets, tables, YouTube embeds, and video links — the tools describe the exact supported markup. Topic and page arguments accept the human titles you see in the reader — "create a topic 'GateKeeper Installation' under Home" works as spoken; slugs are never required. Anything an assistant writes is created as a draft and stays invisible to readers until a person (or an explicit publish call) publishes it — and every change is git-versioned, so the History panel shows exactly what the assistant did.

Blocking AI Access to a Page

Some pages hold material that must never reach an AI assistant — customer-private data, contract detail, anything your policy keeps out of third-party services. Any page can be marked blocked for AI agents: open it in the editor and click the AI: Allowed button in the toolbar. It turns red and reads AI: Blocked, and readers see an AI access blocked badge beside the page title so everyone knows why an assistant cannot discuss that page. The setting applies immediately — it does not wait for you to save or publish.

Blocking covers every route an assistant could take to the content, not just the obvious one:

• Reading is refused — read_page returns an access-denied error naming company policy.
• Writing is refused — update_page, publish_page, and attachment upload are all rejected.
• Search results exclude it — snippets are content, so a blocked page never appears in search_knowledge results.
• Listings omit it entirely — the page does not appear in list_topics at all, because a title can itself be confidential ("Acme Corp — breach post-mortem").

Enforcement is by credential type, decided on the server: a request that authenticates with an API token or OAuth — what assistants use — is treated as an agent on every URL, not only the MCP tools. A person signed in with a browser session is unaffected and reads the page normally. This matters because assistants can call the ordinary REST endpoints directly (that is how they upload images), so guarding only the MCP tools would leave a side door open. The rule lives in the server's authentication layer, so no instruction given to an assistant can talk it out of the block.

Only people can change the setting: the toggle endpoint refuses token-authenticated requests, so an assistant can never unblock a page for itself, and ordinary page saves cannot alter the flag. Every change is written to the audit trail as KNOWLEDGE_AI_BLOCK_ENABLED or KNOWLEDGE_AI_BLOCK_DISABLED with the operator's name, and the block survives reverting a page to an earlier version.

Branding

The Knowledge Base honors the same white-label branding as the file portal — product name, logo, colors, fonts, and favicon are read from a single branding.xml, so one change re-brands both surfaces at once. White-label branding is an Enterprise-edition feature; for the file layout and configuration, see White-label Branding in the Web File Transfer Portal chapter.

Operational Notes

• Storage: Knowledge content lives under the server's data directory in data/knowledge/, with page content, metadata, and attachments as plain files — included in ordinary backups automatically.
• Audit: authoring operations — topic and page creation, edits, publishing, deletion, permission grants and revocations — are recorded in the server's audit trail with the acting user.
• Search index: the full-text index updates on every save and publish; no maintenance is required.