fix: Teams-App-Package-Template am Plugin-Ingest akzeptieren (scoped .template) - #880
Merged
Conversation
A store update to @omadia/channel-teams 0.21.0 failed on the live instance with "entry appPackage/manifest.json.template has a disallowed extension (.template)". Producer, gatekeeper and consumer are all ours and disagreed, so the agent factory could not install its template anywhere: - the published 0.21.0 artifact ships appPackage/manifest.json.template (checked against the hub zip's central directory), - zipExtractor's EXTENSION_ALLOWLIST is deny-by-default and had no .template, so ingest rejected the whole package, - teamsAppPackageAssets reads exactly that filename and requires it by name. .template is now accepted, scoped to appPackage/ -- the construction .woff2 already uses under ui/. Scoped rather than global because the extension says nothing about content: the file is read as text and never loaded or executed, which puts it in the class of the already-allowed .txt / .md, but only one directory has a reason to carry it. Renaming to an allowed extension was the alternative and is worse: the consumer filename is compiled into the running release, so a renamed plugin would blind the factory until the middleware caught up -- an ordering constraint for no security gain, and it would invalidate the published zip. The gap was in the process rather than the deploy: nothing ever held the published package layout against the ingest gate (npm run package checks the zip builds, the drift-guard checks versions). The new test pushes the actual appPackage/ layout through the extractor and pins the scope in both directions -- root-level and look-alike directories still reject.
This was referenced Aug 27, 2026
Weegy
added a commit
that referenced
this pull request
Aug 27, 2026
Operators had no single place that says how to get several omadia agents into Microsoft Teams as separate named bots. The knowledge was spread across three repos, two manifests, five migrations and a handful of PR descriptions, so every attempt rediscovered the same traps: consent that silently does not apply, ARM fields whose absence is a partial success rather than a failure, and a teams_bots block nothing syncs for you. The new guide walks the whole path and states the platform limits up front, because they decide the architecture: Teams cannot change a bot name per message, bots never see each other, and rate limits are per bot (which is an argument FOR separate identities, not against them). Every API path, field name, state and setup key is verified against main rather than carried over from the draft, which predated three waves -- the operator UI (#896), the memory ACL (#881) and the .template ingest fix (#880) all landed after it. The one claim that could not be grounded in code is marked as a VERIFY comment instead of asserted. Part of #860
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Marcels Store-Update auf
@omadia/channel-teams0.21.0 scheitert auf der Fly-Instanz (v0.136.1):Ursache — ein Dreiecks-Konflikt, alle drei Teile bei uns
appPackage/manifest.json.template— gegen die Central Directory des publizierten Artefakts verifiziertmiddleware/src/plugins/zipExtractor.ts:20EXTENSION_ALLOWLISTist deny-by-default, kein.template→ Ingest bricht abmiddleware/src/services/teamsAppPackageAssets.ts:193readFileexaktappPackage/manifest.json.templateund verlangt es namentlichDie Agent-Factory (#860 W1a) kann ihr App-Package-Template damit nirgends installieren — das Paket kommt am eigenen Gate nicht vorbei. In Prod fiel es nicht auf, weil der Pfad ohne Identity-Rows inert ist: der erste echte Install-Versuch war Marcels Klick.
Fix
.templatewird akzeptiert, scoped aufappPackage/— dieselbe Konstruktion, die.woff2unterhalb vonui/schon nutzt (UI_BUNDLE_EXTENSIONS+UI_BUNDLE_PATH).Scoped statt global, weil die Endung nichts über den Inhalt sagt: die Datei wird als Text gelesen und nie geladen oder ausgeführt — damit gehört sie in die Klasse der ohnehin erlaubten
.txt/.md, aber nur ein Verzeichnis hat einen Grund, sie zu tragen.Warum kein Rename (
manifest.template.jsonwäre erlaubt gewesen): der Consumer-Dateiname steckt als Konstante im laufenden Release. Ein umbenanntes Plugin macht die Factory genau so lange blind, bis auch die Middleware nachgezogen ist — Reihenfolgezwang für null Sicherheitsgewinn, und das publizierte ZIP wäre ungültig geworden.Der eigentliche Prozessfehler
Nichts hat je das publizierte Paket-Layout gegen das Ingest-Gate gehalten:
npm run packageprüft, dass das ZIP baut, der Drift-Guard prüft Versionen — aber niemand fragt „kommt dieses ZIP am Extractor vorbei".pluginPackageTemplateAllowlist.test.tsschickt jetzt das echteappPackage/-Layout (manifest.json.template,color.png,outline.png,README.md) durchextractZipToDirund pinnt das Scoping in beide Richtungen: Root-Level und Namensvetter-Verzeichnisse (appPackages/) werden weiterhin abgelehnt, ein Wrapper-Verzeichnis (npm-pack-Stil) wird toleriert, ein.shinappPackage/bleibt abgelehnt, und ein expliziterextensionAllowlist-Override erbt.templatenicht.Ergänzend nimmt die #860-Welle den echten Install-Schritt in ihren E2E-Smoke auf (bisher setzte der erst bei „Plugin ist installiert" an — genau die blinde Stelle).
Tests
8 neue Fälle in
pluginPackageTemplateAllowlist.test.ts(Extractor-Scoping + Ingest überPackageUploadService). Regression: 129 Tests der Paket-/Install-/UI-Suiten grün, lint + typecheck sauber.Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.