Rivya AI दस्तावेज़

Rivya Login and Account Access Guide

Rivya login methods, email password, Google, GitHub, Discord, Magic Link, password reset, protected pages और account security समझें.

अंतिम समीक्षा 2026/04/28 को

जब आपको Rivya में sign-in options, missing login buttons, password recovery, protected pages या account security behavior समझना हो, तब यह login और account access guide इस्तेमाल करें।

आपके point of view से Rivya का authentication system straightforward है, लेकिन कुछ details मायने रखती हैं क्योंकि हर login option हर deployment में दिखाई नहीं देता।

Current Login Methods

Rivya currently ये sign-in paths support करता है:

  • email और password
  • Google
  • GitHub
  • Discord
  • optional Magic Link

महत्वपूर्ण शब्द “optional” है। Magic Link feature-gated है, और social buttons भी इस पर depend करते हैं कि current deployment सच में उन providers के लिए configured है या नहीं।

Login Button गायब क्यों हो सकता है

यह confusion के सबसे common points में से एक है।

Social login button दो अलग वजहों से absent हो सकता है:

  • current site configuration में feature disabled है
  • current deployment के लिए provider credentials configured नहीं हैं

इसीलिए एक environment Google और GitHub दिखा सकता है, जबकि दूसरा केवल email login दिखाता है।

Magic Link भी वही general rule follow करता है। अगर current deployment के लिए यह enabled नहीं है, तो login page को “broken” नहीं पढ़ना चाहिए। वह बस वहां active नहीं है।

Login, Register और Recovery Paths

Current auth paths हैं:

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

ये paths support pages हैं, promotional pages नहीं। ये इसलिए हैं ताकि users account access शुरू, recover या समझ सकें, बिना यह guess किए कि flow कहां रहता है।

Password reset इस्तेमाल करें जब:

  • आप पहले से email/password access पर rely करते हैं
  • आप password भूल गए हैं
  • आपने socially sign up किया था, लेकिन अब password add करना चाहते हैं और account से email attached है

Magic Link इस्तेमाल करें जब:

  • current deployment इसे expose करता है
  • आप password type करने के बजाय short-lived email sign-in path चाहते हैं

अगर Magic Link expired या invalid है, तो product paths उस state को silently fail करने के बजाय /auth/magic-link-status के माध्यम से बताते हैं।

Login के बाद क्या होता है

Current default post-login destination /dashboard है।

यह intentional है। Dashboard sign-in के बाद काम फिर से शुरू करने की सबसे आसान जगह है।

वहां से आप इन जगहों पर जा सकते हैं:

  • studios
  • history
  • notifications
  • billing और credits settings

Protected Pages बनाम Public Pages

Rivya public discovery और authenticated work के बीच real split रखता है।

Public pages आपको ये करने देती हैं:

  • models browse करना
  • tools compare करना
  • pricing inspect करना
  • start pages पर public quick-start blocks से शुरुआत करना

Protected pages वे हैं जहां saved account state मायने रखती है, जैसे:

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

Protected layout session को server पर validate करता है, केवल browser में नहीं। इसलिए अगर आप signed in नहीं हैं, तो उन paths का आपको login flow में वापस भेजना expected है।

अलग Users के लिए Security Settings अलग क्यों दिखती हैं

/settings/security account पर real auth providers से जुड़ा है।

इसका मतलब है कि page आपके original sign-in तरीके के आधार पर अलग behave कर सकता है:

  • email/password users सीधे password बदल सकते हैं
  • email वाले social-only users को password add करने के लिए forgot-password flow में guide किया जा सकता है
  • eligible users वहां account deletion तक पहुंच सकते हैं

यह normal product behavior है, UI mismatch नहीं।

Access Problems के लिए Practical Rule

अगर सवाल है:

Account में कैसे enter करूं?

Auth paths से शुरू करें।

अगर सवाल है:

मैं पहले से अंदर हूं, लेकिन password, account security या deletion manage करना है।

/settings/security से शुरू करें।

अगर सवाल है:

यह page मुझे बार-बार login पर क्यों भेजता है?

इसे content bug नहीं, access boundary की तरह treat करें। आप शायद protected path पर हैं।

आगे पढ़ें

Access Checklist

जब sign-in, account identity या permissions कोई workflow block करें, check करें:

  • Confirm करें कि deployment असल में कौन-सा login method expose करता है।
  • Check करें कि goal public browsing है या saved billable work।
  • Uploads, saved history, payment management या Studio continuation से पहले sign-in इस्तेमाल करें।
  • Password recovery के लिए login attempts repeat करने के बजाय dedicated auth pages follow करें।
  • Return paths intact रखें ताकि आप शुरू किए गए task पर वापस land करें।

Access reset करने से पहले दोबारा check करें

अगर multiple accounts, disabled provider, stale return link, expired reset link, या ऐसी public page हो सकती है जो sign-in के बिना run होनी चाहिए जैसी दिखती है, तो दोबारा check करें।

विषय-सूची