Din Prenly Onboarding

• Google | Skapa ett Google-konto

  4 Aug 2026

  Ett Google-konto krävs för att få åtkomst till tjänster som Google Play Console. Observera: Skapa ett Google-konto, inte ett Google Workspace-konto. Ett Google Workspace-konto kräver en betald prenumeration. Tips: Vi rekommenderar att du använder en gemensam eller generell e-postadress (till exempel apps@foretag.se) som flera personer i organisationen har tillgång till. På så sätt behåller ni åtkomsten vid semester, sjukdom eller personalförändringar.   Alternativ 1: Skapa ett Google-konto under registreringen av Play Console Om du ska skapa ett konto för Google Play Console kan du skapa ditt Google-konto direkt under registreringen. Klicka här för att komma igång.   Alternativ 2: Skapa ett Google-konto direkt Du kan också skapa ditt Google-konto i förväg via den här länken. Följ sedan stegen nedan: Steg 1:Klicka på Skapa konto. Steg 2: Välj För eget bruk. Om du väljer För jobbet eller företaget skapas i stället ett Google Workspace-konto. Steg 3: Ange kontoinnehavarens förnamn och, om du vill, efternamn. Obs: Google kan senare kräva att kontoinnehavaren verifierar sin identitet med en giltig legitimation. Kontot bör därför registreras på en verklig person. Ange sedan ditt födelsedatum. Att ange kön är frivilligt. Välj därefter ett av följande alternativ: Använd din befintliga e-postadress genom att välja Använd din befintliga e-postadress. Eller skapa en ny Gmail-adress genom att följa anvisningarna. Steg 4: Verifiera din e-postadress (om du använder en befintlig adress). Google skickar en verifieringskod som du behöver ange för att fortsätta. Steg 5: Skapa ett säkert lösenord. Aktivera sedan tvåfaktorsautentisering (2FA). Detta rekommenderas starkt och krävs för många av Googles tjänster.   Nästa steg När ditt Google-konto har skapats kan du använda det för att logga in på Googles tjänster, till exempel Google Play Console. Mer information finns i Googles officiella dokumentation:https://support.google.com/accounts/answer/27441

• ID-token

  30 Mar 2026

  En ID-token kan användas för att extrahera det unika användar-ID:t efter att användaren har auktoriserat sig. Du kan också välja att kringgå användningen av en resursserver genom att använda ett anpassat anspråk i ID-token-nyttolasten.Specifikationer Om du vill använda en ID-token måste du verifiera att: ID-token följer JWT-specifikationen (RFC 7519). ID-token följer OpenID Connect Core-specifikationen. ID-token innehåller de påståenden som krävs (se OpenID-specifikationen för detaljer). Valideringen av ID-token överensstämmer med specifikationen. Utfärdare och upptäckt Prenly kräver kunskap om utfärdaren ("iss" i ID-tokenens nyttolast), där utfärdaren måste vara en giltig URI. Du kan också behöva uppfylla Discovery-specifikationen. I synnerhet följande: OpenID-providers som stöder Discovery MÅSTE göra ett JSON-dokument tillgängligt på den sökväg som bildas genom att konkatenera strängen /.well-known/openid-configuration till utfärdaren. - avsnitt Hämtning av konfigurationsinformation för OpenID-leverantörer Denna sökväg bildas genom att sammanlänka strängen issuer: {issuer}/.well-known/openid-konfiguration Anmärkningar: Utfärdaren får inte innehålla ett efterföljande snedstreck. Utfärdaren måste vara en giltig, funktionell URL. Validering ID-token måste vara verifierbar innan dess payload kan betros. För detta krävs tillgång till JSON Web Key Set (JWKS), som vanligtvis refereras till som: JKU JWKS-URI Detta är vanligen tillgängligt via: {issuer}/.well-known/jwks (eller specificeras i OpenID-konfigurationen) Ytterligare krav: Om flera signeringsnycklar används måste rubrikanspråket "kid" inkluderas i ID-token. Om endast en nyckel används antar Prenly att den nyckeln är giltig för verifiering. Du kan testa och verifiera ID-tokens med hjälp av verktyg som t.ex: https://jwt.io Testning via JWT.io Gå till https://jwt.io Klistra in din ID-token i fältet Encoded (kodat) Granska de avkodade avsnitten: Header Payload Signature Om verifieringen misslyckas: Klistra in din JWK (JSON) i fältet: "Public Key in SPKI, PKCS #1, X.509 Certificate, or JWK string formatt" Payload Förutom obligatoriska påståenden använder Prenly främst: "sub" Valfria påståenden som stöds: "email" "given name" "family name" "name" För en fullständig lista över påståenden, se specifikationen för obligatoriska och valfria påståenden. Om namn och e-post är tillgängliga: De kommer att visas i användargränssnittet efter inloggning I annat fall: En platshållare kommer att visas Anpassade anspråk (prenumerationer) Prenly stöder anpassade anspråk i ID-token: Måste vara en strängmatris Varje värde representerar en produktkod för en prenumeration Används för att ge åtkomst till skyddat innehåll Omfattningar Obligatoriskt scope: openid Rekommenderad omfattning: offline_access (för detaljer se specifikation för offline-åtkomst) Fördelar: Möjliggör längre autentiseringssessioner Viktigt beteende: Använder endast åtkomsttoken för att fastställa autentiseringsstatus Sessionens varaktighet beror på: Tokenens utgångsdatum Prenly-cachens varaktighet (minimum: 20 minuter)

• URI:er för omdirigering och URI:er för felaktig omdirigering

  30 Mar 2026

  Prenly använder för närvarande inte URI:er för felomdirigering. Följande omdirigerings-URI:er kan konfigureras i din auktoriseringsserver för att förhindra attack-in-the-middle-attacker. Prenly kommer att använda frågeparametrar som definieras av auktoriseringsflödet, men omdirigerings-URI:n bör konfigureras i auktoriseringsservern utan dem. Om du behöver mer information kan du kontakta Prenlys kundtjänst på hello@prenly.com.Inloggning Prenly stöder OAuth2-auktoriseringsflödet med auktoriseringskoden grant. Prenly kommer att använda följande omdirigerings-URI:er vid lyckad inloggning. Android: {paketnamn}://auth/oauth2-authorization-code/login-with-code iOS: {paket-ID}://auth/oauth2-authorization-code/login-with-code Webb: {webbappens URL}/authorization/auth-codeTill exempel https://your.epaper.url/authorization/auth-code Obs. Om {paketnamn} innehåller "_" så kommer det strippas bort för Android. Logga ut Prenly kommer att använda följande omdirigerings-URI:er vid lyckad utloggning, där utloggning är en auktoriseringsbegäran för att avsluta den aktuella användarsessionen på auktoriseringsservern. Android: {paketnamn}://auth/oauth2-authorization-code/logout iOS: {bundle-ID}://auth/oauth2-authorization-code/logout Webb: {webbappens URL}/auktorisation/auth-kod

• Ladda upp arkiv

  12 Feb 2026

  Med hjälp av en FTP-klient kan ett arkiv (med vanliga PDF-filer) laddas upp till oss. Här följer några enkla instruktioner. Observera: Om ditt arkiv är större än 100 GB, vänligen kontakta oss innan du laddar upp det. Namnge filerna Alla PDF-filer som laddas upp måste namnges med titel (namn eller förkortning av tidningen) och publiceringsdatum, vid behov måste även vilken del PDF-filen tillhör och sidnummer anges. Om ett nummer består av en sammanslagen PDF:title_20190101.pdf Om ett nummer består av flera PDF-filer, lägg till sidnummer:title_20190101_001.pdftitle_20190101_002.pdftitle_20190101_003.pdf Om ett nummer består av olika delar:title_20190101_partA_001.pdftitle_20190101_partA_002.pdftitle_20190101_partA_003.pdftitle_20190101_partB_001.pdftitle_20190101_partB_002.pdftitle_20190101_partB_003.pdf Det är viktigt att vara konsekvent Den angivna namnstrukturen gör det möjligt att importera filerna. Även tecken som understrykningar och punkter är viktiga. Om något av tecknen ersätts kommer filerna inte att hittas under importen och därför inte publiceras. Se därför till att namnstrukturen alltid ser likadan ut. Namngivning av utgåvor med utgåvenummer (valfritt)Som standard får en utgåva samma namn som publiceringsdatumet, till exempel 2019-01-01. Det finns även möjlighet att istället döpa utgåvan efter dess utgåvenummer, förutsatt att numret finns angivet i filnamnet på ett strukturerat sätt.För att detta ska fungera behöver varje PDF döpas enligt ett fast format, till exempel:title_1_20190101.pdftitle_2_20190201.pdf I detta exempel kan vi extrahera utgåvenummer 1 respektive 2 från filnamnet samt årtal 2019 Om ni vill använda denna funktion behöver ni meddela oss:- att utgåvenumret ska användas i namnet- vilken position i filnamnet som innehåller utgåvenumret- hur namnet ska formateras Exempel på utvisning av format:- Nr 1 - 2019- Utgåva 1, 2019

• LOGIN | CSV

  12 Feb 2026

  Ett vanligt sätt att låsa material bakom en inloggningsprocedur är att använda en CSV-fil. När en läsare försöker logga in görs en kontroll mot registret (CSV-filen) som avgör om åtkomst beviljas eller inte. Vad ska registret innehålla? En CSV-fil ser ut som en Excel-fil och önskvärd information som den bör innehålla är:- Namn- E-postadresser- Kundnummer/abonnemangsnummer/ID-nummer Var ska registret sparas? The file gets uploaded to us by using a FTP-client. Filen laddas upp till oss med hjälp av en FTP-klient.Om du inte har en FTP-klient måste du ladda ner en, till exempel FileZilla.- Ladda ner FileZilla för Mac- Ladda ner FileZilla för Windows Kom ihåg att alltid namnge filen på samma sätt varje gång en ny fil skapas, så att vi alltid hittar den när vi importerar.

• 

  Skapa en sekretesspolicy

  27 Nov 2025

  Om du inte har någon befintlig sekretesspolicy kan du skapa och hosta din sekretesspolicysida direkt i Prenly. I Prenly Workspace klickar du på Applications i menyn till vänster och väljer den applikation där du vill lägga till sekretesspolicyn. I applikationsmenyn klickar du på Sekretesspolicy. Här kan du komma igång med att skapa din integritetspolicy.   Därefter kan du antingen klistra in befintligt innehåll eller, om du inte har någon befintlig sekretesspolicy, använda vårt verktyg för att skapa en ny sekretesspolicy: https://privacy.prenly.co/   I det övre högra hörnet väljer du språkväljaren för att byta till önskat språk. Detta är viktigt att komma ihåg: Det är alltid du som är personuppgiftsansvarig som har ansvaret för att policyn är korrekt för ditt företag. Observera att sidan för närvarande inte lagrar något, så om du laddar om webbsidan kommer formuläret att tömmas.

• 

  Google | Verifiera konto

  24 Oct 2025

  I Google Play Console kommer du att se denna banner: Bild som visar banner i Google Developer-konto . Klicka på "Visa detaljer" och du kommer att se följande vy: Bild som visar instruktioner för att besöka organisationens webbplats. Klicka på "Gå till Search Console".I Google Search Console under Domän fyller du i ditt företags domän (t.ex. prenly.com). Bilden visar Google Search Console . Du kommer att se något liknande detta: Bilden visar instruktioner för domänägande via DNS-post . ... Google vill att du ska bevisa att du äger den nämnda domänen genom att lägga till en särskild kod i domänens inställningar (detta kallas en DNS TXT-post). Så här gör du det: Logga in på din domänregistrator - Gå till den webbplats där du köpte eller hanterar din domän (t.ex. GoDaddy, Namecheap, Cloudflare eller en liknande tjänst).- Logga in med dina kontouppgifter. Gå till dina DNS-inställningar - När du har loggat in hittar du DNS-inställningarna eller Zone Editor för din domän.- Den finns ofta i ett avsnitt som heter Hantera domäner eller DNS-hantering.- Leta efter något i stil med "Redigera DNS-poster" eller "Zonfilsinställningar". Lägg till TXT-posten - Typ av post: Välj TXT (som visas i skärmdumpen är detta den posttyp som Google frågar efter).- Värd/Namn: Vissa registratorer kräver att du anger @ (detta representerar rotdomänen). Andra kan be dig att lämna det tomt eller ange ditt fullständiga domännamn.- Värde/Text: Kopiera det exakta TXT-värdet från skärmdumpen: google-site-verification=xyz och klistra in det i fältet Värde eller Text. Spara posten - När du har angett alla uppgifter klickar du på Spara eller Uppdatera.- TXT-posten läggs nu till i DNS-inställningarna för din domän. ... Verifiera i Google Search Console - Gå tillbaka till Google Search Console.- Klicka på knappen Verifiera längst ned på skärmen.- Tips: Om du ser grafer och data i Google Search Console tyder det på att txt-posten har lyckats. Verifiera i Google Play Console - I Google Play, i bannern som visar "Avsluta konfigurationen av ditt utvecklarkonto", klicka på "Visa detaljer" - Klicka på "Verifiera webbplats"- Om detta leder dig till dina kontouppgifter, bläddra ner till din organisations webbplats och klicka på knappen "..." - Kontrollera om bannern på startsidan för Google Play Console försvann ... Viktiga anmärkningar- DNS-ändringar kan ta en viss tid (upp till 48 timmar) att uppdatera på internet. Om verifieringen inte fungerar omedelbart, vänta några timmar och försök igen.- Om du inte vet var din domän är registrerad eller hanteras kan du kontakta den person eller det team som ansvarar för att konfigurera din webbplats.

• Apple | Skapa utvecklarkonto

  24 Oct 2025

  För att kunna publicera en iOS-app på App Store behöver du ett Company utvecklarkonto, vilket kräver ett DUNS-nummer och ett Apple-konto. Om du inte redan har detta skapas det via Apple. Om du behöver mer detaljerade instruktioner än guiden nedan, klicka här och scrolla ner till Registrera dig i Apple Developer Program som organisation.   Börja här: Steg 1 - Apple-konto (tidigare kallat Apple ID) Apple Account skapas här: Apple-konto Tips! Ange en allmän e-postadress som flera personer på ditt företag har tillgång till. I händelse av sjukdom, semester, byte av position.   Steg 2 - D-U-N-S-nummer Om du redan har fått D-U-N-S-numret går du direkt till steg 3. För att kunna skapa ett utvecklarkonto hos Apple behöver du ett D-U-N-S-nummer. D-U-N-S kan beskrivas som ett internationellt organisationsnummer. Gå till den här länken för att kontrollera/skapa ett. Du kan också använda den här sidan för att få ditt D-U-N-S-nummer skickat till dig.   Steg 3 - Konto för utvecklare Klicka på länken och följ instruktionerna för att skapa ett konto. Var noga med att ange Company/Organization som enhetstyp senare i flödet. Efter att ansökan har skickats in kommer Apple att skicka ytterligare instruktioner via e-post inom några dagar.   Steg 4 - Bjud in Prenly till utvecklarkontot efter att Apple har godkänt ansökan i steg 3. ▪ Logga in Under "Programresurser" och "App Store Connect" väljer du "Användare och åtkomst". Här visas en tabellvy med användare. Klicka på plustecknet i menyn för att lägga till en ny användare. Lägg till Prenlys utvecklarkonto som "Admin". Namnet kan ställas in på vad du vill, men e-postadressen måste vara ios-app-manager@textalkmedia.se Kontrollera att alternativen under Developer/Additional Resources är markerade. Spara genom att klicka på Invite. Under "Användare och åtkomst" klickar du på "Integration" och väljer "Begär åtkomst". Läs igenom begäran, kryssa i bekräftelserutan och klicka på "Skicka".   Steg 5 - Verifiera uppgifter om handlaren Från och med april 2024 måste alla konton verifiera sin traderinformation för att kunna publicera appar. Läs mer och följ instruktionerna här.  

• Google | Skapa Utvecklarkonto

  24 Oct 2025

  För att publicera en Android-app på Google Play behöver du ett utvecklarkonto i Google Play Console. Innan du kan skapa kontot behöver du ett Google-konto och ett D-U-N-S-nummer.   Steg 1 – Google-konto Ditt Play Console-konto är permanent kopplat till det Google-konto som används vid registreringen. Välj därför konto noggrant, eftersom kontoinnehavaren inte kan ändras i efterhand. Om du ännu inte har ett Google-konto kan du följa den här guiden innan du fortsätter.   Steg 2 – D-U-N-S-nummer Om du redan har ett D-U-N-S-nummer kan du gå direkt till Steg 3. För att skapa ett utvecklarkonto i Google Play Console behöver du ett D-U-N-S-nummer. D-U-N-S-numret är ett internationellt företagsidentifieringsnummer. Om du inte känner till organisationens D-U-N-S-nummer kan du söka efter det på dunsnumberlookup.dnb.com och få det skickat till dig.   Steg 3 – Skapa ett utvecklarkonto i Play Console Kontrollera att du är inloggad med rätt Google-konto. Vid behov väljer du Byt konto för att logga in med rätt kontoinnehavare. Skapa ditt nya utvecklarkonto här. Logga in med rätt Google-konto.  Godkänn Googles distributionsavtal.  Google tar ut en engångsavgift på 25 USD. Välj den betalningsmetod som passar dig bäst och genomför betalningen.   Observera: Välj Organisation som kontotyp. Denna inställning kan inte ändras efter att kontot har skapats. Tips: Utvecklarnamnet du väljer visas offentligt på Google Play. Vi rekommenderar att du använder organisationens officiella namn.   Steg 4 – Bjud in Prenly Logga in på ditt Play Console-konto. Klicka på Användare och behörigheter i menyn till vänster. Välj Bjud in nya användare. Ange dev@prenly.com som e-postadress och lämna fältet Utgångsdatum tomt. Under Kontobehörigheter väljer du rollen Administratör. Klicka på Bjud in användare.   Tips: Om knappen “Bjud in användare” är gråmarkerad har något steg missats.   Steg 5 – Slutför kontoverifieringen Innan utvecklarkontot kan användas kräver Google att flera verifieringssteg genomförs. Kontrollera att följande har slutförts: Verifiera organisationen genom att ange organisationens D-U-N-S-nummer. Verifiera kontoinnehavarens identitet med en giltig ID-handling. Verifiera organisationens webbplats.   Viktigt: Ditt utvecklarkonto aktiveras inte förrän samtliga obligatoriska verifieringssteg har slutförts.   Rekommendation Vi rekommenderar att du sparar eller skriver ut betalningsbekräftelsen från Google när utvecklarkontot har skapats. E-postmeddelandet innehåller viktig information som kan behövas om appen någon gång ska flyttas till ett annat Play Console-konto, bland annat: Transaktions-ID Betalningsmetod Inköpsdatum Kontoinnehavarens e-postadress

• Integritetspolicy

  24 Oct 2025

  Enligt svensk dataskyddslagstiftning och GDPR (General Data Protection Regulation) är du, som personuppgiftsansvarig, skyldig att tillhandahålla en giltig integritetspolicy. Om du även har en Android- eller iOS-app är du skyldig att tillhandahålla en giltig integritetspolicy i enlighet med Googles och Apples riktlinjer. Om du inte har någon integritetspolicy kan du läsa mer via Skapa en integritetspolicy. Det är viktigt att komma ihåg att din integritetspolicy tydligt måste beskriva hur du, som personuppgiftsansvarig, samlar in, använder och eventuellt delar användardata. Du får inte behandla användardata som inte anges i din integritetspolicy. Användardata Personuppgifter och känsliga personuppgifter omfattar all information som direkt eller indirekt kan kopplas till en specifik fysisk person. Personnummer Kontaktuppgifter, såsom e-postadress och telefonnummer Betalningsinformation eller andra ekonomiska uppgifter Autentiseringsuppgifter (t.ex. inloggningsuppgifter) Behörighetsuppgifter (t.ex. prenumerationsinformation) Hälsorelaterad information, inklusive sexuell läggning Med andra ord, all information som kan identifiera en specifik användare bland samtliga användare av tjänsten eller produkten. Googles krav Din integritetspolicy måste... ...beskriva vilka uppgifter appen kan få åtkomst till eller samla in om användaren. ...förklara hur uppgifterna [1] används och/eller delas. ...inte kombineras med andra upplysningar som inte är relaterade till insamling av personuppgifter och/eller känsliga användaruppgifter. ...innehålla termen "Privacy Policy" någonstans i texten. Google översätter informationen till engelska, och om deras översättningsverktyg inte kan hitta uttrycket "Privacy Policy" kommer policyn att underkännas. ...vara direkt tillgänglig via en URL (webbadress) utan betalvägg, och sidan får inte vara redigerbar. En länkad PDF-fil är inte tillåten. ...inte vara ofullständig. Hela policyn måste vara tillgänglig via URL:en och får inte länka vidare till externa resurser såsom "läs mer". Källor https://support.google.com/googleplay/android-developer/answer/10144311?hl=en&sjid=13395122270323995155-EU Vanliga frågor Behöver jag en integritetspolicy? Ja, om du har en e-tidning är du skyldig att ha en integritetspolicy. Kan jag lägga min integritetspolicy bakom en inloggning? Nej. Integritetspolicyn måste vara offentligt tillgänglig i sin helhet via en webbplats. Den får inte tillhandahållas som ett nedladdningsbart dokument, exempelvis en PDF- eller MS Word-fil. Kan jag inkludera min integritetspolicy i min e-tidning? Ja, det är möjligt. Du kan publicera den som en artikel i en öppen digital publikation via Prenly Workspace, och artikeln kan fungera som en webbsida för din integritetspolicy.

• LOGIN | OAuth2

  24 Oct 2025

  Prenly stöder OAuth2 med eller utan OpenID Connect-tillägg (OIDC) så länge som auktoriseringsservern följer OAuth2-specifikationen RFC 6749. Du kommer sannolikt att behöva en auktoriseringsserver som stöder OIDC. Prenly stöder endast auktoriseringsbidraget Auktoriseringskod. Den klient som Prenly kommer att använda i OAuth2-flödet är e-pappersapplikationens auktoritet (en teknisk implementering som bestämmer hur autentisering och auktorisering ska hanteras av e-pappersapplikationen i Prenlys backend). Prenly kommer att behöva veta några saker för att kunna agera som klient för auktoriseringsflödet: - Valfritt*. Den valda utgivaren. Detta är obligatoriskt om du vill använda OpenID Connect Extension ID token claim. - Obligatoriskt. Det klient-ID som du vill att Prenly-myndigheten ska använda. - Obligatoriskt. Den klienthemlighet som du vill att Prenly-myndigheten ska använda när den utbyter det tillhandahållna auktoriseringsbidraget mot en åtkomsttoken vid autentisering av Prenly-myndigheten (klienten). - Valfri. Omfattning. Du kan välja att låta Prenly använda en mellanslagsseparerad lista med scope som definierar den utfärdade tokenens behörighet. Scope(s) kommer att användas med slutpunkten för auktorisering. - Valfri. Tillstånd. Prenly stöder generering av tillstånd i auktoriseringsbegäran. Du kan välja att antingen låta Prenly generera ett tillstånd eller att låta myndigheten hoppa över det. - Obligatoriskt. Slutpunkt för auktorisering. Prenly-myndigheten kommer att navigera användaragenten till denna slutpunkt för att initiera auktoriseringsflödet med auktoriseringsservern genom att logga in användaren för att få auktoriseringskoden beviljad. - Obligatoriskt. Token-slutpunkt. Prenly-myndigheten kommer att försöka byta ut användarens auktoriseringskod mot en åtkomsttoken eller, om auktoriseringsservern stöder det (vilket starkt rekommenderas), byta ut användarens uppdateringstoken mot en ny åtkomsttoken. Autentiseringsmetod. Som standard använder Prenly OIDC:s klientautentiseringsmetod client_secret_basic vid autentisering med auktoriseringsserverns token-slutpunkt. Prenly har även stöd för klientautentiseringsmetoden client_secret_post. Meddela Prenly om du behöver den senare, annars kommer standardautentiseringsmetoden att användas. - Rekommenderas. En extern URL för att logga ut användaren. Prenly-myndigheten kommer att använda den aktuella användarens valda användaragent för att logga ut användaren på distans på auktoriseringsservern. Prenly kan använda platshållare i URL:en när auktoriseringsbegäran skapas för att logga ut användaren genom att tillhandahålla följande:   ◦ Klient-ID; ◦ URI för utloggningsretur; ◦ URI för fel vid utloggning;   Observera att tillstånd inte kan användas. Ett exempel på en retur URI-frågeparameter är "post_logout_redirect_uri". För närvarande stöds endast HTTP-metoden GET för URL:en för utloggning. Användar-ID Prenly-myndigheten måste veta hur man extraherar det unika användar-ID:t efter att användaren har auktoriserats av auktoriseringsservern. Detta unika användar-ID, om du använder Prenly Remote Authority API, är `uid`-begärandeparametern när du begär information om användarens sammanfattning. Du kan välja en av följande metoder: - Från en egenskap i JSON-tokenens slutpunktssvar. Om du väljer detta måste du informera oss om ditt valda egenskapsnamn som innehåller användar-ID. - Från OpenID Connect "sub"-anspråket i den signerade ID-token (som returneras av token-svarsegenskapen "id_token". För att kunna extrahera användar-ID:t måste du också tillhandahålla:   ◦ Krävs. Den externa URL:en till offentliga nycklar för att validera ID-tokens. Denna URL måste innehålla en JSON Web Key Set enligt JWT-standarder (se RFC 7515), som kan refereras till som antingen JKU eller JWKS. ◦ Valfritt. Egenskapsnamnet i användardatasvaret som innehåller ett kundnummer. ◦ Obligatorisk. Prenly behöver känna till utfärdaren som måste matcha "iss"-påståendet i ID-token vid verifiering av ID-token. För mer information se ID-token. - Från egenskapssvaret "sub" från en UserInfo-slutpunkt. För att använda denna metod måste du också tillhandahålla:   ◦ Obligatoriskt. UserInfo-slutpunktens URL. Endpointen används för att hämta grundläggande information om användaren genom att använda användarens access token för att auktorisera begäran. ◦ Valfritt. Egenskapsnamnet i användardatasvaret som innehåller ett kundnummer. Resursserver Du kan välja en resursserver som Prenly stöder eller så kan du kontakta oss på hello@prenly.com för att göra en begäran till Prenly om att stödja din specifika resursserver som en integrationsuppgift, som Prenly kan stödja baserat på en betald utvecklingsuppgift. Prenly stöder Prenly Remote Authority API från version 1.4 eller högre som en resursserver. Se vår allmänna information om Prenly Remote authority API för konceptet med detta API. För att implementera Prenly Remote authority API som en resursserver, se API-specifikationen för ändpunkten /oauth2/getUser. Den "resurs" som Prenly begär från resursservern är en lista över prenumerationsprodukter som är associerade med användaren. Produkterna, i form av en produktkod, anger användarens prenumerationsstatus där varje kod är konfigurerad för att ge läsåtkomst till publikationer i din e-pappersapplikation. För att bevilja rätt läsåtkomst beroende på prenumerationsprodukten måste du också informera Prenly om vilka publikationer som produktkoden ger läsåtkomst till. Alla okända produkter ignoreras. Du kanske inte behöver en dedikerad resursserver... Prenly kan kringgå en traditionell resursserver helt och hållet om din UserInfo-slutpunkt kan avslöja prenumerationsstatusen för resursägaren - användaren. Om din UserInfo-slutpunkt är kapabel behöver du bara tillhandahålla anspråket (egenskapsnamnet) i UserInfo-slutpunktens JSON-svarsdata. Anspråksvärdet måste vara en JSON-lista (array) med strängar. Varje listobjekt representerar en produktkod för prenumerationen. Tillhandahålla information När du har all information som krävs kontaktar du Prenlys kundtjänst på hello@prenly.com med informationen. Teamet kommer sedan att konfigurera den valda e-pappersapplikationens Prenly-auktoritet för att använda OAuth2 åt dig.

• Remote API

  24 Oct 2025

  Syftet med detta dokument är att förklara: 1. ...hur Prenlys ekosystem gör det möjligt att hantera autentisering och auktorisering av användare med hjälp av en teknisk infrastruktur som ägs av utgivaren eller en tredje part. 2. ...hur en teknisk implementering kan göras genom att bygga ett modest rest-API som följer specifikationen "Prenly Remote authority API". Kontakt Vänligen kontakta oss via e-post på hello@prenly.com eller via telefon på +46-31-3884740 för frågor eller problem angående detta API. Definitioner Autentisering är processen att verifiera någons eller någots identitet, dvs. om de är den de utger sig för att vara, innan åtkomst till skyddade data beviljas. Normalt görs detta genom att tillhandahålla vissa referenser, t.ex. ett användarnamn och ett lösenord. Givet att uppgifterna matchar en lagrad post "verifieras" (autentiseras) användaren genom att tillämpa principen att användaren visste något som bara den "riktiga" användaren skulle veta. Auktorisering är den process där man bestämmer vilka resurser en användare har tillgång till, dvs. vilka data användaren har behörighet att komma åt och vad användaren får eller inte får göra. För Prenly innebär detta att bestämma vilka publikationer som användaren kan se och öppna för att läsa. Ett API(Application Program Interface)är en uppsättning rutiner, protokoll och verktyg för att hantera interaktionen mellan olika system eller delar av system, och dikterar kommunikationen mellan systemen. I Prenly är en auktoritet en teknisk implementering som bestämmer hur autentisering och auktorisering hanteras av en Prenly-applikation i Prenlys backend. Introduktion till Prenly Remote Authority API ger möjlighet att ersätta Prenlys hantering av auktorisering och/eller autentisering genom att implementera API-slutpunkter som följer en API-specifikation, vilket gör det möjligt för en Prenly-kund att autentisera och auktorisera utifrån sitt system, sina krav och behov. I grund och botten gör detta det möjligt för Prenly-applikationens myndighet att auktorisera och/eller autentisera användare när de interagerar med Prenly-applikationen, dvs. när de läser publikationer i en app, genom proxy av Prenly Remote Authority API. Prenly-myndigheten kommer att förmedla autentiserings- och auktoriseringsförfrågningar mellan användare och Prenly där ingen direkt kommunikation tillåts mellan användare och API-implementering. Istället informerar API-implementeringen Prenly-myndigheten om hur den ska agera på användarnas autentiserings- och auktoriseringsförfrågningar. Implementera ditt API Förstå hur användaren använder Prenly-applikationen Prenly-applikationer Prenly förser slutanvändaren med applikationer som främst används för att läsa publikationer och artiklar. Applikationen är antingen en inbyggd mobilapp på Android- eller iOS-plattformen eller vår responsiva webbaserade e-läsare. Dessa två applikationstyper erbjuder en liknande användarupplevelse. Applikationen kan innehålla publicerade publikationer som är offentliga för alla, samt skyddat innehåll som kräver någon form av tillstånd för att kunna konsumeras. För inbyggda appar är det också möjligt att låta alla icke-inloggade användare konsumera vissa publikationer gratis innan inloggning krävs. Navigera i applikationen När en användare använder applikationen kan han eller hon normalt se startsidan som innehåller komponenter som visar publicerade publikationer. Publika publikationer kan öppnas och läsas genom att välja publikationen. Men när användaren försöker öppna en skyddad publikation kommer programmet att kräva att användaren loggar in(autentisering). Efter inloggningen avgör Prenly om den begärda publikationen är läsbar för den användaren(auktorisering). Om så är fallet öppnas publikationen och är redo att användas. Om användaren inte har läsåtkomst meddelas användaren i appen. Det skyddade innehållet kommer inte att visas, men användaren kommer fortfarande att vara inloggad. I vissa fall kommer en applikation att kräva att användaren loggar in för att visa vissa publikationer, särskilt när inte alla publicerade publikationer kan ses av vem som helst. Till exempel publikationer som är tillgängliga via en prenumeration där andra publicerade publikationer som inte är prenumererade ska vara dolda. Konfigurera en API-miljö Förtroende för Prenly-förfrågningar Prenly skickar en fördefinierad hemlig nyckel i alla autentiserings- och auktoriseringsförfrågningar. Nyckeln är endast känd av Prenly och ditt system. Du bör kontrollera att den tillhandahållna nyckeln matchar den förväntade nyckeln för alla API-förfrågningar. Du kan också öppna upp dina API-slutpunkter för endast vissa IP-adresser för extra säkerhet. Kontakta oss för att få en uppdaterad lista över IP-adresser som Prenly kommer att använda i förfrågningar om du vill ha denna extra säkerhet. Kryptera trafiken Vi rekommenderar starkt att du inte tillåter någon okrypterad HTTP-trafik till ditt API. Använd HTTPS! Tillåt ett REST-liknande beteende Prenly-förfrågningar görs för närvarande med HTTP POST, men API:et bör inte vara begränsat till att använda några HTTP-metoder för framtida endpoint-expansion. Se den aktuella API-specifikationen för mer information eftersom API-specifikationen har sista ordet i eventuella avvikelser från denna dokumentation. I API-svar används HTTP-statuskoder för att informera Prenly om resultatet. Du måste kunna svara med olika HTTP-statuskoder, både för lyckade förfrågningar och för datafel, körtidsfel och oväntade serverfel. Parametrar för begäran skickas för närvarande som JSON i begärans kropp. Alla slutpunkter svarar för närvarande med JSON i svarskroppen. Bekanta dig med OpenAPI 3.0 API-specifikationen dokumenteras i en yaml-fil enligt OpenAPI 3.0-standarden (tidigare Swagger) och anger de tekniska aspekterna och kraven för API:et och varje slutpunkt, inklusive alla dataobjekt för begäran och svar. Autogenererad dokumentation finns på https://apidoc.prenly.com/remote-api/ och specifikationsfilen finns på https://apidoc.prenly.com/remote-api/spec/v1.3-specification.yaml. Gör gärna en kopia av specifikationsfilen och modifiera den till dina API-slutpunkter (URL:er) eftersom den autogenererade specifikationen innehåller generiska namngivna slutpunkter som referens. Med den här filen kan du enkelt bygga en testmiljö med färdiga verktyg som finns på https://openapi.tools/ (se avsnittet "Testing"). Läs mer om OpenAPI, inklusive specifikationen, på https://www.openapis.org/. Bygga slutpunkten för autentisering Se API-specifikationen på https://apidoc.prenly.com/remote-api/ för slutpunkterna för autentisering. Du kan välja slutpunktens URL precis som du vill, men slutpunkten måste följa API-specifikationen. Parametrar för begäran Begärandeparametrar är en del av begäran som JSON och skickas av Prenly för varje begäran. Svar vid framgång En lyckad inloggning måste svara med HTTP-statuskod 200 och ett JSON-svar med den unika identifieraren för den användare som autentiserades. Svar vid misslyckande Kända fel som beror på de angivna parametrarna för begäran måste svara med någon av HTTP-statuskoderna 401, 403 eller 412 enligt specifikationen i API-dokumentationen. Dessa fel måste innehålla ett JSON-svar som följer Error-datamodellen som du hittar längst ner på https://apidoc.prenly.com/remote-api/. Du kan välja att antingen tillhandahålla ett Error eller ett tomt JSON-objekt. För närvarande krävs endast egenskapen "message" om du tillhandahåller ett Error. Det är dock rekommenderat att även ange en "code"-egenskap. Vi rekommenderar starkt att du anger ett värde för egenskapen "message" på engelska som representerar felet på något sätt. Om din programvara har någon form av interna koder är det lämpligt att använda dem här om framtida ömsesidig felsökning kommer att behövas. Inkludera inte personuppgifter som inte behövs, t.ex. personnamn! Unika ID:n är tillräckligt bra för felsökning. Denna information visas aldrig för slutanvändaren men kan loggas i Prenly för att förenkla felsökning. Bygga slutpunkten för auktorisering Se API-specifikationen på https://apidoc.prenly.com/remote-api/ för slutpunkterna för auktorisering. Du kan välja slutpunktens URL precis som du vill, men slutpunkten måste följa API-specifikationen. Parametrar för begäran Begärandeparametrar är en del av begäran som JSON och skickas av Prenly för varje begäran. Svar vid framgång En lyckad hämtning av användarinformationen måste svara med HTTP-statuskod 200 och ett JSON-svar enligt UserSummary-datamodellen som beskrivs i specifikationen. Fälten i detta dataobjekt förklaras längst ned på https://apidoc.prenly.com/remote-api/. Vad egenskaper används till Den enda egenskapen som för närvarande inte kan lämnas tom är "uid". De andra egenskaperna kan utelämnas, men vi rekommenderar att du anger en "productCodes"-egenskap för att bättre kunna kontrollera om Prenly ska bevilja läsbehörighet till publikationer eller inte. För närvarande kommer Prenly att behandla en saknad "productCodes"-egenskap som en tom lista. Svar vid misslyckande Kända fel som beror på de angivna parametrarna för begäran måste svara med någon av HTTP-statuskoderna 403, 404 eller 412 enligt specifikationen i API-dokumentationen. Dessa fel måste innehålla ett JSON-svar som följer datamodellen Error enligt beskrivningen ovan. Testning Det är viktigt att testa din implementation för slutpunkterna för autentisering och auktorisering. Se https://docs.google .com/document/d/1UxmvDs7_Z0GwGbwCHXr4Ojpb9HaZif1nJ8YRMmztzeo/ för mer information om hur du testar dina endpoints. Vad händer i Prenly? När användaren loggar in (autentisering + auktorisering) När användaren begär att få logga in och skickar in inloggningsformuläret skickas inloggningsuppgifterna till Prenlys myndighet (krypterade med SSL). Därifrån hanterar myndigheten hur man använder dessa referenser för att autentisera användaren. För API:et Remote authority innebär detta att autentiseringsuppgifterna skickas till fjärranslutningspunkten enligt specifikationen. Prenly kommer att bearbeta API-svaret och hantera både lyckade och misslyckade autentiseringsförfrågningar där användaren kommer att se ett fel beroende på HTTP-statuskoden för felsvaret. Se nedan för mer information. Om autentiseringen lyckades... En lyckad inloggning kommer att trigga en separat auktoriseringsbegäran till API-slutpunkten för auktorisering för att hämta användarens information, som cachas i Prenly under en begränsad tid. Applikationen kommer också att visa att någon är inloggad, med namn eller e-post baserat på vilka användardata som returnerades i användarinformationen. Observera. Om en auktoriseringsbegäran direkt efter en inloggning returnerar en HTTP 401-respons kommer Prenly att tolka det som ett implementeringsfel, logga ut användaren och informera användaren om att hens inloggningsuppgifter var felaktiga. För att förhindra detta rekommenderas att använda tokenkonceptet som kan ses under UserIdentification-schemat om du är intresserad av att stödja fjärrutloggning av användaren. Om inloggningsuppgifterna var felaktiga... Om begäran var tekniskt framgångsrik, men autentiseringsuppgifterna var felaktiga, kommer Prenly-myndigheten att meddela applikationen och ett meddelande om felaktiga autentiseringsuppgifter kommer att presenteras för användaren. Om något misslyckades... Andra klient- eller serverbaserade fel, eller nätverksfel, fångas upp och loggas av Prenly. Programmet kommer att få ett lämpligt felmeddelande som presenteras för användaren. När användaren fortsätter att läsa Cachelagring för upprepade förfrågningar Cachelagring av svarsdata från en lyckad auktorisering (användarens information) eliminerar behovet av upprepade förfrågningar till fjärr-API:t för att hämta användardata som sällan ändras. Varje Prenly-kund kan välja utgångstid för cacheminnet, vi rekommenderar att du ställer in 30 minuter, där den minsta tillåtna utgångstiden för cacheminnet är 20 minuter. Återauktorisering Prenly kommer att använda det cachade resultatet för varje auktoriseringsbegäran så länge som cacheminnet inte har löpt ut. Om cachen har löpt ut kommer Prenly att utlösa en ny auktoriseringsbegäran till auktoriseringsslutpunkten i fjärr-API:t. Detta kommer att uppdatera användarens data, t.ex. produkttillgänglighet, samt de cachade data. Hantering av fel Om ett serverfel (5xx HTTP-kod) inträffar när omauktorisering utlöses förlängs utgångstiden för cachen med fem minuter. Prenly gör detta för att undvika att användare loggas ut på grund av tillfälliga nätverks- eller serverfel; användaren fortsätter att läsa som om inget hänt, och efter fem minuter görs ett nytt omauktoriseringsförsök. Detta beteende varar så länge som serverproblemet kvarstår. Prenly kommer att logga sådana tekniska problem och försöka nå kunden om detta inträffar. Att gå live När du tror att API:et är redo att tas i drift (du är klar med att utveckla och testa din implementering), kontakta oss för att ta de sista stegen. Prenly kommer att kräva information från dig för att konfigurera din implementering i Prenly. Informationen kommer att utvärderas och om allt är i sin ordning kan din implementering användas i Prenly för dina valda Prenly-applikationer för e-papper. Konfigurera Prenly Innan din implementering av fjärr-API:t kan användas i Prenly måste du tillhandahålla: - Din valda hemliga nyckel för slutpunkterna för autentisering och auktorisering - Dina valda API-slutpunkter - En lista över produkter som ska ge läsbehörighet och för vilka Prenly-titeln (endast Prenly-kända produkter i produktkodlistan från auktoriseringsändpunkten kan ge läsbehörighet) - Din önskade utgångstid för cachen - En URL där en ny användare kan skapa ett konto - En URL där en användare kan ta bort sitt konto - En URL där en användare kan återställa sitt lösenord (om de har glömt sitt lösenord) - Vi rekommenderar att du också tillhandahåller en URL där en auktoriserad användare utan några tidigare kända produktkoder kan aktivera en produkt (t.ex. köpa en prenumeration) - Användaruppgifter (användarnamn och lösenord) för testanvändaren, där användaren delas av Textalk, Apple och Google (om du har inbyggda appar) där minst en produktkod måste förbli aktiv så länge som fjärr-API:t används av Prenly-myndigheten för ditt e-papper