Migrering av mashups

Alla mashups genomförs inte på samma sätt. Se följande innehåll som en vägledning som beskriver några av de överväganden som ingår i mashup-migreringsprocessen. Kontrollera att du har gjort följande innan du försöker migrera mashups:

Du har driftsatt och konfigurerat en Qlik Cloud-klientorganisation.
Användarna kan autentisera sig via IdP, och de nödvändiga apparna har migrerats till lämpliga delade eller hanterade utrymmen, där användarna åtminstone har visningsbehörighet. Information om behörigheter för utrymmen finns i Hantering av behörigheter i delade utrymmen och Hantering av behörigheter i hanterade utrymmen.
Tillgång till klientorganisationen med rollen klientorganisationadministratör (krävs för att skapa en webbintegrering).

Du bör också känna till hur Qlik Sense-mashups vanligtvis implementeras med hjälp av JavaScript och HTML, oavsett om de bäddar in objekt bara med IFrames eller med Qlik Capability-API:erna.

För tydlighetens skull kommer nya mashups att hänvisa till de som finns i Qlik Cloud och gamla mashups kommer att hänvisa till befintliga mashups i För klienthanterat Qlik Sense.

Webbintegreringar

Dina nya mashups i Qlik Cloud kommer att ladda och bädda in innehåll från din Qlik Cloud-klientorganisation i stället för från För klienthanterat Qlik Sense. Du måste konfigurera en webbintegrering i Qlik Cloud så att den kan identifiera din mashupwebbplats (ursprung).

Webbintegreringar är en säkerhetsmekanism som gör det möjligt för webbplatser som uppvisar ett giltigt ID som är kopplat till en URL-inkluderingslista att visa inbäddade visualiseringar. Alla webbapplikationer som interagerar med Qlik Cloud kräver att en webbintegrering konfigureras i din klientorganisation.

Skapa en webbintegrering i Qlik Cloud

Du måste vara klientorganisationsadministratör i Qlik Cloud för att skapa en webbintegrering.

Gör följande:

Gå till delavsnittet Webb i Hanteringskonsol och klicka på Skapa ny längst upp till höger.
I dialogen ger du webbintegreringen ett namn.
Skriv ursprungets adress med följande format: https://domain.com. Lägg sedan till ursprunget i godkända-listan genom att klicka på Lägg till.

Anteckning om informationDu kan lägga till fler än ett ursprung.
Klicka på Skapa.

När du har skapat webbintegreringen får du ett ID. Detta är qlik-webbintegrerings-ID:t för din mashup, vilket är ett attribut eller en parameter som krävs i den nya mashup-koden.

Exempel på webbintegrerings-ID — Webbintegrerings-ID

Mer information om hur du skapar webbintegreringar finns i Hantera webbintegreringar.

Autentisering

Mashups i För klienthanterat Qlik Sense hanterar vanligtvis autentisering genom en virtuell proxy, där autentiseringsmekanismen är förkonfigurerad. Alternativen inkluderar Header, Ticket, SAML, JWT, OpenID Connect ( OIDC) och Anonymous. För mer information, se Autentiseringslösningar (endast på engelska).

I din gamla För klienthanterat Qlik Sense-mashup hanteras autentisering vanligtvis i koden innan eventuella resurser, inklusive nödvändiga statiska Qlik-filer och -bibliotek, laddas via denna virtuella proxy.

Till exempel,

Med Ticket och JWT görs vanligen ett anrop till autentiseringsmodulen i backend för att skapa ett Qlik-ärende eller en JWT-token på ett säkert sätt.
Med Header ställer en underliggande modul eller omvänd proxy in lämplig rubrik.
För OIDC och SAML måste det göras en inledande omdirigering till motsvarande identitetsleverantör som aktiverar autentiseringsflödet för att slutligen inleda sessionen med Qlik Sense, så att den kan ladda resurser och börja bädda in innehåll.

Qlik Cloud använder inte en virtuell proxy. I stället används en webbintegrering som du skapar i klientorganisationen. För autentisering finns följande två mekanismer:

Interaktiv inloggning – Den här mekanismen bygger på den konfigurerade IdP som klientorganisationen använder för vanlig åtkomst. Detta är Qlik Account IdP som standard, eller något av de tillgängliga alternativen som Okta, Auth0, ADFS, AzureAD, Salesforce, Generic och Keycloak.
JSON Web Tokens (JWT) – Den här autentiseringsmekanismen bygger på signerade JWT-tokens som vanligtvis genereras på ett säkert sätt av en backend-tjänst. I det här fallet bör det finnas en konfigurerad identitetsleverantör i din klientorganisation av typen JWT.

Mashups där Qlik-objekt är inbäddade med Capability-API:er

Autentisering med interaktiv inloggning

Potentiella uppdateringar av html-koden

Precis som i ditt För klienthanterat Qlik Sense-kombinationsprogram måste du ladda två Qlik-statiska filer i (qlik-styles.css och require.js). Men med Qlik Cloud är dessa filer direkt tillgängliga utan att det krävs någon autentisering.

Klicka för att visa i full storlek — Potentiella uppdateringar av html-koden

Potentiella uppdateringar av JavaScript-koden

Om din För klienthanterat Qlik Sense-mashup använder Capability-API:er för att bädda in och interagera med objekt i För klienthanterat Qlik Sense, se följande kod, som i det här exemplet bäddar in flera visualiseringar med hjälp av Capability-API-Qlik-biblioteket.

Konfigurationsvariabel och baseUrl för require

Med din nya Qlik Cloud-mashup måste konfigurationsvariabeln återspegla din klientorganisations värd samt webIntegrationId. Eftersom det inte finns någon virtuell proxy ska prefixet bara vara /. Du kan ställa in ett identitetsattribut så att sessionen inte delas utan endast används för kontexten för den här mashupen. Porten måste vara 443, vilket innebär att isSecure alltid är sant.

require -konfigurationen ska innehålla ditt webIntegrationId, och baseUrl är enklare eftersom kommunikationen till Qlik Cloud alltid sker via https på port 443.

API:er för laddningskapacitet

Innan du laddar Qlik Capability-API-biblioteket med require (js/qlik)kontrollerar du om användaren redan är inloggad. Du kan göra detta genom att till exempel trigga ett REST-API-anrop för den aktuella användarens metadataslutpunkt. Om svarsstatusen inte är 200 måste koden omdirigera till inloggningsskärmen och lägga in två parametrar i URL:en: returnto (din faktiska mashup-URL) och qlik-web-integration-id.

Koden körs på följande sätt:

Kontrollera om användaren redan är inloggad med en GET-förfrågan till /api/v1/users/me-REST-API-slutpunkten.
- Om svaret är negativt (svarsstatusen är inte 200) omdirigerar du till inloggningsskärmen/inloggningen genom att lägga till parametrarna return to och qlik-web-integration-id.
- Om svaret är positivt (svarsstatusen är 200), laddar du qlik/js Capability API-biblioteket med require och fortsätter att använda denna uppsättning API:er.

Den slutliga koden kan se ut som följande exempel. Med JavaScript finns det inte bara ett enda sätt att skriva den perfekta koden, så detta är bara ett giltigt kodalternativ.

Autentisering med hjälp av JSON Web Token (JWT)

Konfigurera en JWT-identitetsleverantör

En JWT-token är resultatet av krypteringen av vissa nyttolast-användarmetadata (t.ex. namn, e-postadress, grupper, ämne) som undertecknas säkert med en privat nyckel i ett certifikat. Vem som helst som har den tillhörande offentliga nyckeln för certifikatet kan validera denna token och läsa användarinformationen i den.

För att Qlik Cloud ska kunna validera dina signerade JWT-token måste du konfigurera en identitetsleverantör i din Qlik Cloud-klientorganisation av typen JWT. När klientorganisationen har konfigurerats kan den acceptera och validera API-begäranden som innehåller en korrekt signerad JWT-token för bärare.

Gör följande:

I Management Console väljer du Identitetsleverantör i delavsnittet Konfiguration för att skapa en ny leverantör.

Skapa en identitetsleverantörskonfiguration av typen JWT
Klistra in certifikatets offentliga nyckel i PEM-format i rutan Certifikat ovan.

Om din gamla mashup redan använder JWT för autentisering med För klienthanterat Qlik Sense kanske du redan vet vilka privata och offentliga nycklar som används för certifikatet. Du kanske också redan har en backend-tjänst för att skapa signerade JWT-token. Om inte, se Skapa signerade token för JWT-auktorisering.
Du kan också ange utfärdare och ett nyckel-ID – i vilket fall som helst får du dessa värden efter skapandet.

Potentiella uppdateringar av koden för den signerade JWT-token-backendtjänsten

Med För klienthanterat Qlik Sense krävdes för nyttolasten för att generera en JWT-token endast användar-ID:t och -användarkatalogen för krav, vilket krävs av den virtuella proxyn i Qlik Sense för JWT-autentisering. Med Qlik Cloud kräver denna nyttolast fler och olika kravattribut.

Du måste justera koden för backendtjänsten för JWT-tokengenerering för nyttolasten, tillsammans med de nödvändiga signeringsalternativen, för att återspegla vad som krävs med Qlik Cloud. Till exempel är utfärdare och nyckel-ID för JWT-identitetsleverantören obligatoriska signeringsalternativ. Se JWT-formatet för Qlik Sense-auktorisering för en fullständig beskrivning.

Potentiella uppdateringar av html-koden

Potentiella uppdateringar av JavaScript-koden

Kodkonceptet liknar det som används vid interaktiv inloggning. Men i det här fallet måste du i stället för att omdirigera till den vanliga inloggningsskärmen initiera en JWT-session med en POST-förfrågan till slutpunkten /login/jwt-session och skicka rubrikerna för JWT-bärartoken och webbintegrerings-ID.

Gör följande:

Kontrollera om användaren redan är inloggad med en begäran till REST-API-slutpunkten /api/v1/users/me.
- Om svaret är positivt (svarsstatusen är 200) laddar du och använder qlik/js Capability API-biblioteket med require.
- Om svaret är negativt (svarsstatusen är inte 200) aktiveras en POST-förfrågan för att inleda JWT-sessionen med den signerade JWT-token som anges.
  - Om svaret är positivt, laddar du och använder qlik/js Capability API-biblioteket med require.

Följande är ett kodexempel för den process som beskrivs ovan.

Capability-API:er och kompatibilitet i Qlik Cloud

Capability-API:erna är ett JavaScript-bibliotek som låter dig interagera med en samling olika API:er, t.ex. rot-API, visualiserings-API, app-API, globalt API, fält-API, tabell-API, variabel-API med mera. Se Capability-API:er för en fullständig lista.

Även om det råder nästan fullständig kompatibilitet mellan Qlik Cloud och För klienthanterat Qlik Sense när du använder Capability-API:er för din webbapplikation finns det vissa små skillnader eller metoder som inte är tillgängliga om du använder det här JavaScript-biblioteket för webbplatser med Qlik Cloud-implementeringar. Global API är till exempel inte tillgängligt i Qlik Cloud.

Se API-jämförelse mellan produkter för mer information.

Mashups där Qlik-objekt är inbäddade med IFrames

Förutom att hantera autentisering enligt beskrivningen i Mashups där Qlik-objekt är inbäddade med Capability-API:ermåste du känna till hur Qlik Cloud hanterar Content Security Policy (CSP).

Content Security Policy

CSP-policyn i Qlik Cloud blockerar åtkomst till Qlik-objekt från andra domäner. Detta innebär att när du bäddar in Qlik-objekt med hjälp av Single API IFrame-metoden kommer du att få frame-ancestors "self"-policyfelet.

Se Content Security Policy om du vill veta hur du konfigurerar CSP så att din mashup kan använda IFrames för att bädda in Qlik Cloud-objekt.

Mashups med enigma.js

enigma.js-biblioteket hjälper dig att kommunicera med Qliks associativa motor i JavaScript-miljöer.

Förutom den nödvändiga webbintegreringen och hanteringen av användarautentisering måste du också tänka på konceptet förfalskning av begäranden på olika webbplatser (Cross-site Request Forgery, CSRF) när du använder enigma.js på Qlik.

Förfalskning av begäranden på olika webbplatser (CSRF)

Qlik Cloud har motåtgärder för att skydda mot förfalskning av begäranden på olika webbplatser (CSRF). Alla webblösningar som interagerar med Qlik Cloud måste tillhandahålla en giltig CSRF-token för alla REST-anrop som inte är GET, inklusive WebSocket-kopplingar.

När du använder enigma.js i din webbapplikation, antingen i backend- eller frontend-koden, skapas en WebSocket-koppling. Detta innebär att en CRSF-token måste ingå som en parameter i WebSocket-kopplingen för att enigma.js-biblioteket ska kunna öppna en säker session med Qlik Cloud.

När användaren är inloggad kan en giltig CSRF-token begäras till slutpunkten /api/v1/csrf-token.

Följande kodexempel (med en inloggad användare) av enigma.js används i frontend-koden för att öppna en app och hämta layouten.

Om du vill se ett fullständigt kodexempel kan du läsa följande handledningar:

Handledning för att bygga en enkel webbapplikation.

Hantera ark i iframes med enigma.js

Var den här sidan till hjälp för dig?

Om du hittar några fel på denna sida eller i innehållet – ett stavfel, ett steg som saknas eller ett tekniskt fel – berätta för oss så att vi kan blir bättre!

Lämna din feedback här