Guide till Rivya-inloggning och kontoåtkomst

Använd den här guiden till inloggning och kontoåtkomst när du behöver förstå inloggningsalternativ, saknade inloggningsknappar, lösenordsåterställning, skyddade sidor eller kontosäkerhetsbeteende i Rivya.

Rivyas autentiseringssystem är enkelt från ditt perspektiv, men några detaljer spelar roll eftersom inte varje inloggningsalternativ visas i varje driftsättning.

Nuvarande inloggningsmetoder

Rivya stöder för närvarande dessa inloggningsvägar:

• e-post och lösenord
• Google
• GitHub
• Discord
• valfri Magic Link

Det viktiga ordet är "valfri". Magic Link är funktionsstyrt, och sociala knappar beror också på om den aktuella driftsättningen faktiskt är konfigurerad för dessa leverantörer.

Varför en inloggningsknapp kan saknas

Det här är en av de vanligaste källorna till förvirring.

En social inloggningsknapp kan saknas av två separata skäl:

• funktionen är inaktiverad i den aktuella webbplatskonfigurationen
• leverantörs-credentials är inte konfigurerade för den aktuella driftsättningen

Därför kan en miljö visa Google och GitHub medan en annan bara visar e-postinloggning.

Magic Link följer samma allmänna regel. Om det inte är aktiverat för den aktuella driftsättningen ska inloggningssidan inte tolkas som "trasig". Det är helt enkelt inte aktivt där.

Inloggnings-, registrerings- och återställningsvägar

De aktuella auth-vägarna är:

• /auth/login
• /auth/register
• /auth/forgot-password
• /auth/reset-password
• /auth/magic-link-status
• /auth/error

Dessa vägar är supportsidor, inte kampanjsidor. De finns för att användare ska kunna starta, återställa eller förstå kontoåtkomst utan att gissa var flödet finns.

När du ska använda lösenordsåterställning jämfört med Magic Link

Använd lösenordsåterställning när:

• du redan förlitar dig på e-post/lösenord
• du har glömt lösenordet
• du registrerade dig socialt men nu vill lägga till ett lösenord och kontot har en e-postadress kopplad

Använd Magic Link när:

• den aktuella driftsättningen exponerar det
• du vill ha en kortlivad e-postinloggning i stället för att skriva ett lösenord

Om en Magic Link är utgången eller ogiltig skickar produktvägarna den statusen via /auth/magic-link-status i stället för att misslyckas tyst.

Vad som händer efter inloggning

Nuvarande standarddestination efter inloggning är /dashboard.

Det är avsiktligt. Dashboard är den enklaste platsen att plocka upp arbetet igen efter inloggning.

Därifrån kan du gå vidare till:

• studios
• historik
• notiser
• fakturerings- och creditinställningar

Skyddade sidor jämfört med offentliga sidor

Rivya håller en verklig uppdelning mellan offentlig upptäckt och autentiserat arbete.

Offentliga sidor låter dig:

• bläddra bland modeller
• jämföra verktyg
• granska prissättning
• starta från offentliga quick-start-block på startsidor

Skyddade sidor är de där sparat kontotillstånd spelar roll, till exempel:

• /dashboard
• /studio/*
• /history/*
• /notifications
• /settings/*
• /payment

Den skyddade layouten validerar sessionen på servern, inte bara i webbläsaren. Om du inte är inloggad förväntas dessa vägar därför skicka dig tillbaka genom inloggningsflödet.

Varför säkerhetsinställningar ser olika ut för olika användare

/settings/security är kopplad till de verkliga auth-providers som finns på kontot.

Det betyder att sidan kan bete sig olika beroende på hur du ursprungligen loggade in:

• användare med e-post/lösenord kan ändra lösenord direkt
• social-only-användare med en e-postadress kan vägledas till forgot-password-flödet för att lägga till ett lösenord
• behöriga användare kan nå kontoradering där

Det är normalt produktbeteende, inte en UI-missmatchning.

En praktisk regel för åtkomstproblem

Om frågan är:

Börja med auth-vägarna.

Om frågan är:

Börja med /settings/security.

Om frågan är:

Behandla det som en åtkomstgräns, inte som en innehållsbugg. Du är troligen på en skyddad väg.

Läs vidare

• Kom igång
• Kontoinställningar i Rivya
• Felsökning i Rivya

Åtkomstchecklista

När inloggning, kontoidentitet eller behörigheter blockerar ett arbetsflöde, kontrollera:

• Bekräfta vilken inloggningsmetod driftsättningen faktiskt exponerar.
• Kontrollera om målet är offentlig browsing eller sparat, debiterbart arbete.
• Logga in före uppladdningar, sparad historik, betalningshantering eller Studio-fortsättning.
• För lösenordsåterställning, följ de dedikerade auth-sidorna i stället för att upprepa inloggningsförsök.
• Behåll return paths intakta så att du landar tillbaka på uppgiften du startade.

Kontrollera igen innan åtkomst återställs

Kontrollera igen om det kan finnas flera konton, en inaktiverad leverantör, en gammal returlänk, en utgången återställningslänk eller en offentlig sida som ser ut som att den borde köras utan inloggning.