Rivya AI Docs

Rivya Login and Account Access Guide

Understand Rivya login methods, email password, Google, GitHub, Discord, Magic Link, password reset, protected pages, and account security.

Last reviewed on 2026/04/28

Use this login and account access guide when you need to understand sign-in options, missing login buttons, password recovery, protected pages, or account security behavior in Rivya.

Rivya’s authentication system is straightforward from your point of view, but a few details matter because not every login option appears in every deployment.

The Current Login Methods

Rivya currently supports these sign-in paths:

  • email and password
  • Google
  • GitHub
  • Discord
  • optional Magic Link

The important word is “optional.” Magic Link is feature-gated, and the social buttons also depend on whether the current deployment is actually configured for those providers.

Why a Login Button May Be Missing

This is one of the most common points of confusion.

A social login button can be absent for two separate reasons:

  • the feature is disabled in the current site configuration
  • the provider credentials are not configured for the current deployment

That is why one environment can show Google and GitHub while another shows only email login.

Magic Link follows the same general rule. If it is not enabled for the current deployment, the login page should not be read as “broken.” It is simply not active there.

Login, Register, and Recovery Paths

The current auth paths are:

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

These paths are support pages, not promotional pages. They are there so users can start, recover, or understand account access without guessing where the flow lives.

Use password reset when:

  • you already rely on email/password access
  • you forgot the password
  • you signed up socially but now want to add a password and the account has an email attached

Use Magic Link when:

  • the current deployment exposes it
  • you want a short-lived email sign-in path instead of typing a password

If a Magic Link is expired or invalid, the product paths that state through /auth/magic-link-status instead of silently failing.

What Happens After Login

The current default post-login destination is /dashboard.

That is intentional. Dashboard is the easiest place to pick work back up after sign-in.

From there, you can move into:

  • studios
  • history
  • notifications
  • billing and credits settings

Protected Pages vs Public Pages

Rivya keeps a real split between public discovery and authenticated work.

Public pages let you:

  • browse models
  • compare tools
  • inspect pricing
  • start from public quick-start blocks on start pages

Protected pages are the ones where saved account state matters, such as:

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

The protected layout validates the session on the server, not only in the browser. So if you are not signed in, those paths are expected to send you back through the login flow.

Why Security Settings Look Different for Different Users

/settings/security is tied to the real auth providers on the account.

That means the page can behave differently depending on how you originally signed in:

  • email/password users can change password directly
  • social-only users with an email can be guided into the forgot-password flow to add a password
  • eligible users can reach account deletion there

That is normal product behavior, not a UI mismatch.

A Practical Rule for Access Problems

If the question is:

How do I get into the account?

Start with the auth paths.

If the question is:

I am already in, but I need to manage password, account security, or deletion.

Start with /settings/security.

If the question is:

Why does this page keep pushing me to login?

Treat it as an access boundary, not as a content bug. You are probably on a protected path.

Access Checklist

When sign-in, account identity, or permissions block a workflow, check:

  • Confirm which login method the deployment actually exposes.
  • Check whether the goal is public browsing or saved billable work.
  • Use sign-in before uploads, saved history, payment management, or Studio continuation.
  • For password recovery, follow the dedicated auth pages instead of repeating login attempts.
  • Keep return paths intact so you land back on the task you started.

Recheck Before Resetting Access

Recheck if there may be multiple accounts, a disabled provider, stale return link, expired reset link, or a public page that looks like it should run without sign-in.

Table of Contents