Guide til Rivya-innlogging og kontotilgang

Bruk denne guiden for innlogging og kontotilgang når du trenger å forstå innloggingsvalg, manglende innloggingsknapper, passordgjenoppretting, beskyttede sider eller kontosikkerhetsatferd i Rivya.

Rivyas autentiseringssystem er enkelt fra ditt ståsted, men noen detaljer betyr noe fordi ikke alle innloggingsvalg vises i hver deployment.

Nåværende innloggingsmetoder

Rivya støtter for øyeblikket disse innloggingsveiene:

• e-post og passord
• Google
• GitHub
• Discord
• valgfri Magic Link

Det viktige ordet er "valgfri." Magic Link er feature-gated, og sosiale knapper avhenger også av om den nåværende deploymenten faktisk er konfigurert for disse providerne.

Hvorfor en innloggingsknapp kan mangle

Dette er et av de vanligste forvirringspunktene.

En sosial innloggingsknapp kan mangle av to separate grunner:

• funksjonen er deaktivert i den nåværende nettstedskonfigurasjonen
• provider-legitimasjonen er ikke konfigurert for den nåværende deploymenten

Derfor kan ett miljø vise Google og GitHub mens et annet bare viser e-postinnlogging.

Magic Link følger samme generelle regel. Hvis den ikke er aktivert for den nåværende deploymenten, bør innloggingssiden ikke leses som "ødelagt." Den er ganske enkelt ikke aktiv der.

Innlogging, registrering og gjenopprettingsruter

De nåværende auth-rutene er:

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

Disse rutene er støttesider, ikke kampanjesider. De finnes slik at brukere kan starte, gjenopprette eller forstå kontotilgang uten å gjette hvor flyten ligger.

Når du bør bruke passordtilbakestilling kontra Magic Link

Bruk passordtilbakestilling når:

• du allerede bruker e-post/passord-tilgang
• du har glemt passordet
• du registrerte deg sosialt, men nå vil legge til et passord og kontoen har en e-post tilknyttet

Bruk Magic Link når:

• den nåværende deploymenten eksponerer den
• du vil ha en kortvarig e-postbasert innloggingsvei i stedet for å skrive passord

Hvis en Magic Link er utløpt eller ugyldig, sender produktet den tilstanden gjennom /auth/magic-link-status i stedet for å feile stille.

Hva som skjer etter innlogging

Den nåværende standarddestinasjonen etter innlogging er /dashboard.

Det er med vilje. Dashboard er det enkleste stedet å ta opp igjen arbeidet etter innlogging.

Derfra kan du gå videre til:

• studios
• historikk
• varsler
• fakturerings- og credit-innstillinger

Beskyttede sider kontra offentlige sider

Rivya holder et reelt skille mellom offentlig oppdagelse og autentisert arbeid.

Offentlige sider lar deg:

• bla gjennom modeller
• sammenligne verktøy
• se priser
• starte fra offentlige hurtigstartblokker på startsider

Beskyttede sider er de der lagret kontotilstand betyr noe, for eksempel:

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

Den beskyttede layouten validerer økten på serveren, ikke bare i nettleseren. Hvis du ikke er logget inn, er det derfor forventet at disse rutene sender deg tilbake gjennom innloggingsflyten.

Hvorfor sikkerhetsinnstillinger ser ulike ut for ulike brukere

/settings/security er knyttet til de reelle auth-providerne på kontoen.

Det betyr at siden kan oppføre seg ulikt avhengig av hvordan du opprinnelig logget inn:

• e-post/passord-brukere kan endre passord direkte
• social-only-brukere med e-post kan veiledes inn i forgot-password-flyten for å legge til et passord
• kvalifiserte brukere kan nå kontosletting der

Dette er normal produktatferd, ikke et UI-avvik.

En praktisk regel for tilgangsproblemer

Hvis spørsmålet er:

Start med auth-rutene.

Hvis spørsmålet er:

Start med /settings/security.

Hvis spørsmålet er:

Behandle det som en tilgangsgrense, ikke som en innholdsfeil. Du er sannsynligvis på en beskyttet rute.

Les videre

• Kom i gang
• Kontoinnstillinger i Rivya
• Feilsøking i Rivya

Tilgangssjekkliste

Når innlogging, kontoidentitet eller tillatelser blokkerer en arbeidsflyt, sjekk:

• Bekreft hvilken innloggingsmetode deploymenten faktisk eksponerer.
• Sjekk om målet er offentlig browsing eller lagret fakturerbart arbeid.
• Bruk innlogging før opplastinger, lagret historikk, betalingsadministrasjon eller Studio-fortsettelse.
• For passordgjenoppretting, følg de dedikerte auth-sidene i stedet for å gjenta innloggingsforsøk.
• Behold return paths intakte slik at du lander tilbake på oppgaven du startet.

Sjekk på nytt før tilgang tilbakestilles

Sjekk på nytt hvis det kan finnes flere kontoer, en deaktivert provider, en foreldet return-lenke, en utløpt reset-lenke eller en offentlig side som ser ut som den burde kjøre uten innlogging.