Rivya 로그인 및 계정 접근 가이드

Rivya에서 sign-in options, missing login buttons, password recovery, protected pages, account security behavior를 이해해야 할 때 이 로그인 및 계정 접근 가이드를 사용하세요.

사용자 입장에서 Rivya의 authentication system은 단순하지만, 모든 login option이 모든 deployment에 나타나는 것은 아니므로 몇 가지 세부 사항이 중요합니다.

현재 Login Methods

Rivya는 현재 다음 sign-in paths를 지원합니다.

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

중요한 단어는 “optional”입니다. Magic Link는 feature-gated이며, social buttons도 현재 deployment가 해당 providers에 맞게 실제로 configured되어 있는지에 따라 달라집니다.

Login Button이 보이지 않을 수 있는 이유

가장 흔히 혼동되는 지점입니다.

social login button이 없을 수 있는 이유는 두 가지입니다.

• 현재 site configuration에서 feature가 disabled됨
• 현재 deployment에 provider credentials가 configured되어 있지 않음

그래서 어떤 environment에서는 Google과 GitHub가 보이고, 다른 environment에서는 email login만 보일 수 있습니다.

Magic Link도 같은 일반 규칙을 따릅니다. 현재 deployment에서 enabled되어 있지 않다면 login page가 “broken”이라고 읽어서는 안 됩니다. 단지 그곳에서 active가 아닐 뿐입니다.

Login, Register, Recovery Paths

현재 auth paths는 다음과 같습니다.

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

이 paths는 promotional pages가 아니라 support pages입니다. 사용자가 flow가 어디에 있는지 추측하지 않고 account access를 시작, 복구, 이해할 수 있도록 존재합니다.

Password Reset과 Magic Link를 쓰는 때

다음의 경우 password reset을 사용하세요.

• 이미 email/password access에 의존하고 있음
• password를 잊음
• social로 가입했지만 이제 password를 추가하고 싶고 account에 email이 연결되어 있음

다음의 경우 Magic Link를 사용하세요.

• 현재 deployment가 그것을 노출함
• password를 입력하는 대신 short-lived email sign-in path를 원함

Magic Link가 expired 또는 invalid라면 product paths는 조용히 실패하지 않고 /auth/magic-link-status를 통해 해당 state를 표시합니다.

Login 후 이동 위치

현재 기본 post-login destination은 /dashboard입니다.

의도된 동작입니다. Dashboard는 sign-in 후 작업을 다시 이어가기 가장 쉬운 곳입니다.

여기에서 다음으로 이동할 수 있습니다.

• studios
• history
• notifications
• billing and credits settings

Protected Pages와 Public Pages

Rivya는 public discovery와 authenticated work를 실제로 분리합니다.

Public pages에서 할 수 있는 일:

• models 둘러보기
• tools 비교
• pricing 확인
• start pages의 public quick-start blocks에서 시작

Protected pages는 saved account state가 중요한 곳입니다. 예:

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

protected layout은 browser에서만이 아니라 server에서 session을 검증합니다. 따라서 signed in 상태가 아니면 이런 paths가 login flow로 돌려보내는 것이 정상입니다.

사용자마다 Security Settings가 달라 보이는 이유

/settings/security는 account의 실제 auth providers에 묶여 있습니다.

즉, 처음 sign in한 방식에 따라 page가 다르게 동작할 수 있습니다.

• email/password 사용자는 password를 직접 변경할 수 있습니다.
• email이 있는 social-only 사용자는 password를 추가하도록 forgot-password flow로 안내될 수 있습니다.
• 조건을 충족하는 사용자는 account deletion에 접근할 수 있습니다.

이는 UI mismatch가 아니라 정상적인 product behavior입니다.

Access Problems를 다루는 실용 규칙

질문이 다음이라면:

auth paths에서 시작하세요.

질문이 다음이라면:

/settings/security에서 시작하세요.

질문이 다음이라면:

content bug가 아니라 access boundary로 다루세요. 아마 protected path에 있을 가능성이 높습니다.

다음에 읽을 문서

• 시작하기
• Rivya의 계정 설정
• Rivya의 Troubleshooting

Access Checklist

sign-in, account identity, permissions가 workflow를 막을 때 확인하세요.

• deployment가 실제로 어떤 login method를 노출하는지 확인하세요.
• 목표가 public browsing인지 saved billable work인지 확인하세요.
• uploads, saved history, payment management, Studio continuation 전에 sign-in을 사용하세요.
• password recovery는 login attempts를 반복하지 말고 dedicated auth pages를 따르세요.
• return paths를 유지해 로그인 후 시작한 task로 돌아오게 하세요.

Access Reset 전 재확인

multiple accounts, disabled provider, stale return link, expired reset link, 또는 sign-in 없이 실행될 것처럼 보이는 public page가 있을 수 있다면 먼저 다시 확인하세요.