Külön teszt-környezet előkészítése

Használd a külön teszt-környezetet, ha egy kifejezetten kért ellenőrzéshez friss tárolás kell a szokásos helyi adatbázisok helyett. Készen maradhat későbbi munkához. Nem indul el automatikusan, és nem ütemez teszteket.

Mielőtt elkezded

Legyen meg a projektforrás, a Docker-hozzáférés és egy meglévő megosztott proxy. Nézd át a gép kapacitását és a klónizolációt. Hideg bootstrap előtt válassz ki egy teljes, aktív stacket. A production volume-okat és mentéseket tartsd külön.

Snapshot és routing előkészítése

Előkészítés előtt commitold a tervezett megvalósítást minden érintett repositoryban. A build- vagy böngészős eredmények értékelése előtt ellenőrizd a snapshot source provenance részleteit. Erősítsd meg a kiválasztott revíziókat, a source manifestet és a ténylegesen feloldott ECS_APPLICATION_SOURCE_ROOT értéket. A későbbi gyökér-szerkesztések nem frissítik a meglévő bundle-t. Őrizd meg a rögzített bizonyítékait, és készíts elő új fizikai snapshotot, ha az aktuális forrásra van szükség.

1. Az eredeti projektgyökérből futtasd a bash testInstance.sh prepare parancsot. Ez fizikai forrás-snapshotot és privát konfigurációt hoz létre, szolgáltatások indítása nélkül.
2. Add hozzá a jóváhagyott teszt-hosztokat a meglévő proxyhoz úgy, hogy az eredeti hosztokat nem szerkeszted. Az új előkészítés deploymentből származtatott teszt-hosztokat használ. A ttrmb forrás deploymentnél ezek a https://test.bff.ttrmb.ecas.local:8443 és a https://test.account.ttrmb.ecas.local:8443 címek.
3. Állítsd be a névfeloldást a böngésző gépén és a szerver vagy WSL hoszton úgy, hogy elérje a proxyt. Bízz meg a kiválasztott nyilvános tanúsítványban a tényleges böngészőkörnyezetben. Csak .crt fájlokat importálj, soha privát kulcsot.
4. Szolgáltatói bejelentkezés előtt regisztráld a pontos Microsoft callbacket mindkét kiválasztott hoszton. Indítás előtt nézd át a tanúsítványokat és callbackeket.
5. A kért teszthez futtasd a bash testInstance.sh start parancsot. Használat előtt ellenőrizd a tényleges készenlétet.

A generált teszt-policy kikapcsolja a provider- és ingress-kapcsolókat. A teszt-snapshot nem tartalmaz automatikusan használható postafiók-connectort. Hiányzó connector vagy bejelentkezési policy a LOGIN_PROVIDER_DISABLED hibát okozhatja. Ne kerüld meg a teszt-policyt production store-ok csatolásával.

A friss Microsoft-bejelentkezés előfeltételei

A szolgáltatói bejelentkezéshez külön átnézett, operátor által jóváhagyott snapshot kell a szükséges konfigurációval. A rögzített teszt-wrapper personal-only módban marad, letiltja a Microsoftot, és véletlenszerű ECAS_DEPLOYMENT_TENANT_ID authorization névteret generál. Tartsd változatlanul ezt a policyt.

A Microsoft-bejelentkezéshez teljes BFF_MICROSOFT_CLIENT_ID, BFF_MICROSOFT_CLIENT_SECRET és BFF_MICROSOFT_TENANT_ID beállítás kell. Kell hozzá egy mentett tenant-kapcsolat is megadott consenttel, service-principal ID-val és hitelesítőadat-referenciával. A hitelesítő adat nem lehet lejárt. A kapcsolatnak egyeznie kell a beállított tenant-kiválasztással. Ez a gate akkor is érvényes, ha a Graph workerek kikapcsolva maradnak. Az OAuth-beállítások átmásolása és a redirectek regisztrálása önmagában nem elégíti ki.

Egy friss izolált adatbázishoz a Microsoft alkalmazás-bejelentkezés előtt kell az első szabályszerű tenant-kapcsolat. A normál seed nem hozza ezt létre. Bejelentkezés előtt végezd el az alábbi operátori előkészítést. Soha ne hozz létre valótlan aktív granteket, és ne jelölj meg nem ellenőrzött consentet megadottként. Az éles tárolási hitelesítő adatokat, a titkosítási kulcsokat, a sessionöket és az adatokat tartsd a teszt-környezettől izoláltan.

Egy operátor által jóváhagyott külön egyedi snapshotban, amelyben használható mentett Microsoft tenant-kapcsolat van, tartsd meg a MICROSOFT_CONNECTOR_ENABLED=true beállítást. Ez bekapcsolja a Microsoft profilt, így a szokásos Microsoft connector-szolgáltatások futnak. Az indítás elutasítja a personal-only módot (MICROSOFT_CONNECTOR_ENABLED=false), ha ilyen kapcsolat létezik. Ne kerüld meg ezt a konzisztencia-védelmet, és ne módosítsd a rögzített testInstance.sh wrapper policyt. A generált letiltó kapcsolói továbbra is érvényesek.

A Microsoft profilhoz a snapshot saját GRAPH_WEBHOOK_URL és GRAPH_LIFECYCLE_WEBHOOK_URL értéke, valamint teljes Cloudflare életciklus-kezelési beállítások is kellenek. Ne vedd át a production Graph callbackeket. Az indítás már a postafiók-onboarding előtt elutasítja a hiányzó Graph ingress- vagy Cloudflare-beállításokat.

A tényleges Cloudflare edge TLS-tanúsítványnak le kell fednie a nyilvános Graph ingress hosztnevet. Csak Universal SSL-t használó teljes Cloudflare DNS-setupban válaszd az apex nevet vagy egy egyszintű aldomaint, például a test-graph-DEPLOYMENT.example.com nevet. A mélyebb proxied hosztnevekhez külön kiállított, lefedő edge tanúsítvány kell. Lásd a Universal SSL korlátait. Ez eltér a DNS-only privát Office callbacktől, amely saját DNS-01 tanúsítványt használ, és megtarthatja a támogatott többszintű hosztnevét.

Kövesd a kanonikus értesítési setupot és a Graph kriptográfiai setupot. Használj friss, a snapshothoz tartozó client state-et és tanúsítvány-identitást, majd őrizd meg ezeket az újraindítások során és a meglévő feliratkozásokhoz. A normál inicializálás előkészíti a példányhoz tartozó helyi tanúsítványfájlokat.

A GraphOneTimeUserOnboarder a GRAPH_WEBHOOK_URL és a GRAPH_WEBHOOK_CLIENT_STATE beállítást is igényli. Generálj friss client state értéket az izolált példányhoz. Tárold a meglévő privát környezeti setupban. Állítsd be ugyanezt az értéket az onboarderhez és a WebhookCatcherhez. Irányítsd az izolált webhook és lifecycle URL-eket ennek a példánynak a WebhookCatcher szolgáltatásához úgy, hogy mindkét útvonal érintetlen maradjon. Őrizd meg az értéket az újraindítások során. Egy másik példányhoz tartozó callback nem elégíti ki ezeket az előfeltételeket.

A szabványos életciklus létrehozza vagy újrahasználja a pontosan a klónhoz tartozó Cloudflare tunnelt, és validationToken challenge-dzsel ellenőrzi mindkét nyilvános endpointot. Tartsd a privát CLOUDFLARE_TOKEN, CLOUDFLARE_ACCOUNT_ID és CLOUDFLARE_ZONE_ID értékeket a snapshot saját életciklus-gyökér .env fájljában. A Compose ezeket az x-runtime elemen keresztül adja át az életciklus-kezelésnek, nem az alkalmazás-szolgáltatások környezetének.

A Microsoft profil bekapcsolása nem indítja el a postafiók-onboardingot, és nem bizonyítja annak elkészültét sem. A szokásos Start onboarding műveletet külön használd.

A külön app-only hitelesítő adatokat a Microsoft Graph setupban készítsd elő. A kanonikus környezet-referencia határozza meg a BACKEND_TENANT_ID, BACKEND_CLIENT_ID és BACKEND_CLIENT_SECRET változókat. Ezek a hitelesítő adatok a backend Graph-hozzáférést szolgálják, a BFF_MICROSOFT_* bejelentkezési hitelesítő adatoktól külön.

Bootstrap előtt egy jogosult operátornak tényleges tokent kell kérnie, és le kell futtatnia egy csak olvasható Graph-kérést a tervezett hitelesítő adatokkal. Csak ezután használd a meglévő kanonikus kapcsolat-bootstrapet az izolált adatbázison. Az ensure helpere pusztán a konfigurációból írja be a megadott consentet. Ez az írás nem bizonyítja a külső consentet vagy a Graph-hozzáférést. A jelenlegi alkalmazásban nincs normál connector-létrehozó adminisztrációs API vagy setup CLI. Ehhez az előfeltételhez operátori előkészítés kell, nem automatizált bootstrap-parancs.

Alkalmazás-bejelentkezés után végezd el a külön Microsoft postafiók-összekapcsolást. Az alkalmazás-bejelentkezés önmagában nem kapcsolja össze a tervezett postafiókot. Onboarding előtt nyisd meg az Open email key setup lehetőséget, amikor megjelenik. Használd a kiválasztott HTTPS origint beállított böngészős tanúsítvány-megbízhatósággal.

Új tulajdonosnál válaszd a Generate and download email key gombot a titkosítási párbeszédablakban. Tárold biztonságosan a backupot. Jelöld be az I saved my backup in a safe place. megerősítést. Ezután válaszd az Activate email encryption gombot.

Meglévő tulajdonosnál ehelyett importáld a tulajdonos eredeti backupját. Kövesd a személyes kulcs biztonsági mentését és feloldását. Ezután térj vissza az onboardinghoz, és válaszd a Start onboarding gombot. A Graph értesítési kulcsok és a személyes e-mail-kulcsok külön célt szolgálnak.

A Microsoft deployment tenant kiválasztása bootstrap előtt

Külön előkészített, operátor által engedélyezett Microsoft-változatnál az első authorization bootstrap előtt válaszd ki az ECAS_DEPLOYMENT_TENANT_ID értéket. Állítsd a tervezett, ellenőrzött app-only BACKEND_TENANT_ID értékre, amely az Entra tenantot azonosítja. Bootstrap előtt futtasd le a fenti hitelesítőadat-ellenőrzéseket. Ez az azonos tenantra vonatkozó követelmény a jelenlegi legacy Microsoft-onboarding admission-útvonalra érvényes.

Ha az ellenőrzött Microsoft-identitás másik deployment tenanthoz tartozik, a BFF meglévő ellenőrzött Microsoft postafiók-kötést és alkalmazáskapcsolatot vár el. A friss onboardingnál nincs ilyen postafiók-kötés. Ha az alapértelmezett véletlenszerű deployment tenant mellett engedélyezed a Microsoftot, a POST /api/onboarding/start hívás ezért HTTP 409 választ adhat. A C# Graph onboarder V1 authorization admissiont és egyező tenantot vár el. A meglévő legacy admission-útvonal nem támogatja a friss Microsoft-onboardingot eltérő deployment tenantok között.

Tarts fenn független teszt-adatbázisokat, hitelesítési és titkosítási kulcsokat, object store-okat, Kafka- és Qdrant-névtereket, valamint cookie-kat. A tenant ID önmagában nem izolálja a tárolást. Az egyező Entra tenant nem hatalmaz fel megosztott éles tárolás vagy kulcsok használatára.

Ha a teszt már tartalmaz inicializált authorization állapotot, ne csupán az .env tenant-értékét módosítsd. Minden migráció előtt készíts és őrizz meg biztonsági mentést. A teljes migrációnak le kell fednie a saját tulajdonú authorization névteret, a jogosultságokat (grants) és az előzményeket. Másik megoldásként állítsd le a kiválasztott teszt-futtatókörnyezetet, őrizd meg az adatait, majd bootstrap előtt készíts elő friss, izolált Microsoft-változatot a tervezett tenanttal. Soha ne módosítsd a megváltoztathatatlan (immutable) provider-kötéseket, és ne kerüld meg a capability-védelmeket. Ezek az előfeltételek nem igazolják a sikeres éles onboardingot.

Tanúsítványok és callbackek

A nyilvános nevek kiválasztásához használd a két opcionális origin selectort. A futásidejű identitás és a volume-ok izoláltak maradnak. Ugyanez a referencia felsorolja mind a nyolc származtatott URL-változót.

A proxy routing, a tanúsítvány-lefedettség és a kliensoldali megbízhatóság külön előfeltétel. Adj hozzá külön BFF és Account útvonalakat a saját futásidejű upstream céljaikhoz. Ne irányítsd az Accountot a BFF hoszton keresztül. A proxy tanúsítványnak le kell fednie mindkét kiválasztott hosztnevet a Subject Alternative Names (SAN) mezőben. Vedd fel a származtatott FormGen és dokumentációs hosztokat is, ha használod ezeket a szolgáltatásokat. A megjelenített Common Name (CN) nem igazolja a SAN-lefedettséget.

A meglévő proxy helperek csak új felvételeket (create-only) terveznek, és elutasítják az ütköző hosztokat. Őrizd meg az éles hosztokat, a tanúsítványokat és a proxy állapotát. A teszt életciklus nem tudja elindítani vagy újraindítani a megosztott proxyt. A jóváhagyott útvonalak felvétele igényelheti a konfiguráció újratöltését.

A kiszámított teszt-origint használó új BFF hosztterveknél a proxy elhalasztja a DNS-feloldást az /api/google-mailbox/complete útvonalhoz. Ez védi a proxy indítását, mielőtt a BFF upstream létrejönne. A pontos útvonal és az access-control viselkedés változatlan marad. Ehhez az útvonalhoz az access- és error-logok továbbra is kikapcsolva maradnak. Az Account megtartja a külön útvonalát.

Az alkalmazás indítása előtt ellenőrizd, hogy a saját tulajdonú útvonal aktív-e az Nginx Proxy Managerben (NPM), és működik-e a TLS. Az alkalmazás HTTP-kérései 502 választ adhatnak, amíg az upstream el nem indul. A sikeres TLS önmagában nem bizonyítja az alkalmazás készenlétét.

Ez a módosítás csak az új terveket érinti. Egy meglévő offline hoszt továbbra is jelezhet host not found hibát a régi literális upstreamre. Az operátornak át kell néznie a pontos tulajdonjoghoz kötött javító helpert, a docker/proxy/office_deferred_dns.py::repair_plan függvényt. Alkalmazd a javítást hitelesített NPM-kezelésen keresztül, az office_routes.reconcile és az apply_changes tulajdonjogi és versenyhelyzeti ellenőrzéseivel. Őrizd meg a többi hosztot és az egyedi útvonalakat. Az alkalmazásban nincs normál javító gomb vagy operátori setup-parancs ehhez az eljáráshoz.

Ha az upstream indulása után mented a régi hosztot az NPM-ben, az átmenetileg aktiválhatja a literális konfigurációját. A tartós javításhoz továbbra is a halasztott DNS-es javító helper kell. Emiatt a hiba miatt ne futtasd újra az első gépes setupot, ne állítsd alaphelyzetbe az adatokat, és ne törölj tanúsítványokat.

Tanúsítvány-megbízhatóság a böngészőkörnyezetben

A proxy tanúsítvány létrehozása vagy kiválasztása nem állítja be a böngészőoldali megbízhatóságot. Csak a kiválasztott nyilvános proxy.crt fájlt importáld, soha a privát kulcsát. Importálás előtt hasonlítsd össze az X.509 SHA-256 fingerprintjét az egyes kiválasztott HTTPS hosztok által ténylegesen kiszolgált tanúsítvánnyal:

openssl x509 -in '<selected public proxy.crt>' -noout -fingerprint -sha256

Cseréld le a helyőrzőt a kiválasztott nyilvános tanúsítvány útvonalára. Hasonlítsd össze az eredményt az egyes hosztok böngészőben látható tanúsítványával. Eltérő fingerprintnél állj meg, és ellenőrizd a kiválasztott route-ot és tanúsítványt. Ellenőrizd a névfeloldást a böngésző gépén és a szerver vagy WSL hoszton is. Mindkettőnek a tervezett proxyt kell elérnie.

A T3 preview böngésző futhat Linux/WSL környezetben akkor is, ha a T3 felület Windowson fut. Ellenőrizd a tényleges böngészőkörnyezetet. A Windows Root importálás nem ad megbízhatóságot a Linux/WSL preview-nak.

Windows böngésző

Másold a kiválasztott nyilvános tanúsítványt a Downloads\proxy.crt útvonalra. Futtasd ezt a parancsot PowerShellben:

certutil.exe -user -addstore Root "$env:USERPROFILE\Downloads\proxy.crt"

Az aktuális felhasználó megbízható Root tárolója interaktív jóváhagyást kérhet. Hagyd jóvá a Windows ablakot az importálás befejezéséhez.

Linux/WSL Chromium preview

Ubuntun a libnss3-tools csomag adja a certutil eszközt. Használd azt a fiókot, amelyik a preview böngészőt futtatja. Őrizd meg a meglévő Network Security Services (NSS) adatbázist és bejegyzéseit.

A Chromium Linux tanúsítványkezelési útmutatója szerint M146-tól az alapértelmezett útvonal ~/.local/share/pki/nssdb. Ha létezik a régi ~/.pki/nssdb, a Chromium azt használja. Importálás előtt ellenőrizd, melyik adatbázist nyitja meg ténylegesen az érintett böngésző. Ne hozz létre helyette új adatbázist.

A parancsokat a böngészőt futtató fiók Linux shelljében futtasd. Állítsd a browser_nss_db értékét az ellenőrzött könyvtárra. Ez a példa az M146 alapértelmezését használja:

browser_nss_db="$HOME/.local/share/pki/nssdb"
certutil -L -d "sql:$browser_nss_db"

Ha a böngésző a meglévő régi adatbázist használja, válaszd helyette a $HOME/.pki/nssdb útvonalat. Válassz még nem használt nickname-et. Csak a kiválasztott, ellenőrzött fingerprintű nyilvános leaf tanúsítványt importáld. Ehhez az önaláírt szervertanúsítványhoz (CA:false) használj P,, peer trustot. Ne adj CA trustot a C,, jelöléssel.

certutil -A -d "sql:$browser_nss_db" -n 'chosen unique nickname' -t 'P,,' -i '<selected public proxy.crt>'
certutil -L -d "sql:$browser_nss_db" -n 'chosen unique nickname'

Importálás előtt cseréld le a nickname-et és a tanúsítvány útvonalát. Utána ellenőrizd a bejegyzés fingerprintjét és P,, trustját. A másik kiválasztott hosztnál csak akkor ismételd meg, ha eltérő leaf tanúsítványt szolgál ki. Őrizd meg a többi bejegyzést. A Linux rendszer trustja önmagában nem eredményez Chromium NSS elfogadást.

Újraindítás és ellenőrzés

A megbízhatóság módosítása után zárd be teljesen, majd nyisd meg újra csak az érintett böngésző- vagy preview-folyamatot. Amikor lehet, használd az alkalmazás preview vezérlőit. A lap újratöltése vagy bezárása és újranyitása megtarthatja az elavult tanúsítvány-ellenőrzési eredményeket. Ha folyamat-újraindítás kell, azonosítsd a böngésző szülőfolyamatát a profilútvonala alapján. Csak ezt a folyamatot állítsd le.

Ne állítsd le a T3 backendet vagy az összes Chrome-folyamatot.

Nyisd meg mindkét kiválasztott HTTPS hosztot a tényleges böngészőkörnyezetben. Bejelentkezés előtt ellenőrizd, hogy egyik sem jelez tanúsítványhibát. Tartsd bekapcsolva a HTTPS tanúsítvány-ellenőrzést. Ne használj általános megbízhatósági megkerülést vagy a HTTPS-ellenőrzést kikapcsoló opciókat.

Microsoft callbackek

Regisztráld ezeket a Microsoft redirect URI-kat a példa deploymenthez:

https://test.bff.ttrmb.ecas.local:8443/api/auth/callback/microsoft
https://test.account.ttrmb.ecas.local:8443/api/auth/callback/microsoft

Cseréld le a deployment, a suffix és a port értékét a kiválasztott értékekre. Mindkét jelenlegi handler az /api/auth/callback/microsoft útvonalat használja. A további /api/account/connect/microsoft/callback regisztráció nem hoz létre handlert. A jelenlegi forráskódban nincs alias ehhez az útvonalhoz, ezért a jelenlegi handlerhez nem szükséges.

Bekapcsolt Account-bejelentkezésnél az Account kezeli a Microsoft-bejelentkezési callbacket. A BFF kezeli a postafiók-összekapcsolási callbacket, és a callback origint a MAILGEN_PUBLIC_URL értékből származtatja. Regisztráld mindkét fenti pontos URI-t. Az origin allowlist megtartja a pontos origineket a sémával és a porttal együtt, a két folyamat pedig külön OAuth state cookie-kat tart meg. A sikertelen postafiók-összekapcsolás a meglévő lefordított riasztást (alert) használja.

A párosított teszt-hosztok ecas-shared-test cookie-kat és külön OAuth state neveket használnak. A prefix nélküli deployment megtartja az ecas-shared értéket. A közös domain korlátaihoz és a pontos HTTP localhost kivételhez lásd a hitelesítési izolációt.

A konfigurálás után ellenőrizd a tényleges bejelentkezést, a kijelentkezési izolációt és a Microsoft callback roundtripet a kiválasztott futtatókörnyezetben. A generált URL-ek, a proxy-tervek és a tanúsítványfájlok önmagukban nem bizonyítják ezeket az eredményeket. A távoli dependency-próbák szintén nem igazolják a teljes hibrid alkalmazás-folyamatot.

Megtartás és folytatás

Cél	Parancs
Állapot vizsgálata	bash testInstance.sh status
Leállítás a teszt-adatok megőrzésével	bash testInstance.sh stop
Előkészített konténerek folytatása	bash testInstance.sh quick-start
Szokásos újraindítás	bash testInstance.sh restart

A snapshot nem kapja meg automatikusan a későbbi szerkesztéseket. Őrizd meg a meglévő befagyasztott bundle-öket és a korábbi bizonyítékaikat. Használj kifejezetten jóváhagyott új snapshotot a módosított origin helperek és konfiguráció felvételéhez, a meglévő teszt-adatok megőrzése mellett. A fájlspecifikus forrás-belefoglalás nem kapcsolja ki a secret- és útvonalszűrőket.

Az alapértelmezett generált teszt-profil továbbra is ECS_MEMORY_GIB=30, bounded módban, 4 GiB swap-kerettel, és az indítási minimum-ellenőrzés a mérvadó. A megfigyelt 33 kiválasztott szolgáltatással futó, külön előkészített és operátor által engedélyezett Microsoft-tesztnek nagyobb meglévő profil kell. Az onboarder minimuma 2048 MiB, a teljes fejlesztői independent queue minimuma pedig 768 MiB. Ez az összeállítás a 30 GiB-os profil minimumszintjein 32,192 MiB-ot igényel, ezért meghaladja a 30 GiB-ot. A 35+ GiB-os profil minimumszintjein 38,592 MiB kell, ami belefér a kiválasztott 40 GiB-os profilba. Ez nem általános alapértelmezés, és nem állít szabad gazdagépi RAM-ot.

Szokásos újraindítás előtt csak egy teljes stacket tarts aktívan, és ellenőrizd a gazdagép RAM- és swap-admission feltételeit. Őrizd meg a meglévő adatbázisokat, az object store-okat, a volume-okat és a kulcsokat. A jóváhagyott profilmódosítást a kiválasztott futtatókörnyezet szokásos újraindításával alkalmazd, reset nélkül. Egy szolgáltatás cgroup out-of-memory (OOM) hibája nem bizonyít gazdagépszintű OOM-ot. A teljes stack leállítása előtt ellenőrizd a gazdagép memóriáját és a kernel OOM-bizonyítékokat.

A Graph FTS export most chunkonként egy elemet dolgoz fel, hogy csökkentse a batch-pufferelést. Egyetlen nagy elemnek továbbra is megfelelő szolgáltatási memóriakeret kell. A profil kiválasztása nem bizonyítja a sikeres indítást vagy a postafiók elkészültét. Bármelyik eredmény állítása előtt kérj tényleges futási bizonyítékot.

A memória-iránymutatáshoz, a friss kulcsokhoz, a távoli namespace-ekhez és a proxykorlátozásokhoz lásd a teszt-futtatókörnyezet részleteit. Ebbe a környezetbe ne csatolj eredeti fejlesztési adatbázisokat, object storage-t vagy nem kapcsolódó mentés-teszt volume-okat.

Meglévő regisztrált böngésző-origin használata

Részesítsd előnyben a saját regisztrációval és tanúsítvánnyal rendelkező, deploymentből származtatott teszt-hosztokat. Ha egy ellenőrzés kifejezetten meglévő böngésző-origint igényel, az operátornak külön snapshotot és annak privát konfigurációját kell átnéznie. Ez nem a testInstance.sh egyedi azonosítós opciója. A rögzített teszt-bundle-t hagyd változatlanul. Lásd a snapshot életciklus-parancsokat.

Egy engedélyezett böngésző-originhez, például a https://bff.ttrmb.ecas.local:8443 címhez a nyilvános böngésző- és auth-URL-eknek egyezniük kell a proxy-útvonalakkal. Bejelentkezés előtt ellenőrizd a tartozó Account origint és a regisztrált Microsoft callbacket. Az olyan ingress-aliasok, mint a ttrmb-bff és a ttrmb-account, kiszolgálhatják ezeket a meglévő proxy-célokat, miközben a belső azonosító és a tárolás egyedi marad.

Ebben a kizárólagos alias-időablakban tartsd leállítva az eredeti éles példányt. Két példány nem szolgálhatja ki ugyanazokat az aliasokat. Őrizd meg az eredeti tárolást és kulcsokat, a megosztott proxyt és a nem kapcsolódó monitoringot. Indítás előtt ellenőrizd ezeket a feltételeket. A routing-konfiguráció önmagában nem bizonyítja, hogy a bejelentkezés vagy a távoli szolgáltatások működnek.

Privát placement-változatok előkészítése

Az operátor külön privát FullLocal és valódi PartialRemote környezeti változatokat készíthet elő. Az aktív gyökér .env választja ki a módot. Őrizd meg a helyi PostgreSQL-t, az S3-at, a hitelesítési és titkosítási kulcsokat, valamint a volume-okat mindkét változatban. Váltás előtt állítsd le a kiválasztott futtatókörnyezetet. A szokásos start vagy restart alkalmazza a kiválasztott konfigurációt. A quickStarter.sh csak a meglévő konténereket folytatja.

A megtartott helyi OpenSearch-adatokhoz bármelyik módban lásd a helyi OpenSearch lemez-watermarkokat. Az opcionális override a fizikai runtime-gyökér .env fájljába tartozik, és szokásos újraindítást igényel. Az átmásolt engedélyezett konfiguráció a célkörnyezetben is bekapcsolja az override-ot.

A valódi PartialRemote indítása előtt ellenőrizd a saját tulajdonú távoli Kafka cluster-identitást és a meglévő Qdrant collectiont. Az egyedi topicok, consumer groupok és collection-nevek nem helyettesítik a Kafka cluster-identitást. Lásd a változatok váltását és a dependency-követelményeket, valamint a kanonikus távoli deployment placementet.

Újrahasználható privát Office callbackhez kövesd az explicit callback setupot az eredeti gyökérből. Ehhez fizikai cél-runtime, a meglévő egészséges megosztott NPM HTTPS-leképezés és helyi Tailscale kell. Kellenek még a 100.64.0.0/10 tartományba eső /32 renderer Tailscale IPv4 forrás-CIDR-ek és az eredeti gyökér Cloudflare hitelesítő adatai is. Az opcionális suffix külön privát callbacket származtat nyilvános DNS-01 tanúsítvánnyal. Nem visz át éles útvonalakat, és nem módosítja a távoli renderer megbízhatóságát. A FullLocal helyi marad, a valódi renderer-folyamatot pedig külön ellenőrizd. A jelenlegi előkészített távoli Coolify rendererhez a tényleges Coolify szolgáltatás-konfigurációban mentett teljes, átnézett COLLABORA_CONTENT_SECURITY_POLICY is kell, a frame-ancestors direktívában a pontos MAILGEN_PUBLIC_URL originnel.

Második callbackhez a távoli operátor egyszer másolja át a tényleges származtatott REMOTE_WOPI_ORIGIN értéket a távoli WOPI_ADDITIONAL_CALLBACK_ORIGIN változóba. A származtatott DNS-példa a https://test.wopi.ttrmb.ecs.t42.hu:8443 cím. Ez az opcionális beállítás adja a távoli Collabora aliasgroup2 értékét, üres alapértéke pedig nem ad hozzá hosztot. Használj kanonikus, pontos HTTPS origint wildcard, hitelesítő adatok és elérési út nélkül. Tartsd meg a kötelező WOPI_CALLBACK_ORIGIN változót az aliasgroup1 mezőben, és őrizd meg a meglévő jóváhagyott origineket. Lásd a callback konfigurációs táblázatot és a célzott újralétrehozási eljárást.

Tartsd összhangban a mentett Coolify nyers és generált Compose, valamint szolgáltatás- és renderelt környezeteket, mielőtt csak az ellenőrzött Collabora szolgáltatást hozod létre újra. Őrizd meg a többi konténert, az adatokat és a proof key-t. A callback hoszt megbízhatósága különáll a böngészős CSP frame-ancestors direktívától és a DNS/TLS beállítástól. Állítsd be a callback-megbízhatóságot és a böngészős beágyazást is. Az elfogadás addig függőben marad, amíg egy tényleges dokumentum be nem tölt a gyökéralkalmazásban.

Tartsd meg a pontos public-origin és útvonal-tulajdonjogot az Office-hoz. A sikeres távoli dependency-próbák nem igazolják a teljes hibrid alkalmazás-folyamatot vagy az Office callbacket.

Friss storage esetén a szokásos hideg indítás a normál seed előtt betölti a kanonikus actor-jogosultsági és policy SQL-t. Ezután csak akkor futtatja az authorization migrációkat, ha a betterauth.user és az authorization.subjects globálisan üres, és a deployment tenantnak nincs migrációs markere. A meglévő adatbázisokhoz az explicit authorization migrációs folyamat kell. Ne helyettesítsd ezt a folyamatot csupán egy marker beszúrásával vagy az authorization gate megkerülésével.

A BFF fejlesztői konfigurációja wildcard nélkül engedélyezi a MAILGEN_PUBLIC_URL hosztnevét a HMR-hez a meglévő Account auth hosztnevek mellett. Tartsd összhangban ezeket a nyilvános URL-eket a proxy-útvonalakkal. A next.config.js módosítása után indítsd újra a BFF fejlesztői szolgáltatást.

A MAILGEN_PUBLIC_URL a pontos origint (séma, hosztnév és port) is hozzáadja a BFF hitelesített realtime és cookie sync folyamataihoz. A HTTP origin-ellenőrzések is tartalmazzák a Complexity mutációknál, a jóváhagyásoknál, a composer draft attachmenteknél, az admin proxy mutációknál és a keresési mutációknál. Ezek az ellenőrzések az URL origint használják, míg a HMR csak a hosztnevet használja. Állítsd be a konkrét nyilvános URL-t, wildcard nélkül. A session- és jogosultság-ellenőrzések továbbra is érvényesek.