Saltar a contenido

Shopify App Store — estado de preparación

Fecha: 2026-08-31
Estado: Preparación técnica en curso; todavía no lista para enviar.

Lo que ya funciona

  • Frontend Vite accesible como shell de Commerce.
  • Auth TimeLiber con cookies HttpOnly y refresh rotatorio.
  • Multi-tenancy, capabilities y RLS sobre PostgreSQL.
  • Creación/listado de intents de conexión Shopify.
  • Allowlist de scopes read-only y validación de dominio/API version.
  • Verificación HMAC y allowlist de topics en el adaptador de webhooks.
  • Documentación técnica, threat model y ADR de arquitectura.
  • Scaffold oficial React Router enlazado con la app TimeLiber Connect.
  • Flujo DEV de código de conexión de un solo uso entre una organización TimeLiber y la sesión Shopify autenticada; compila en ambas superficies pero todavía no está validado contra una tienda real.
  • La entrada pública del conector ya no solicita manualmente el dominio de la tienda, conforme al requisito 2.3.1.
  • Endpoint y vista tenant-aware de pedidos recientes con estado financiero, fulfillment, total, moneda y líneas compradas (nombre/variante, SKU, cantidades y precios). Refresca cada minuto sin persistir pedidos y usa no-store. Está cubierto por pruebas sin PII, pero aún no se considera validado contra Shopify real.
  • El scope efectivo del MVP se redujo a read_orders; catálogo, inventario y ubicaciones quedaron fuera. Los productos se leen como líneas del pedido.
  • shopify.app.toml validado por Shopify CLI el 2026-08-31.
  • Build de producción, TypeScript y auditoría npm sin vulnerabilidades de producción conocidos al 2026-08-31.
  • Configuración de los tres webhooks obligatorios de privacidad y handlers con autenticación HMAC del SDK oficial.
  • Páginas de privacidad, términos y soporte implementadas en el conector.
  • Sesiones offline con access/refresh tokens cifrados antes de persistencia.
  • Session store migrado del SQLite del template a commerce_connect_db en el PostgreSQL compartido, con roles owner/runtime separados y sin SUPERUSER/BYPASSRLS.
  • TimeLiber Connect es el único dueño de la credencial Shopify. Commerce sólo conserva el vínculo tenant↔shop y consulta al conector por REST interno con JWT de servicio corto; no copia ni intenta sincronizar tokens.
  • Gate operativo de secretos implementado: clave AES-256 de sesión generada fuera del repositorio, instalación interactiva del client secret rotado y preflight que valida permisos/formato sin imprimir valores.
  • /shopify/health comprueba proceso y acceso real a commerce_connect_db; la ruta interna de pedidos no forma parte de las reglas públicas de Traefik.
  • Dominio base https://commerce.timeliber.com.co publicado con certificado válido; el router Shopify está desplegado y /shopify/health responde sano.
  • Distribución personalizada seleccionada para la Development Store y versión timeliber-connect-6 activa. Los webhooks usan URLs absolutas para evitar que Shopify les anteponga /app.
  • El servidor de producción registra únicamente método, pathname, estado y latencia; nunca query strings que puedan contener id_token.
  • La instalación personalizada en pulsecommerce-test completó token exchange, abrió /app con 200 y guardó una sesión offline cifrada. Falta vincularla a una organización TimeLiber mediante el código de un solo uso.
  • El botón de vinculación sólo recibe la propiedad booleana loading durante un envío real. Omitirla en reposo evita que React 18 deje presente el atributo del web component y lo mantenga deshabilitado antes de enviar el formulario.
  • El servidor estático de Commerce no conserva access logs: el encabezado Referer de recursos cargados desde una app incrustada puede incluir tokens de sesión efímeros. La observabilidad permanece en API y conector mediante registros sanitizados sin query strings.

Bloqueadores para una Public App

  • El secreto nuevo está instalado y el antiguo fue revocado. La instalación DEV y el linking tenant-aware ya respondieron correctamente; falta probar pedidos y entregas nuevas de webhooks.
  • Repetir y validar públicamente /app, /auth/* y /webhooks/* después de corregir el secreto. Las rutas públicas /privacy, /terms y /support pertenecen al frontend TimeLiber y ya responden por HTTPS; el contenido sigue sujeto a revisión legal antes del envío a App Review.
  • Falta validar OAuth/Managed Installation y callback con la Development Store.
  • El adaptador GraphQL read-only existe en TimeLiber Connect y Commerce lo consume por una ruta exclusivamente interna. Falta conectarlo a una instalación real y demostrar la consulta de estados de pedidos al reviewer.
  • La ingesta durable de eventos comerciales queda fuera del MVP nivel 1: la vista consulta Shopify en vivo y no persiste pedidos. Se reconsiderará sólo después de validar el journey y definir retención.
  • Falta validar con entregas reales los webhooks de privacidad y su runbook.
  • Las páginas legales son borradores técnicos y requieren aprobación legal antes de usarlas en el listing.
  • Falta observabilidad, backup probado del session store y credenciales/guion del reviewer.
  • Shopify exige tokens offline expirables para nuevas public apps. El SDK oficial conserva y refresca la sesión offline en el store del conector; falta validar esa rotación con la Development Store y probar recuperación ante expiración/revocación.
  • Falta validar con pedidos reales la superficie funcional ya implementada y grabar la evidencia para el reviewer.
  • Falta decidir si TimeLiber Connect será completamente gratis. Si el acceso a la integración exige un plan pago de TimeLiber, ese cobro debe pasar por Shopify App Pricing/Billing para distribución en App Store.
  • Protected Customer Data nivel 1 no está solicitado. El MVP no consulta nombre, dirección, email o teléfono; shippingAddress.city queda para una solicitud posterior de nivel 2.

Pre-auditoría oficial de código (2026-08-31)

Se descargó y evaluó la lista canónica de requisitos verificables por código publicada por Shopify el 2026-08-31.

  • 25 probablemente cumplen: session tokens/template oficial, ausencia de checkout/pagos/temas/POS/marketplace, GraphQL Admin API, App Bridge, scopes mínimos y comienzo de instalación sin pedir el dominio manualmente.
  • 6 requieren validación: modelo de cobro (tres requisitos), retorno tras instalación, reinstalación y TLS/ruteo del conector una vez desplegado.
  • 10 grupos omitidos por no aplicar: theme app, payments, payment facilitator, purchase options, product sourcing, checkout customization, sales channel, post-purchase/mobile/donation según sus condiciones u opt-in. Los opt-in se mantienen fuera del alcance actual.

Esta pre-auditoría no reemplaza las pruebas automáticas ni la revisión humana de Shopify. Aun con los requisitos de código en verde, la app debe ser instalable y su función principal debe poder probarse de extremo a extremo.

Criterio de “funcionando”

La vertical funciona como fundación técnica y entorno DEV. No funciona aún como Public App instalable por múltiples tiendas ni puede enviarse honestamente a Shopify App Store. La etiqueta visible del frontend mantiene ese estado para evitar presentar un prototipo como producto aprobado.

Orden recomendado antes del envío

  1. Rotar el secreto y desplegar el router Shopify mediante secretos montados.
  2. Completar instalación OAuth y linking de intent/tenant.
  3. Completar GraphQL, webhooks comerciales e idempotencia.
  4. Validar privacidad, soporte, backups y observabilidad en producción.
  5. Ejecutar la auditoría visual/accesibilidad y probar en Development Stores.
  6. Preparar listing, capturas, screencast y credenciales del reviewer.
  7. Ejecutar de nuevo la checklist oficial inmediatamente antes de seleccionar distribución pública y enviar.

Fuentes oficiales: envío a revisión, requisitos de App Store, webhooks obligatorios y datos protegidos.