# Legacy Credentials and Config (Retraced) ## Source folders used - `../dewemoji-api` - `../dewemoji-chrome-ext` - `../dewemoji-site` ## 1) Extension auth and credential flow From `dewemoji-chrome-ext/panel.js`: - User enters license key in settings. - Extension verifies via `POST https://api.dewemoji.com/v1/license/verify`. - License key is sent as payload and reused in headers for data requests. Headers used on licensed requests: - `Authorization: Bearer ` - `X-License-Key: ` - `X-Account-Id: ` - `X-Dewemoji-Frontend: ext-v1` (always sent) ## 2) Local/sync storage keys (extension) Local storage keys observed: - `theme` - `licenseValid` - `licenseKey` - `lastLicenseCheck` - `actionMode` - `searchCache` - `accountId` - `accountLabel` - `profileUUID` - usage key pattern: `usage_YYYYMMDD` Sync storage keys observed: - `preferredSkinTone` - `toneLock` ## 3) Backend (`dewemoji-api`) auth status From `helpers/auth.php`: - Reads license from query `key` or bearer token. - Validation hooks exist (`isValidGumroad`, `isValidMayar`) but are stubs returning `false`. - Effective behavior in current code: fallback to free tier. ## 4) `dewemoji-site` credential/config status - Site folder currently scaffold/empty files. - No active credential logic currently implemented there. ## 5) Hardcoded secrets check result In inspected source files: - No committed private API secrets/tokens/passwords found. - License key is user-provided at runtime (extension). ## 6) Rebuild config recommendations For new NativePHP app, add env-managed secrets for: - License provider API credentials - Internal signing/app secrets - Any DB credentials And keep backward compatibility during migration for: - `Authorization` bearer auth - legacy `X-License-Key` - `X-Account-Id`