Daletguard test

Daletguard test — Social anti-fraud verification

This page is used to end-to-end test the daletguard integration from this merchant site to https://daletguard.com. The button below opens a modal containing an iframe hosted on daletguard.com, in which the user picks a social network and completes an OAuth flow. The result comes back to the page via postMessage.

1. “Checkout” scenario

Use case: a customer is about to confirm a cart. We ask for a light anti-fraud check.



        
    

2. “Signup” scenario

Use case: account creation. We require a slightly stronger verification.



        
    

3. What to watch for

  • On click, the status line switches to “Initializing daletguard session…” — that’s the server-side AJAX call to /api/v1/session/init.
  • A modal opens, the iframe loads https://daletguard.com/iframe?token=... and displays the list of available OAuth providers.
  • After choosing a provider (e.g. Google or Microsoft), a popup window opens with the provider’s consent screen, then returns to daletguard.
  • On success, the popup stays open to display the full raw JSON payload collected from the provider (on the daletguard side), while the merchant modal shows ✅ OAuth OK with the session_id and network.
  • The Bearer session_token (moteur API key) must never appear in the browser dev tools — it stays server-side on WordPress.

4. Server-side verification

Once the modal has closed successfully, fetch the collected data from a terminal (replace <SID> with the displayed session_id):

curl -H "Authorization: Bearer dev-api-key" \
  https://daletguard.com/api/v1/session/<SID>/data | jq

The returned JSON should contain an authentications array with at least one entry for the chosen provider, including its email, sub, name, and any extended data (birthday, phones, addresses for Google via People API; amr/acr MFA context for Microsoft via id_token).

5. Common errors and hints

  • Blank modal / blank iframe → browser console: likely a CSP frame-ancestors issue on the daletguard nginx side.
  • “Init error: HTTP 502” under the button → the merchant-apache container cannot reach daletguard.com, or the DALETGUARD_MOTEUR_API_KEY in the merchant docker-compose does not match MOTEUR_API_KEY on the daletguard side.
  • Google answers redirect_uri_mismatch → in the Google Cloud Console, the authorized URI must be exactly https://daletguard.com/api/v1/auth/google/callback.
  • Microsoft answers AADSTS50011 → same thing on Azure Portal → App registration → Authentication → redirect URI must be exactly https://daletguard.com/api/v1/auth/microsoft/callback.
  • Iframe returns “invalid token” → the session_token has expired (default TTL = 10 min) or was already used. Click the button again to regenerate.
  • postMessage is ignored → the origin is not whitelisted. Check that DALETGUARD_BASE_URL on the merchant side is exactly https://daletguard.com (no trailing slash, same scheme).

6. Useful logs during the test

In a terminal on the daletguard server, keep running:

docker compose logs -f fastapi

You should see, in order: POST /api/v1/session/init, GET /iframe, GET /api/v1/auth/networks, GET /api/v1/auth/{network}/start → 302, then GET /api/v1/auth/{network}/callback → 302.