Spaces:
Sleeping
Sleeping
Commit History
-
feat: Migrate frontend from static HTML to Next.js 16 App Router
eeshaAI- All 16 buyer pages: home, login, product, cart, checkout, payment, categories, search, seller-profile, profile, orders, wishlist, videos, live, live-watch, group-buy, ai-chat, link-account, telegram - 7 seller dashboard pages with shared sidebar layout - 22 API route proxies to existing Supabase Edge Functions - Suspense boundaries for useSearchParams pages - Standalone output build for Docker deployment - Dockerfile (multi-stage Node 20 alpine, port 7860) - README with HF Space YAML frontmatter - .hfignore for lean Docker context Backend unchanged: 27 Supabase Edge Functions, Render bot, OpenWA, PalmPay payment verifier — all remain in place.94c9882 -
fix: Universal cyan/white theme + smaller fonts + ₦ currency + navbar everywhere
Z UserCOLOR FIXES (30 files updated): - Replaced ALL orange/amber/red/gold/purple/violet/teal/rose/indigo/pink colors with cyan (#00d4ff / #0891b2) across every HTML, CSS, and JS file - All gradients now use cyan - All badges, buttons, text accents → cyan - All borders, focus rings, backgrounds → cyan - No more yellow/orange/amber anywhere FONT SIZES (Temu/AliExpress/Amazon style): - Base font: 14px (was 16px) - Body text: 13px - H1: 20px (was 40px), H2: 18px, H3: 16px - Meta/badges: 10px - Mobile: base 13px (even denser) - Added !important overrides for Tailwind text-xs/sm/base/lg/xl/2xl/3xl CURRENCY: - All prices now show ₦ instead of $ (cart, checkout, product, orders, etc.) - All 'USD' → 'NGN' - All locale 'en-US' → 'en-NG' NAVBAR: - Added universal navbar to 18 pages that were missing it: cart, categories, checkout, product, profile, orders, wishlist, settings, search-result, ai-chat, order-confirmation, videos, live-watch, whatsapp, telegram - All pages now have the same nav…00611f0 -
feat: On-demand payment verifier on HF Space + 3-role bot welcome
Z User1. Payment verifier hosted on HF Space (/api/verify-payments): - Triggered when buyer clicks 'I've sent it' (not a cron job) - Also triggered on each status poll (every 5 seconds) - Uses Python imaplib (proven, fast) — connects to Gmail, fetches 10 most recent unread PalmPay emails, parses amounts, matches against awaiting_verification orders - Updates matched orders in Supabase DB directly - Marks matched emails as read (prevents reuse) 2. Payment flow: - Buyer clicks 'I've sent it' → confirm_sent (edge function) - Frontend immediately calls /api/verify-payments (Gmail IMAP check) - Frontend polls check_status every 5s, each poll also calls /api/verify-payments → instant match detection 3. Bot welcome: 3-role selection (from handwritten notes): When user sends /start or first message: 1️⃣ Registered Buyer — browse, cart, checkout, track orders 2️⃣ Registered Seller — add products, upload videos, manage store 3️⃣ Guest Buyer — browse…87fd9d2 -
feat: PalmPay payment option in checkout + delivery info flow
Z User1. Added PalmPay bank transfer option to checkout.html payment methods - Cyan gradient icon, 'Auto-verified via AI' label - When selected, redirects to payment.html after order placement - Skips card/wallet validation for PalmPay orders 2. Checkout flow: shipping info (name, email, phone, address, city, state, zip) → payment method selection → place order → payment.html (for PalmPay) → auto-verification via AI + Gmail IMAP → order confirmation 3. Payment page receives order details via URL params: ?orderId=X&total=Y&items=Z&count=N 4. PalmPay account details set in Supabase secrets: - Account name: Abdlrazaq Bidemi Awofolaji - Account number: 8088561764 - Bank: PalmPay 5. Gmail credentials set: - Email: fuhandinho@gmail.com - App password: wttdauhasjdpqrem3f0a091 -
fix: remove duplicate searchGmailForPayment function (syntax error)
Z User351fd2b -
feat: AI-powered payment verification (Qwen2.5-72B) + bank name collection
Z UserUPGRADES: 1. Added buyer_bank_name field to payment_orders table + create_order endpoint 2. Frontend now collects buyer's bank name (required field) 3. Gmail IMAP polling now fetches full email content (headers + body) 4. AI matching uses Qwen2.5-72B to verify ALL THREE fields: - Buyer name (fuzzy match — handles variations like 'John Doe' vs 'JOHN D.') - Bank name (exact or close match) - Amount (must match exactly, including decimal suffix) 5. AI returns structured JSON: {match, email_index, sender_name, amount} 6. Fallback: if AI fails, falls back to simple amount matching 7. After match: marks Gmail email as read (prevents reuse) FLOW (matches the original plan): 1. User enters: full name, email, bank name 2. System generates unique amount (base + decimal suffix) 3. User transfers to PalmPay → clicks 'I've sent it' 4. AI checks Gmail for PalmPay emails matching name + bank + amount 5. On match → order confirmed, redirect to order confirmation page 6. On timeout → WhatsApp…cb3d98c -
feat: Payment gateway — PalmPay manual transfer + Gmail IMAP verification
Z UserDATABASE: - payment_orders table: order_id, buyer info, expected_amount (with unique decimal suffix), status (pending → awaiting_verification → matched/expired), matched_email_id (prevents reuse) - payment_rate_limits table: 1 confirm per order, 3 per IP per 10 min EDGE FUNCTION (payment): - create_order: generates unique order_id + unique expected_amount (base + 0.01-0.99 suffix) - confirm_sent: validates + rate-limits, then triggers background Gmail IMAP polling that runs every 30s for up to 10 minutes, searching for PalmPay alert emails that match the exact amount - check_status: returns only status + message (no email/transaction details) GMAIL IMAP: - Connects to imap.gmail.com:993 via TLS - Searches INBOX for unread emails FROM 'palmpay' in last 24h - Parses amount from email body (₦5,000.23 format) - Matches against expected_amount (exact match including decimal suffix) - Marks matched email as read (SEEN flag) - Checks matched_email_id to prevent reusing the same emai…6b807b3
-
Production fixes: Depop-style sellers, AI Mode, products loading, cart count, account page
Z User1. Redesigned 'Discover Sellers' section on home page to Depop style: - Each seller shown as a card with 2x2 product grid (4 product images) - Circular avatar + seller name + follower count - Black 'Shop' button (hover: cyan) - Products are fetched and filtered by seller_id 2. Added 'AI Mode' to category bar BEFORE Explore (as requested) - Cyan gradient pill with sparkle icon - Links to ai-chat.html 3. Fixed products not loading on home page: - Root cause: handleHome() used discount_percentage column (doesn't exist) and sellers!inner join (FK relationship issue) — both returned empty - Fixed: fetch all products once, categorize client-side - Flash deals: products with units_sold > 0 (fallback: first 5) - Farm products: filter by category containing 'farm'/'food' (fallback: next 5) - Trending: newest 10, New arrivals: newest 5 4. Deleted test screenshots that were appearing on screen 5. Fixed cart count in navbar: - Badge now hides when count…c743329 -
Production refactoring: move buying folder to root, separate seller login, new navbar
Z UserMAJOR CHANGES: 1. Moved all files from 'Eesha buying folder/' to root directory - login.html, signup.html, cart.html, wishlist.html, profile.html, orders.html, categories.html, product.html, checkout.html, order-confirmation.html, settings.html, auth.html - Fixed all path references (../js/ → js/, ../css/ → css/, etc.) - Updated all references from 'Eesha buying folder/' to '' in all files 2. Created separate seller login page at /seller/login.html - Dark theme to distinguish from buyer login - Redirects to seller dashboard after login - Links back to buyer login 3. New universal navbar (shared/navbar.html) - Clean: Home, Shops, Cart, Account only - Category bar below search: Explore, Flash Deals, Farm Fresh, Phones, Electronics, Fashion, Home, Beauty, Sports, Books, Videos, Live - Mobile bottom nav: Home, Shops, Cart, Account - User dropdown with links to profile, orders, wishlist, seller dashboard, link-account, telegram - Cyan +…44d212f -
fix: product page 404 — FK constraint + column name fix
Z UserRoot cause: products.seller_id had a FK pointing to auth.users instead of public.sellers. PostgREST couldn't infer the relationship, so the by_id query with sellers(...) join returned 'Product not found' for every product. Fixes: 1. Dropped the wrong FK (products → auth.users) 2. Added correct FK (products → sellers) 3. Fixed column name in edge function: sellers(name,...) → sellers(business_name,...) 4. Also fixed the category query which had the same sellers(name,...) issue 5. Pulled the products edge function source into the repo for trackingbf04856 -
fix(phase4): edge functions now broadcast via Render bot /internal/broadcast
Z UserEdge functions (seller-products, live, group-buy) now call the Render bot's /internal/broadcast endpoint instead of the Supabase telegram edge function. This uses the bot's TELEGRAM_BOT_TOKEN (which never leaves Render) to send actual Telegram messages to subscribers. Auth: X-Internal-Key header (BOT_INTERNAL_KEY env var on both sides).6910d77 -
Phase 4 — Cross-platform integration
Z User4 new feature areas built on existing HTTP-only cookie auth + EdgeFunctions client. EDGE FUNCTIONS (2 new, 3 modified): - cross-platform (NEW): 12 ops Web-side (cookie auth): generate_link_code, my_phone_links, unlink_phone Bot-side (X-Bot-Api-Key auth): bot_link_account, bot_get_cart, bot_add_to_cart, bot_remove_from_cart, bot_clear_cart, bot_checkout, bot_join_group_buy, bot_get_product, bot_search, bot_get_active_group_buys, bot_get_live_sessions, bot_get_seller_products - telegram (NEW): broadcast (internal-only), webhook (Telegram updates), set_webhook, channel_info, subscribe, unsubscribe, recent - seller-products (MODIFIED): auto-broadcasts new products to Telegram channel + subs - live (MODIFIED): auto-broadcasts live session starts to Telegram - group-buy (MODIFIED): auto-broadcasts new group buys to Telegram DATABASE (3 new tables): - user_phone_links (phone ↔ user_id, link_code, confirmed_at) — WhatsApp linking - telegram_subscribers (chat_id,…f90569c -
fix(phase3): video upload via /api/video-upload proxy (presigned URL endpoint had bucket bug)
Z User- The Supabase Storage 'create-signed-upload-url' endpoint returns 'Bucket not found' for our product-videos bucket even though the bucket exists (likely a TUS/resumable upload issue). - Replaced presigned URL approach with a direct PUT to /api/video-upload/{seller_id}/{product_id}/{filename} which the web-server proxies to Supabase Storage using the service role key. - Added SUPABASE_SERVICE_ROLE_KEY env var to HF Space. - The browser never sees the service key — it goes through the auth-verifying proxy. - Fixed videos feed bug: PostgREST couldn't infer FK between product_videos and sellers (no FK declared in migration), so sellers are now fetched separately and merged. - Updated seller/videos.html to use the new upload endpoint with XHR progress bar. - Updated test_phase3_live.py to match.f7b3b45 -
Phase 3 — Content & Discovery
Z User4 new feature areas, all using existing HTTP-only cookie auth + EdgeFunctions client. EDGE FUNCTIONS (4 new, all deployed): - videos: feed (algorithmic with personalized scoring), by_product, by_seller, get (increments views), upload_url (presigned PUT to Supabase Storage), create, delete, like, unlike, mine - trending: list (computes views + shares*3 + purchases*5 over last N hours, falls back to row-level aggregation if RPCs are missing), log_view, log_share - stories: active_bar (grouped by seller with has_unseen flag), by_seller, get (increments views + marks seen), mark_seen, create (auto-posts to activity_feed), mine, delete — 24-hour expiry - discover: recommend (rule-based + optional AI enrichment via Qwen2.5-72B), log_view — uses purchases, cart, wishlist, follows, recent views as signals DATABASE (5 new tables + 1 trigger + 1 storage bucket): - product_videos (status, views_count, likes_count) + product_video_likes with trigger maintaining likes_count - produc…f1d4890 -
Phase 2 — Community Engagement
Z User4 new feature areas, all using existing HTTP-only cookie auth + EdgeFunctions client. EDGE FUNCTIONS (4 new, all deployed): - reviews: by_product, by_seller, create (verifies purchase), helpful, delete - group-buy: create, join, status, active, mine, cancel (Pinduoduo model) - wishlist-share: share (snapshot), get_shared, my_shares, revoke - live: list, get, messages, start, end, join, leave, message, mynext, whatsapp_buy DATABASE (7 new tables + triggers): - product_ratings (avg + count cache, trigger-maintained from buyers_reviews) - group_buys + group_buy_members (status auto-flips to 'completed' at target) - shared_wishlists (token-based, snapshot JSON, view_count) - shop_live_sessions + shop_live_messages + shop_live_viewers (renamed from live_sessions to avoid clash with academy table) FRONTEND (all using EdgeFunctions, zero Supabase SDK): - Product page: WhatsApp/Telegram/copy share buttons, 'Start group buy' button, active group buys list, full reviews section + write-re…b0f33c8 -
chore: ignore supabase CLI linked-project artifacts
Z Userf2a57e4 -
Phase 1 — Social ecommerce: seller dashboard migrated to Edge Functions + follow/feed/discover
Z UserEdge Functions (5 new, all deployed): - seller-dashboard: stats (products, orders, revenue, followers, posts) - seller-products: full CRUD for seller catalog - seller-orders: list orders containing seller's items, with details - seller-profile: get/update seller's own profile - social: public_profile, follow/unfollow, feed, seller_feed, discover Database (migration applied): - seller_follows (follower_id, seller_id) with trigger-maintained counters - activity_feed (seller_id, activity_type, entity_id, title, body, image) - seller_social_stats (followers_count, posts_count) denormalized - Trigger: new product INSERT auto-posts to activity_feed Frontend (all using EdgeFunctions, zero Supabase SDK, zero localStorage tokens): - /seller/{index,products,orders,profile,academy,settings}.html — clean Cellex-branded seller center - /seller-profile.html — public storefront with follow button, tabs (products/about/activity) - index.html: added 'Discover Sellers' carousel + 'From Sellers You Fol…d4abe71
-
feat: HTTP-only cookie auth (production standard — same as AliExpress, Amazon, Gmail)
Switched to HTTP-only cookies for session management. This is the industry standard used by every major website. How it works: - Login: edge function creates session in Supabase web_sessions table → returns { session_id, user } → web-server sets session_id as HTTP-only cookie → strips session_id from response body - All requests: browser AUTOMATICALLY sends the HTTP-only cookie → web-server reads it → forwards as Authorization: Bearer <session_id> - Edge function looks up session_id in web_sessions → gets JWT tokens → verifies → identifies user - Logout: web-server clears cookie + edge function deletes session Security: - HTTP-only: JavaScript CANNOT read the cookie (document.cookie returns nothing) - Secure: only sent over HTTPS - SameSite=Lax: CSRF protection - Max-Age=7 days: persists across tabs, browser restarts, and 7 days - The cookie only contains a random UUID (session_id), NOT a JWT token - The actual JWT tokens live in Supabase web_sessions table - NO localStorage.…f892a0d -
feat: session-based auth stored in Supabase (NO cookies, NO localStorage)
Completely redesigned auth: - Auth tokens (JWT access_token + refresh_token) are stored IN SUPABASE in a new web_sessions table - Frontend receives ONLY a session_id (random UUID) — stored in JS memory - No cookies, no localStorage, no sessionStorage - Even if session_id is stolen via XSS, attacker can't get the JWT tokens (they're in the Supabase database, protected by service role key) Flow: 1. Login → edge function authenticates via Supabase Auth → stores tokens in web_sessions table → returns { session_id, user } 2. Frontend stores session_id in a JS variable (memory only) 3. Each request: frontend sends X-Session-Id header 4. Web-server reads X-Session-Id → forwards as Authorization: Bearer <session_id> 5. Edge function looks up session_id in web_sessions → gets access_token → verifies with Supabase Auth → identifies user 6. Logout → deletes session from web_sessions Files changed: - supabase/functions/auth/index.ts: creates/deletes/checks sessions in web_sessions - su…a02b951 -
feat: cookie-based auth + 4 new edge functions + remove localStorage
MAJOR SECURITY UPGRADE: - Auth tokens now stored in HTTP-ONLY cookies (JavaScript CANNOT read them) - Removed ALL localStorage usage (was bad for production) - Server sets/clears cookies on login/logout - Server reads cookie and adds Bearer header for edge functions New edge functions deployed: - orders: list user orders, get order details - profile: get/update profile + stats - wishlist: get/add/remove wishlist items - checkout: prepare checkout, place order atomically New proxy routes: - /api/orders, /api/profile, /api/wishlist, /api/checkout Frontend changes: - edge-functions.js: removed localStorage, uses in-memory user + cookies - cart.js: uses async getCurrentUser - All 10 remaining pages: removed Supabase UMD + supabase.js script tags - Added edge-functions.js + cart.js script tags to all pagesb8613e0