Beställ återställning med den etablerade autentiseringen i Lovable Cloud. Godkänn sedan kedjan först när testkontot kan logga in med det nya lösenordet, det gamla nekas och felaktiga länkar ger en begriplig väg till ett nytt försök. Proven här är föreslagna kontroller, inte utförda tester.
1. Kontrollera vilket konto du återställer
Guiden gäller slutanvändaren i en app med Lovable Cloud och e-post/lösenord. Den gäller inte ditt eget konto hos Lovable, en Google-inloggning eller en app kopplad till ett separat Supabase-projekt. Enligt Lovables dokumentation om e-postinloggning genererar Lovable registrering, inloggning och lösenordsåterställning när du beställer e-postinloggning i Cloud. Egna Supabase-projekt hanterar inställningarna i Supabase.
Be Lovable bekräfta vilken backend projektet använder innan du ändrar något. Har du en app där användaren klickar på Google-knappen, börja med guiden om Google-inloggning. Har du ännu inte bestämt hur konton och data ska hänga ihop, läs data och inloggning. I den här övningen väljer du ett testkonto som faktiskt har ett lösenord i appen.
2. Beställ flödet med ett tydligt facit
Kopiera beställningen nedan och byt ut sidan Mina anteckningar mot din egen skyddade sida. Texten är en redaktionell beställning med egna acceptanskrav. Behåll kontrollerna även om Lovable svarar att funktionen redan finns; det svaret ersätter inte ett prov i webbläsaren.
Bekräfta att appen använder Lovable Cloud. Använd den etablerade e-post/lösenordsautentiseringen, utan egen lagring av lösenord eller egna återställningstoken. Lägg till Glömt lösenord på inloggningssidan. Användaren ska kunna begära ett återställningsmejl, öppna länken och välja och bekräfta ett nytt lösenord på en tydlig återställningssida. Visa lyckat resultat först när ändringen sparats. Visa begripliga fel vid ogiltig eller använd länk och erbjud att begära en ny. Kontrollera den publicerade appens domän, Site URL och tillåtna returadresser. Mina anteckningar ska fortsatt kräva inloggning. Jag ska kunna logga ut och logga in med det nya lösenordet, medan det gamla nekas. Förklara vilka inställningar och sidor du ändrat och hur jag provar flödet.
Begär samma synliga resultat som du tänker mäta: mejl, återställningssida, sparat lösenord och ny inloggning. Att bara beställa ”en snygg reset-sida” lämnar mejlet och sparandet oprövade. Be byggaren visa ändringarna och använd därefter stegen nedan som din egen checklista.
3. Förbered testkonto och anteckningar
Använd en separat e-postadress vars inkorg du själv kan läsa. Skapa testkontot i appen, slutför eventuell bekräftelse och logga in en gång med det första lösenordet. Lägg in anteckningen RESET-TEST på den skyddade sidan. Då kan du senare se att du kommit tillbaka till samma konto, i stället för ett tomt nyregistrerat konto.
Logga ut och öppna appens publicerade adress i ett privat fönster. Skriv ned domän, datum och vilka prov du gör. Använd beteckningarna ”första lösenordet” och ”nya lösenordet” i protokollet; klistra inte in lösenord eller hela återställningslänkar i projektchatten. Ett användbart protokoll har fyra kolumner: prov, förväntat, faktiskt resultat och godkänt eller underkänt.
4. Följ mejlet hela vägen till en ny inloggning
Prov A: begäran och mejl. Klicka på Glömt lösenord, skriv testkontots adress och skicka. Facit enligt beställningen: appen visar en begriplig bekräftelse och inkorgen får ett återställningsmejl för rätt app. Ett meddelande på sidan bevisar inte att mejlet kom fram. Spara tidpunkten och kontrollera att du öppnar det mejl som hör till just detta försök.
Prov B: länken och sparandet. Öppna länken. Facit: du kommer till en sida där du kan ange och bekräfta ett nytt lösenord, inte bara till startsidan. Prova först två olika värden i fälten; beställningens facit är ett tydligt fel och ingen lyckad ändring. Ange sedan samma nya lösenord i båda fälten och spara. Dokumentationen beskriver själva kedjan som begäran, återställningsmejl och val av nytt lösenord; fältens utformning och felen är dina acceptanskrav.
Prov C: en ny session. Logga ut om appen har loggat in dig efter sparandet. Stäng det privata fönstret och öppna en ny privat session. Logga in med det nya lösenordet. Facit: du kommer in och hittar RESET-TEST. Logga ut igen och försök med det första lösenordet. Facit: det nekas. Den separata sessionen gör provet tydligare än att bara ladda om en sida där testkontot redan är inloggat.
5. Prova använda, trasiga och äldre länkar
Prov D: redan använd länk. Öppna samma återställningslänk igen efter att du sparat det nya lösenordet, i en ny privat session. Acceptanskravet är att länken inte medger ännu en lösenordsändring utan ny behörig återställning. Användaren ska få ett begripligt besked och kunna begära ett nytt mejl. Om formuläret visas ändå, kontrollera även vad som händer vid sparandet innan du bedömer resultatet.
Prov E: trasig länk. Gör en separat lokal kopia av länken och ta bort ett tecken i dess token eller motsvarande återställningsdel. Behåll originalet för jämförelse och dela ingen av adresserna. Facit enligt beställningen: inget lösenord ändras, sidan visar ett fel och vägen till en ny begäran går att hitta. En tom sida eller ett evigt laddningstillstånd underkänner användarflödet även om själva ändringen blockeras.
Prov F: äldre oanvänd länk. Begär en länk och lägg undan den. Be Lovable redovisa vilka regler som gäller för giltighet och för flera begäranden i ditt projekt, och prova därefter mot den dokumenterade regeln. De två källorna här anger ingen bestämd giltighetstid för återställningslänken. Inställningen Email OTP expiration beskrivs för lösenordslösa koder och magic links; använd den inte som facit för lösenordsåterställningen. Saknas verifierad regel skriver du ”återstår att kontrollera” i protokollet.
6. Kontrollera domän, mobil och returadress
Enligt Lovables dokumentation om autentisering finns Site URL och Redirect URLs under Auth settings → Advanced. Site URL är standardadressen efter autentisering när ingen returadress anges. Cloud uppdaterar adresser vid publicering och anslutning av egen domän, men en Site URL som du satt själv lämnas oförändrad. Kontrollera därför de faktiska värdena och länken i mejlet.
Jämför den avsedda publicerade domänen med adressen där återställningsformuläret faktiskt öppnas. Hamnar du i förhandsvisningen eller på en tidigare domän, be Lovable rätta returadressen och gör en ny begäran. Ändra inte en mottagen tokenlänk för att försöka rädda flödet. Ska appen få en egen adress hjälper guiden om egen domän dig med den delen.
Gör sedan prov A–C på en mobil: läs mejlet på telefonen, öppna länken där och kontrollera att fälten, sparaknappen och felmeddelandena går att använda med skärmtangentbordet öppet. Notera om mejlappen öppnar länken i en annan webbläsare än den du började i. Det är ett eget provfall; ett godkänt datorprov säger inget om den kombinationen.
Felsök den del där kedjan bryts
Inget mejl: jämför adressen med testkontot, kontrollera skräpposten och gör en ny begäran med antecknad tid. Lovable dokumenterar en sändningsgräns för autentiseringsmejl under Advanced i e-postinställningarna. Be byggaren kontrollera sändningen om mejlet uteblir. Ett lyckat sidmeddelande och en tom inkorg är ett underkänt slutprov, även när gränssnittet ser färdigt ut.
Fel domän: be byggaren kontrollera Site URL, tillåtna returadresser och adressen flödet begär. Ingen återställningsvy: beskriv exakt vilken sida länken öppnar och om ett fel visas. Be Lovable kontrollera att återställningslänken hanteras av rätt sida och att formuläret faktiskt sparar genom den etablerade autentiseringen. Skicka en beskrivning av utfallet, inte hemliga delar av länken.
Eget Supabase-projekt: byt till projektets Supabase-konfiguration som en separat arbetsgång. Cloud-instruktionerna ovan är inte dess inställningsväg, och dokumentationen säger att dessa projekt inte får automatiska URL-uppdateringar. Be byggaren visa rätt inställningar där innan du provar igen.
Testkontot tar sig från begäran till nytt lösenord på avsedd domän, en ny inloggning fungerar och det gamla lösenordet nekas. Använd och trasig länk hanteras enligt beställningen. Mobilprovet är godkänt och eventuell återstående regel för äldre länkar är uttryckligen noterad.
Kontrollerad 11 oktober 2026 mot Email authentication for your app och Users and authentication. Källorna stöder de uttryckligen tillskrivna produktuppgifterna. Beställningen, provkontot och acceptansproven är redaktionella rekommendationer som du måste utföra i din egen app.