Rivya login- en accounttoegangsgids

Gebruik deze gids voor login en accounttoegang wanneer je sign-in opties, ontbrekende loginbuttons, wachtwoordherstel, beschermde pagina's of accountbeveiligingsgedrag in Rivya wilt begrijpen.

Rivya-authenticatie is vanuit jouw perspectief eenvoudig, maar een paar details zijn belangrijk omdat niet elke loginoptie in elke deployment verschijnt.

De huidige loginmethoden

Rivya ondersteunt momenteel deze sign-in paden:

• e-mail en wachtwoord
• Google
• GitHub
• Discord
• optionele Magic Link

Het belangrijke woord is "optioneel." Magic Link is feature-gated, en de social buttons hangen ook af van of de huidige deployment echt voor die providers is geconfigureerd.

Waarom een loginbutton kan ontbreken

Dit is een van de meest voorkomende verwarringspunten.

Een social loginbutton kan om twee aparte redenen ontbreken:

• de feature is uitgeschakeld in de huidige siteconfiguratie
• de providercredentials zijn niet geconfigureerd voor de huidige deployment

Daarom kan de ene environment Google en GitHub tonen terwijl een andere alleen e-maillogin toont.

Magic Link volgt dezelfde algemene regel. Als die niet is ingeschakeld voor de huidige deployment, moet je de loginpagina niet als "kapot" lezen. De optie is daar gewoon niet actief.

Login-, registratie- en herstelpaden

De huidige auth-paden zijn:

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

Deze paden zijn supportpagina's, geen promotiepagina's. Ze bestaan zodat gebruikers accounttoegang kunnen starten, herstellen of begrijpen zonder te raden waar de flow zit.

Wanneer je wachtwoordreset of Magic Link gebruikt

Gebruik wachtwoordreset wanneer:

• je al op e-mail/wachtwoordtoegang vertrouwt
• je het wachtwoord bent vergeten
• je je sociaal hebt aangemeld maar nu een wachtwoord wilt toevoegen en het account een e-mailadres heeft

Gebruik Magic Link wanneer:

• de huidige deployment die optie toont
• je een kortlevend e-mail sign-in pad wilt in plaats van een wachtwoord te typen

Als een Magic Link verlopen of ongeldig is, dragen de productpaden die status over via /auth/magic-link-status in plaats van stil te falen.

Wat er na login gebeurt

De huidige standaardbestemming na login is /dashboard.

Dat is bewust. Dashboard is de makkelijkste plek om werk na sign-in weer op te pakken.

Van daaruit kun je doorgaan naar:

• studios
• history
• meldingen
• billing- en creditsinstellingen

Beschermde pagina's versus publieke pagina's

Rivya houdt een echte scheiding tussen publieke discovery en geauthenticeerd werk.

Publieke pagina's laten je:

• modellen bekijken
• tools vergelijken
• pricing inspecteren
• starten vanuit publieke quick-start blokken op startpagina's

Beschermde pagina's zijn pagina's waar opgeslagen accountstatus telt, zoals:

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

De beschermde layout valideert de sessie op de server, niet alleen in de browser. Als je niet bent ingelogd, horen die paden je dus terug door de loginflow te sturen.

Waarom beveiligingsinstellingen per gebruiker verschillen

/settings/security is gekoppeld aan de echte authproviders op het account.

Dat betekent dat de pagina anders kan werken afhankelijk van hoe je oorspronkelijk bent ingelogd:

• e-mail/wachtwoordgebruikers kunnen direct hun wachtwoord wijzigen
• social-only gebruikers met een e-mailadres kunnen naar de forgot-password flow worden geleid om een wachtwoord toe te voegen
• geschikte gebruikers kunnen daar accountverwijdering bereiken

Dat is normaal productgedrag, geen UI-mismatch.

Een praktische regel voor toegangsproblemen

Als de vraag is:

Begin met de auth-paden.

Als de vraag is:

Begin met /settings/security.

Als de vraag is:

Behandel dat als een toegangsgrens, niet als een contentbug. Je zit waarschijnlijk op een beschermd pad.

Lees hierna

• Aan de slag
• Accountinstellingen in Rivya
• Probleemoplossing in Rivya

Toegangschecklist

Wanneer sign-in, accountidentiteit of permissions een workflow blokkeren, controleer je:

• Bevestig welke loginmethode de deployment echt toont.
• Controleer of het doel publiek browsen is of opgeslagen factureerbaar werk.
• Gebruik sign-in voor uploads, opgeslagen history, payment management of Studio-continuation.
• Volg voor wachtwoordherstel de specifieke authpagina's in plaats van loginpogingen te herhalen.
• Houd return paths intact zodat je terugkomt bij de taak waarmee je begon.

Opnieuw controleren voordat je toegang reset

Controleer opnieuw als er meerdere accounts, een uitgeschakelde provider, een oude return link, verlopen reset link of een publieke pagina kan zijn die lijkt alsof hij zonder sign-in moet werken.