Authentication

// 4. OneloAuthView always opens the centrally-hosted sign-in page —
//    on every plan. Email / password stays inside the embedded
//    WKWebView. Social providers (Google, GitHub, Apple) are handed
//    off to ASWebAuthenticationSession automatically — required
//    by Apple App Store Review and gives buyers their cached
//    SSO session in Safari, so no re-login + 2FA every time. Branding
//    (colors, logo, copy) is configured in the Onelo dashboard.

// 5. Access the current user anywhere in your app
struct ContentView: View {
    @EnvironmentObject var auth: OneloAuth

    var body: some View {
        VStack {
            if let user = auth.currentSession?.user {
                Text("Hello, \(user.email ?? "user")")
                Button("Sign out") {
                    Task { try? await auth.signOut() }
                }
            }
        }
    }
}

// ── Automatic remote-logout ─────────────────────────────────
// You don't need to write any code for this — OneloAuthView observes
// auth.currentSession (which is @Published) and AUTOMATICALLY shows
// the sign-in screen when the session is cleared remotely. Delivery
// is instant (sub-second) over a Server-Sent Events channel the SDK
// opens after sign-in, with a 13-minute heartbeat fallback in case
// the long-lived connection is blocked by a corporate firewall.
// Triggers that clear the local session:
//   • Customer self-requested account deletion via /customer/portal.
//   • Refund issued AND no eligible free-tier plan to fall back to
//     (the app you sell becomes unusable for that buyer; SDK kicks them
//     out so they can re-purchase or close the app).
//   • You suspended/banned the user in the Onelo admin dashboard.
//   • Hard-delete by the 30-day account-deletion cron job.
//
// REQUIREMENTS so the auto-logout actually shows the sign-in screen:
//   1. OneloAuthView MUST be your ROOT view — above any NavigationStack,
//      TabView, or custom router. If it's nested inside, navigation pop
//      stays on whatever screen the user was on when revoked.
//      ❌ NavigationStack { OneloAuthView(auth: auth) { ContentView() } }
//      ✅ OneloAuthView(auth: auth) { NavigationStack { ContentView() } }
//   2. In ContentView observe auth via @EnvironmentObject / @ObservedObject —
//      never capture it into a local 'let' (snapshot won't update on revoke).
//      ❌ let user = auth.currentSession?.user; if user != nil { … }
//      ✅ if let user = auth.currentSession?.user { … }
//   3. If you maintain your own NavigationPath, reset it on revoke so the
//      stack doesn't outlive the session:
//        .onChange(of: auth.currentSession) { newSession in
//            if newSession == nil { navigationPath = .init() }
//        }
//
// Full working example with NavigationStack + path reset:
//
//   @main struct MyApp: App {
//       @StateObject var auth = OneloAuth(config: .init(/* … */))
//       var body: some Scene {
//           WindowGroup {
//               // OneloAuthView wraps the whole NavigationStack so that on
//               // remote-revoke the entire stack is replaced by the hosted
//               // sign-in page — no leftover pushed screens.
//               OneloAuthView(auth: auth) {
//                   RootView().environmentObject(auth)
//               }
//           }
//       }
//   }
//
//   struct RootView: View {
//       @EnvironmentObject var auth: OneloAuth
//       @State private var path = NavigationPath()
//
//       var body: some View {
//           NavigationStack(path: $path) {
//               HomeView()
//                   .navigationDestination(for: Route.self) { /* … */ }
//           }
//           // Belt-and-suspenders: reset the path on revoke so deep
//           // links don't survive the logout. OneloAuthView already
//           // re-presents the sign-in page; this just clears the stack
//           // behind it so the user lands on HomeView after re-login.
//           .onChange(of: auth.currentSession) { newSession in
//               if newSession == nil { path = NavigationPath() }
//           }
//       }
//   }
//
// If you want to show a one-time "your account was deleted" toast
// before re-presenting the sign-in screen, observe the
// auth.isUserRevoked flag (also @Published):
//
//   .onChange(of: auth.isUserRevoked) { revoked in
//       if revoked { showAccountDeletedToast() }
//   }
//
// ── AppKit / multi-window apps ──────────────────────────────
// The "OneloAuthView as root" pattern above assumes a single SwiftUI
// WindowGroup. Menu-bar utilities, floating widgets, and multi-window
// editors (separate NSWindow instances for face / bubble / chat / auth)
// don't fit that shape — your main user-facing window is NOT the one
// hosting OneloAuthView, so the SwiftUI re-render on revoke can't
// hide it. Drive your windows from Combine instead.
//
// ⚠️ TWO DIFFERENT SIGNALS. Do not use one for both directions.
//
//   SHOW YOUR APP  →  auth.$isAllowedIn   (signed in AND allowed in)
//   HIDE YOUR APP  →  auth.$currentSession going non-nil → nil (revoke)
//
// Using $currentSession for the "show" direction is the mistake this warning
// exists for: a user with no plan on a paywalled app IS signed in, and letting
// them in on that signal walks straight past your paywall and past the Apple
// Access Gate. $isAllowedIn is false for them, and flips true by itself the
// moment they buy — which the session signal never does.
//
//   auth.$isAllowedIn
//       .removeDuplicates()
//       .sink { [weak self] allowed in
//           guard allowed else { return }
//           Task { @MainActor in self?.showApp() }   // close login window, bring UI up
//       }
//       .store(in: &cancellables)
//
// Needs onelo-swift 3.80.0 or newer. Below that, build it yourself as
//   isReady && currentSession != nil && (!paywallEnabled || hasActiveAccess)
// and note the isReady term: paywallEnabled is false until the remote config
// lands, so without it every user looks allowed in for the first moments.
//
// The revoke direction, which is a different edge entirely:
//
//   import Combine
//
//   private var cancellables = Set<AnyCancellable>()
//   private var hadSession = false
//   private var isSigningOut = false  // set true around your own auth.signOut() call
//
//   auth.$currentSession.sink { [weak self] session in
//       guard let self else { return }
//       let has = session != nil
//       defer { self.hadSession = has }
//       // Fire only on non-nil → nil (the actual revoke moment).
//       // Skip the user-initiated Sign out path you already handle.
//       if self.hadSession && !has && !self.isSigningOut {
//           Task { @MainActor in
//               self.mainWindow.orderOut(nil)
//               self.otherWindows.forEach { $0.orderOut(nil) }
//               self.showAuthWindow()   // your NSWindow hosting OneloAuthView
//           }
//       }
//   }.store(in: &cancellables)
//
// Note: OneloAuthView hosted in a hidden / minimized / off-screen
// NSWindow will NOT react to remote-revoke. Bring the window forward
// (orderFrontRegardless / makeKeyAndOrderFront) BEFORE you expect the
// hosted page to appear.

// ── Automatic legal-consent gate ────────────────────────────
// You don't need to write any code for this. When you publish a
// material update to your Terms of Service in the Onelo dashboard,
// OneloAuthView automatically shows the updated document — in the
// SAME hosted WKWebView used for sign-in — the next time the user
// opens the app after the effective date. The user must tap
// "Accept & Continue" to reach your content(), or "Sign out".
// There is no "Decline" button: nothing to mis-tap.
//   • Terms of Service → blocks the app until accepted (legal
//     requirement in DE/PL: silent "acceptance by continued use"
//     is not valid — an explicit tap is required).
//   • Privacy Policy / DPA / Cookies → users are notified by email
//     and the app is not blocked (GDPR information duty) — UNLESS you
//     published the version with "Require acceptance", which shows the
//     same blocking gate as Terms.
//
// This automatic gate only works WHILE OneloAuthView is mounted — i.e. when it
// wraps your content() as the root view (the pattern in step 2).
//
// ⚠️ IF YOU USE OneloAuthView ONLY FOR SIGN-IN and switch to your own UI after
// login (OneloAuthView is no longer in the view tree), the automatic gate
// cannot fire — nothing is left to host it. In that case add ONE line to your
// post-login root so the gate is enforced on YOUR UI:
//
//   struct HomeView: View {
//       @EnvironmentObject var auth: OneloAuth
//       var body: some View {
//           MyAppContent()
//               .oneloConsentGate(auth: auth)   // ← blocking gate on your own UI
//       }
//   }
//
// .oneloConsentGate presents a full-cover hosted gate OVER your UI when a
// blocking version is pending (Accept & Continue / Sign out, no dismiss). It
// re-checks on appear, on app-foreground, and on the real-time SSE push — so a
// running, logged-in app shows the gate instantly when you publish.
//
//   • Terms of Service → blocks the app until accepted (legal requirement in
//     DE/PL: silent "acceptance by continued use" is not valid).
//   • Privacy / DPA / Cookies → notified by email only; never blocks the app
//     (GDPR information duty) unless you published it with "Require acceptance".
//
// Advanced (optional): read pending consents yourself, e.g. for a custom banner —
//   let pending = await auth.requiredConsents()
//   let mustAccept = pending.filter { $0.blocking }   // blocking, past effective
// Recording acceptance from your own UI:
//   try await auth.acceptConsent(versionId: requirement.versionId)

// The frontend sends the user's ACCESS TOKEN (returned by the Onelo SDK after
// sign-in — NOT your secret key) as: Authorization: Bearer <token>.
// requireUser verifies it and attaches req.oneloUser. When the App's Sign-in
// Mode is an external provider (Supabase, Clerk, Firebase…), requireUser also
// accepts that provider's token, so the frontend keeps sending what it sends.
app.get('/me', requireUser(onelo), (req, res) => {
  // requireUser guarantees req.oneloUser is set here — assert non-null.
  res.json({ id: req.oneloUser!.id, email: req.oneloUser!.email })
})

// Post-verify gates + SSE support (all optional):
//   requireUser(onelo, { acceptQueryToken: true })   // allow ?token= for EventSource/SSE
//   requireUser(onelo, { identifyMonitor: false })   // opt out of auto monitor.setUser (on by default when a monitor scope is active)
//   optionalUser(onelo)   // sets req.oneloUser = null instead of 401 (a 503 outage still surfaces)

// ── Other frameworks — one adapter import, same onelo client ──
//   Next.js  → import { withUser } from '@onelo/node/next'
//              export const GET = withUser(onelo, async (req, user) =>
//                Response.json({ id: user.id }))
//   Fastify  → import { requireUser } from '@onelo/node/fastify'
//              fastify.get('/me', { preHandler: requireUser(onelo) },
//                async (req) => ({ id: req.oneloUser!.id }))
//   Hono     → import { requireUser } from '@onelo/node/hono'
//              app.use('/me', requireUser(onelo))
//              app.get('/me', (c) => c.json({ id: c.get('oneloUser').id }))
//   Any other (Koa, Nest, raw http, WebSocket, queue worker):
//              import { verifyToken } from '@onelo/node'
//              const user = await verifyToken(onelo, token)   // throws typed errors
//
// Error → status: OneloAuthInvalidToken / missing → 401 · OneloAuthForbidden /
//   failed gate → 403 · OneloAuthRateLimited (429) / OneloAuthUnavailable (5xx) → 503.