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: de zichtbare methoden hangen af van de deploymentconfiguratie en de providers die daar werkelijk zijn gekoppeld.

De huidige loginmethoden

Het huidige authenticatiecontract kan Google en een zescijferige verificatiecode per e-mail als primaire ingangen tonen wanneer e-mail-OTP voor de deployment is ingeschakeld.

Voor login met een e-mailcode:

• Rivya stuurt een zescijferige code naar het opgegeven adres

• de code verloopt na vijf minuten

• een code staat maximaal drie verificatiepogingen toe

• het aanvragen en verifiëren hangt nog steeds af van de e-mail- en beveiligingsdiensten die voor de deployment zijn geconfigureerd

Wachtwoord, Magic Link, Discord en GitHub zijn legacy of optionele toegangspaden. Ze verschijnen alleen wanneer de deployment de legacy fallback ingeschakeld houdt en de vereiste functie- of providercredentials aanwezig zijn. Ook Google vereist zijn deploymentcredentials, zelfs wanneer het onderdeel is van de primaire productconfiguratie.

Het codecontract kan dus een methode ondersteunen zonder te beloven dat elke deployment die toont.

Waarom een loginbutton kan ontbreken

Dit is een van de meest voorkomende verwarringspunten.

Een loginmethode kan om meerdere normale redenen ontbreken:

• de feature is uitgeschakeld in de huidige siteconfiguratie

• de providercredentials zijn niet geconfigureerd voor de huidige deployment

• de deployment heeft de legacy fallback uitgeschakeld

• een voor de methode vereiste e-mail- of beveiligingsafhankelijkheid is niet beschikbaar

Daarom kan de ene environment Google en login met e-mailcode tonen, terwijl een andere minder methoden aanbiedt.

Legacy wachtwoord, Magic Link, Discord en GitHub volgen dezelfde regel. Als een methode niet wordt getoond, is de loginpagina niet kapot; gebruik een methode die de deployment werkelijk aanbiedt.

Login-, registratie- en herstelpaden

De belangrijkste accounttoegangspaden zijn:

• /auth/login

• /auth/register

Legacy herstel via wachtwoord of Magic Link kan ook deze paden gebruiken:

• /auth/forgot-password

• /auth/reset-password

• /auth/magic-link-status

Authenticatiefouten gebruiken:

• /auth/error

De zescijferige e-mailcode wordt afgehandeld in het huidige authenticatieformulier en vereist geen aparte openbare herstelpagina. Deze paden zijn supportpagina's, geen promotiepagina's.

Wanneer je e-mailcode of legacy herstel gebruikt

Gebruik de zescijferige code wanneer het huidige loginformulier die aanbiedt. Vraag een nieuwe aan als de vorige is verlopen en blijf niet proberen nadat de toegestane pogingen zijn verbruikt.

Gebruik wachtwoordreset alleen wanneer:

• de deployment nog legacy wachtwoordtoegang aanbiedt

• je al op e-mail/wachtwoordtoegang vertrouwt

• je het wachtwoord bent vergeten

• de beveiligingspagina het account naar die herstelflow stuurt

Gebruik Magic Link alleen wanneer:

• de deployment deze legacy of optionele methode 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 en credentials op het account.

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

• accounts met een legacy wachtwoordcredential kunnen die direct wijzigen

• accounts zonder zo'n credential kunnen alleen naar herstel worden geleid wanneer legacy wachtwoordtoegang ingeschakeld blijft

• Google-, OTP- en legacy social-provideraccounts kunnen verschillende credentialcontrols tonen

• geschikte gebruikers kunnen daar accountverwijdering bereiken

Dat is normaal productgedrag, geen UI-mismatch.

Een praktische regel voor toegangsproblemen

Als de vraag is:

Hoe kom ik in het account?

Begin met de auth-paden.

Als de vraag is:

Ik ben al binnen, maar ik moet wachtwoord, accountbeveiliging of verwijdering beheren.

Begin met /settings/security.

Als de vraag is:

Waarom stuurt deze pagina me steeds naar login?

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.

• Gebruik voor toegang met e-mailcode de nieuwste zescijferige code binnen de geldigheid van vijf minuten.

• Controleer of het doel publiek browsen is of opgeslagen factureerbaar werk.

• Gebruik sign-in voor uploads, opgeslagen history, payment management of Studio-continuation.

• Gebruik wachtwoord- of Magic Link-herstel alleen wanneer de deployment die legacy paden aanbiedt.

• 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.