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

  Innan du börjar: Fråga ditt IT-team eller din webbyrå om webbplatsen redan är verifierad i Google Search Console. I så fall kan du hoppa över DNS-stegen nedan och gå direkt till Verifiera i Google Play Console. Den verifierade webbplatsägaren kan godkänna din begäran. Om du använder samma Google-konto i Play Console och Search Console godkänns den automatiskt. 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 hela det unika TXT-värdet som visas i din egen Google Search Console och klistra in det i fältet Värde eller Text. Kopiera inte exempelkoden från den här guiden eller dess skärmdumpar. 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.- Vänta tills Google Search Console bekräftar att ägarskapet har verifierats. Grafer och data räcker inte som bekräftelse. 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å ”Skicka verifieringsbegäran” (Send verification request) - Om någon annan är verifierad webbplatsägare i Search Console, be personen att godkänna begäran. Om du använder samma Google-konto godkänns den automatiskt.- Kontrollera din e-post eller inkorgen i Play Console för en bekräftelse på att webbplatskopplingen är klar. Andra uppgifter för att konfigurera kontot kan fortfarande återstå. 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 i App Store behöver du ett företagskonto för utvecklare, vilket kräver ett DUNS-nummer och ett Apple-konto. Om du inte redan har detta skapas det via Apple. Innan du börjar: Vem ska skapa kontot? Någon i din organisation som är behörig att ingå avtal på organisationens vägnar – till exempel en ägare, en styrelseledamot eller en anställd som har fått den behörigheten. Denna person behöver inte ha tekniska kunskaper. Apple kallar denna person för kontoinnehavaren. Apples krav Hjälper du någon att skapa kontot? Se till att den blivande kontoinnehavaren fyller i ansökan tillsammans med dig. Hen måste logga in själv och vara tillgänglig för eventuella identitetskontroller, så att du kan fortsätta utan avbrott. Ha kontoinnehavarens foto-ID till hands: Apple kan begära ett foto-ID utfärdat av myndigheterna för att bekräfta identiteten. Se till att kontoinnehavarens telefon eller Apple-enhet finns i närheten: Apple kan skicka en säkerhetskod via SMS eller visa den på en Apple-enhet som hen redan är inloggad på. Hen måste ange den här koden för att kunna fortsätta. Företagets webbplats: Du behöver en offentligt tillgänglig, fungerande webbplats som tydligt kan kopplas till ditt företag. Vi rekommenderar en sida med juridisk företagsinformation som anger det fullständiga registrerade företagsnamnet, inklusive bolagsform och företagsadress. Uppgifterna bör stämma överens med D-U-N-S-registret. Om webbplatsen har publikationens namn ska det tydligt framgå vilket företag som driver den. E-postadress för arbetet: Ha en e-postadress på företagets domän redo som du har tillgång till, till exempel hello@prenly.com. En adress som prenly@gmail.com eller en Yahoo-adress är inte lämplig för fältet ”Work Email”. Börja här: Steg 1 – Apple-konto (tidigare kallat Apple-ID) Du kan skapa ett Apple-konto här: Apple-konto Se till att: Ange kontoinnehavarens juridiska för- och efternamn – inte företagsnamnet. Du kommer att ange organisationens namn separat när du registrerar dig för Apple Developer Program. Använd en allmän e-postadress som flera personer i ditt företag har tillgång till. För den händelse att någon blir sjuk, är på semester eller byter befattning. Aktivera tvåfaktorsautentisering: Apple kräver detta för att registrera din organisation i Apple Developer Program.   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 skapa ett utvecklarkonto hos Apple behöver du ett D-U-N-S-nummer. D-U-N-S-numret kan beskrivas som ett internationellt organisationsnummer. Har du inget nummer? Gå till den här länken för att kontrollera eller skapa ett. Vet du inte vad ditt nummer är? Du kan också använda den här sidan för att få ditt befintliga D-U-N-S-nummer skickat till dig.   Steg 3 – Utvecklarkonto Klicka på länken och följ instruktionerna för att skapa ett konto. När du loggar in första gången kan Apple först ställa några frågor om dina utvecklarintressen. Om du är osäker kan du exempelvis välja iOS och iPadOS som plattformar och Tidskrifter eller Nyheter som apptyp, om dessa alternativ erbjuds. För ämnen passar exempelvis Apputveckling. Frågan om länder handlar om var du vill delta i utvecklaraktiviteter, vanligtvis ditt hemland. Fortsätt sedan med registreringen för Apple Developer Program och välj ”Företag/Organisation” som enhetstyp. Kontrollera vem de efterfrågade uppgifterna gäller: Under registreringen frågar Apple efter uppgifter om både kontoinnehavaren och företaget. Vid personuppgifter anger du kontoinnehavarens uppgifter – fullständigt namn och, om Apple uttryckligen frågar efter bostadsadressen, den privata adressen. Vid företagsuppgifter ska du tänka på följande: Företagsnamn, företagsadress och D-U-N-S-nummer: Använd uppgifterna från D-U-N-S-registret. Ange organisationens registrerade företagsnamn, inte publikationens varumärke. Företagets webbplats: Ange en fungerande, offentligt tillgänglig webbplats som tydligt kan kopplas till ditt företag. Se anvisningarna under ”Innan du börjar”. E-postadress för arbetet: Använd en adress på företagets domän som du har tillgång till, till exempel hello@prenly.com. En Gmail- eller Yahoo-adress är inte lämplig här. Efter att du har skickat in din ansökan: Kontrollera din e-post, inklusive skräppost, för att se om Apple har skickat verifieringsförfrågningar. Om Apple begär ytterligare dokument, följ vår guide. När Apple har godkänt ansökan följer du instruktionerna i e-postmeddelandet för att godkänna medlemsavtalet och slutföra betalningen. Vänta på Apples bekräftelse av medlemskapet innan du går vidare till steg 4. Att skicka in ansökan innebär inte i sig att registreringen är klar. Observera: Ideella organisationer kan vara berättigade till avgiftsbefrielseErkända ideella organisationer kan vara berättigade till befrielse från Apples årliga medlemsavgift på 99 US-dollar om de inte säljer digitala varor eller tjänster via sina appar och inte har något aktivt avtal om betalda appar. Begär befrielsen under registreringen, innan du betalar – Apple återbetalar inte redan betalda avgifter. Se Apples krav för avgiftsbefrielse. Har du fastnat eller är du osäker på vad Apple efterfrågar? Kontakta Prenlys support och bifoga en skärmdump av meddelandet eller steget där du har fastnat, så att vi kan hjälpa dig vidare.   Steg 4 – Bjud in Prenly till utvecklarkontot, efter att Apple har godkänt ansökan som gjordes i steg 3. Bjud in Prenly: Logga in Under ”Programresurser” och ”App Store Connect” väljer du ”Användare och åtkomst”. Klicka på plustecknet i menyn för att lägga till en ny användare. Lägg till Prenlys utvecklarkonto som ”Admin”. Namnet kan du välja själv, men e-postadressen måste vara ios-app-manager@textalkmedia.se Se till att alternativen under Utvecklare/Ytterligare resurser är markerade. Spara genom att klicka på "Bjud in". Låt oss skicka uppdateringar till dig: Under ”Användare och åtkomst” klickar du på ”Integration” och väljer ”Begär åtkomst”. Läs igenom begäran, markera bekräftningsrutan och klicka på ”Skicka”.   Steg 5 – Verifiera handlarens uppgifter Alla konton måste verifiera sina handlaruppgifter 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 skapar kontot måste du ha ett Google-konto och ett D-U-N-S-nummer.   Innan du börjar Vem ska skapa kontot? Välj en person i din organisation som ska ansvara för Google Play Console-kontot. Det Google-konto som används vid registreringen blir kontoägaren. Ha ett foto-ID till hands: Detta måste tillhöra någon som är behörig att företräda din organisation – inte nödvändigtvis den person som skapar kontot. Det kan vara en ägare, en styrelseledamot eller en anställd som har fått den behörigheten. Om någon annan ska tillhandahålla ID-handlingen, se till att den personen hjälper till med verifieringen. Se till att du har tillgång till din e-post och telefon: Google skickar verifieringskoder som du måste ange när du skapar kontot. Steg 1 – Google-konto Det Google-konto som används vid registreringen blir ägare till ditt Play Console-utvecklarkonto. Innan du fortsätter ska du se till att du är inloggad på det Google-konto som din organisation avser att använda. Om du ännu inte har ett Google-konto ska du följa den här guiden innan du fortsätter.   Steg 2 – DUNS-nummer Om du redan har fått ditt D-U-N-S-nummer går du direkt till steg 3. För att skapa ett utvecklarkonto hos Google behöver du ett D-U-N-S-nummer. D-U-N-S-numret kan beskrivas som ett internationellt organisationsnummer. Om du inte känner till din organisations D-U-N-S-nummer, besök dunsnumberlookup.dnb.com för att få det skickat till dig.   Steg 3 – Utvecklarkonto i Play Console Se till att du är inloggad på rätt konto, eller välj Byt konto för att välja rätt kontoägare. Börja processen för att skapa ditt nya utvecklarkonto här. Logga in med rätt Google-konto. Välj vid behov ”Byt konto”. Godkänn Googles distributionsavtal. Google tar ut en engångsavgift på 25 dollar. Google accepterar flera betalningsalternativ; välj det som passar dig bäst och betala registreringsavgiften.   Välj ”Organisation” som kontotyp. Om du väljer ”Personligt” krävs ytterligare steg för att konvertera kontot senare. Vilken betalningsprofil ska du välja? En Google-betalningsprofil lagrar det juridiska namnet och den adress som Google använder för att verifiera din organisation – även om din app är gratis. Skapa en betalningsprofil för företag med din organisations registrerade namn och adress. Om Google erbjuder en befintlig profil ska du endast välja den om den tillhör samma organisation och uppgifterna är korrekta. I annat fall ska du skapa en ny profil. Använd inte en anställds personliga betalningsprofil. Se till att företagsnamnet och adressen stämmer överens med din organisations uppgifter hos Dun & Bradstreet. Tips: Utvecklarnamnet visas offentligt på Google Play och kan vara din organisations namn eller varumärket för din publikation. Detta skiljer sig från det juridiska företagsnamnet som används för verifiering.   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 användarens e-postadress och lämna fältet "Utgångsdatum" tomt. I avsnittet Behörigheter väljer du Kontobehörigheter och sedan Admin Välj "Bjud in användare" för att bjuda in Prenly Tips: Om knappen ”Bjud in användare” är grå betyder det att du har missat ett steg.   Steg 5 – Slutför kontoverifieringen Slutför verifieringsuppgifterna som visas i Play Console, inklusive din organisations D-U-N-S-nummer, identitet, webbplats och kontaktuppgifter. Förbered rätt dokument Google kan begära ett officiellt företagsregistreringsdokument samt den behöriga representantens foto-ID. Kontrollera vilka dokument som Google godtar för ditt land innan du laddar upp dem. Se till att dokumenten stämmer överens med de uppgifter som angetts för verifieringen. För foto-ID ska du använda ett tydligt färgfoto av ett giltigt dokument – inte en fotokopia. Om Google begär ytterligare dokument, följ vår guide: Hantera begäran om ytterligare dokument för utvecklarkonton. Verifiera din webbplats Verifieringen är inte klar bara genom att ange webbplatsadressen. Google använder Google Search Console, sin tjänst för webbplatshantering, för att bekräfta din organisations åtkomst till webbplatsen. Fråga ditt IT-team eller webbbyrån vem som hanterar webbplatsen i Search Console. Den personen kan behöva godkänna verifieringsbegäran som du skickar från Play Console. Om samma Google-konto äger webbplatsen i Search Console godkänns begäran automatiskt. Följ vår guide för att verifiera din organisations webbplats. Verifiera din e-postadress och ditt telefonnummer Utför de verifieringsuppgifter för e-post och telefonnummer som visas i Play Console. Använd kontaktuppgifter som du har tillgång till för att ta emot verifieringskoder. För organisationskonton kräver Google att identitets- och webbplatsverifieringen är slutförd innan verifieringen av kontaktnumret kan fortsätta. Ditt utvecklarkonto aktiveras inte fullt ut förrän alla nödvändiga verifieringssteg har slutförts. Har du fastnat eller är du osäker på vad Google efterfrågar? Kontakta Prenlys support och bifoga en skärmdump av meddelandet eller steget där du har fastnat, så att vi kan hjälpa dig vidare.   Rekommendation När du har skapat ditt utvecklarkonto i Play Console rekommenderar vi att du sparar eller skriver ut e-postmeddelandet med betalningsbekräftelse från Google. E-postmeddelandet innehåller viktig information som kan behövas om du någonsin behöver överföra din app till ett annat Play Console-konto, bland annat: Transaktions-ID Den använda betalningsmetoden Köpdatum 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