Skip to main content

Running Inside the Alogame Portal

Most games load standalone (their own domain, their own tab). If your game is instead loaded inside an Alogame portal — an <iframe> on game.alogame.vn, or a popup opened by it — the SDK automatically synchronizes login state with the portal. There is nothing to call; this happens during OEGWebSdk.init().

What happens automatically​

Game loads inside the portal (iframe or popup)
        │
        ▼
SDK detects an iframe parent / window opener → "embedded" mode
        │
        ▼
SDK asks the portal: "what's the current session?"
        │
        ├─ Portal replies LOGIN(token)  → SDK adopts that session
        └─ Portal replies LOGOUT        → SDK clears any local session
  • When embedded, the portal is the source of truth for the session — even if the game has its own cached token from a previous standalone visit, it is reconciled against the portal's answer on every load.
  • If the player logs in or out inside the game (via OEGAuth.login() / OEGAuth.logout()), the SDK notifies the portal so other embedded surfaces stay in sync.
  • If the game is opened with a ?oeg_token=... URL parameter (e.g. a portal link that hands off a session), the SDK consumes it on load and strips it from the URL/history — no game code needed.

Security​

Cross-window messages are only trusted from an origin under alogame.vn (or localhost in development) — the SDK never sends or accepts a session token to/ from an unknown origin. A game running standalone (no iframe parent, no opener) never sends or receives these messages at all, so this feature is fully inert for normal integrations.

What you don't need to do​

  • No API to call — detection and sync are automatic in OEGWebSdk.init().
  • No extra config — the trusted portal origin is built into the SDK.
  • Standalone games (the common case) are unaffected; this only activates when the game detects it's running inside a portal window.