<div class="key-takeaways"><ul><li>นักพัฒนาที่ใช้ภาษาอื่นนอกเหนือจาก Node ต้องเผชิญความท้าทายในการจัดการแอปฝังตัวใน iframe</li><li>แอป Shopify ฝังตัวไม่สามารถใช้ PHP session ได้ จึงต้องพึ่งพา Session Token แบบ JWT ที่มีอายุเพียง 1 นาที</li><li>การแลก Token ใช้มาตรฐาน OAuth 2.0 token exchange (RFC 8693) แทนการทำ authorization-code แบบเดิม</li><li>บทความนี้นำเสนอโค้ดจริงจากการใช้งานจริงในแอป StockPilot บน Symfony 7.4 และ PHP 8.5</li></ul></div>เอกสารทางการของ Shopify มักจะเน้นเส้นทางหลักด้วย Node, Official CLI และเทมเพลต Remix เป็นหลัก ทำให้นักพัฒนาที่เลือกใช้ภาษาอื่นต้องเผชิญกับความท้าทายตั้งแต่ก้าวแรก เนื่องจากแอปพลิเคชันของคุณจะรันอยู่ใน iframe ภายในหน้าผู้ดูแลระบบของ Shopify ซึ่งเบราว์เซอร์จะไม่ยอมส่งคุกกี้ข้ามเว็บไซต์ให้ และ Token ที่จำเป็นต่อการเรียกใช้งาน Admin API ก็จะต้องถูกนำมาแลกเปลี่ยนกันแบบสด ๆเรื่องเหล่านี้ไม่ได้ยากเกินความสามารถ แต่มันแค่ขาดเอกสารอธิบายสำหรับนอกเหนือจากฝั่ง JavaScript เท่านั้น บทความนี้จึงรวบรวมเส้นทางด้านความปลอดภัยและการยืนยันตัวตนฉบับสมบูรณ์สำหรับการพัฒนาแอปพลิเคชัน Shopify แบบฝังตัวด้วย Symfony 7.4 และ PHP 8.5 ซึ่งนำมาจาก StockPilot แอปพลิเคชันจริงที่ผ่านการตรวจสอบบน Shopify App Store และเปิดให้บริการอยู่ในปัจจุบัน โดยทุกชุดโค้ดด้านล่างนี้คือโค้ดสำหรับใช้งานจริง ไม่ใช่เพียงโค้ดจำลองแอปพลิเคชันแบบฝังตัว (Embedded app) คือหน้าเว็บที่แสดงผลอยู่ภายใน admin.shopify.com ผ่าน iframe แบบ cross-origin ในบริบทนี้ Third-party cookies ไม่สามารถใช้งานได้อีกต่อไป ส่งผลให้ PHP session ไม่สามารถใช้งานได้และไม่มีวันใช้งานได้ คำตอบของ Shopify คือ JWT ระยะสั้นที่เรียกว่า Session Token ซึ่งสร้างโดย App Bridge (ไลบรารี JavaScript ของ Shopify ที่โหลดจาก CDN) ในทุก ๆ คำขอ โดยโทเค็นนี้จะมีอายุการใช้งานเพียง 1 นาทีและถูกแนบไปกับทุกคำขอ fetch() ภายในเว็บไซต์สถาปัตยกรรมนี้บังคับให้เกิดการแบ่งส่วนที่นักพัฒนา PHP มักจะไม่ค่อยทำโดยปริยาย:<ul><li>ส่วนเชลล์ (Shell) และหน้าต่างผู้ดูแลระบบ: ต้องให้บริการอย่างรวดเร็ว, มีการแคชได้ง่าย และไม่ต้องใช้การยืนยันตัวตนในฝั่งเซิร์ฟเวอร์</li><li>ส่วนคำขอ API ของแอป: เป็นส่วนที่ stateless ทั้งหมด และต้องทำการตรวจสอบความถูกต้องของ Session Token ในทุก ๆ คำขอที่เข้ามา</li></ul>การแบ่งส่วนนี้ช่วยพลิกสัญชาตญาณดั้งเดิมของ Symfony ที่มักจะป้องกันตัวคอนโทรลเลอร์และเรนเดอร์ข้อมูลจากฝั่งเซิร์ฟเวอร์ โดยในกรณีนี้ การเรนเดอร์ข้อมูลลงในเชลล์จะหมายถึงการยืนยันตัวตนในขณะโหลดหน้าที่ไม่มีข้อมูลประจำตัวใด ๆ ส่งผลให้เชลล์สามารถแคชได้อย่างง่ายดายและมีขอบเขตความปลอดภัยที่ชัดเจนผ่านไฟร์วอลล์เพียงชุดเดียวการกำหนดค่าใน config/packages/security.yaml จะมีรูปแบบดังนี้:<ul><li>webhooks: ตรวจสอบความถูกต้องผ่านลายเซ็น HMAC ภายในตัวคอนโทรลเลอร์ แทนที่จะใช้ไฟร์วอลล์</li><li>api: สำหรับแอปพลิเคชัน Admin API ที่ฝังตัว ใช้ App Bridge session token บนทุกคำขอแบบ stateless</li><li>main: ตั้งค่าเป็น lazy และใช้ผู้ให้บริการข้อมูลผู้ใช้งานในหน่วยความจำ</li></ul>Session Token คือ JWT ที่ลงนามด้วยอัลกอริทึม HS256 โดยใช้ Client Secret ของแอปพลิเคชัน การตรวจสอบลายเซ็นเป็นขั้นตอนที่ทุกคนทำกัน แต่การตรวจสอบ Claim 4 ส่วนหลังจากนั้นมักจะถูกละเลย ซึ่งแต่ละส่วนช่วยปิดช่องโหว่สำคัญ ได้แก่ การตรวจสอบ aud เพื่อป้องกันการยอมรับโทเค็นจากแอปอื่น และการตรวจสอบ iss กับ dest เพื่อป้องกันโทเค็นที่ระบุร้านค้าไม่ตรงกัน<div class="ai-insight">การทำความเข้าใจสถาปัตยกรรมความปลอดภัยของ Shopify บนเฟรมเวิร์กอย่าง Symfony ถือเป็นกุญแจสำคัญในการสร้างแอปพลิเคชันที่ผ่านมาตรฐานความปลอดภัยระดับสูงของ App Store การที่ Shopify บังคับใช้ stateless API และการตรวจสอบ JWT อย่างเข้มงวดช่วยป้องกันช่องโหว่ประเภท CSRF และการโจมตีแบบ cross-origin ได้อย่างมีประสิทธิภาพ ซึ่งนักพัฒนา PHP จำเป็นต้องปรับเปลี่ยนแนวคิดจากการใช้เซสชันแบบเดิมมาเป็นการจัดการโทเค็นระยะสั้นแทน</div>Session Token เป็นเพียงเครื่องยืนยันตัวตนว่าใครกำลังร้องขอข้อมูล แต่ยังไม่เพียงพอต่อการเรียกใช้งาน Admin API โดยคุณจะต้องนำมันไปแลกเปลี่ยนเป็น Access Token ผ่านมาตรฐาน OAuth 2.0 token exchange (RFC 8693) แทนการใช้งาน authorization-code แบบเดิมที่มีการเปลี่ยนเส้นทาง (Redirect) ด้วยระบบติดตั้งแบบจัดการเองนี้ จะทำให้ขั้นตอนการติดตั้งทั้งหมดไม่มีเส้นทาง /auth, ไม่มีหน้าเปลี่ยนเส้นทาง และไม่มี callback โดยคำขอแรกที่ผ่านการยืนยันตัวตนจากร้านค้าใหม่จะทำการแลกเปลี่ยนโทเค็นทันทีในส่วนของ Webhooks จะไม่มีการแนบ Session Token มาด้วย แต่จะใช้การลงนามแบบ HMAC-SHA256 บนเนื้อหาคำขอแบบดิบ (Raw request body) และเข้ารหัส base64 ไว้ในเฮดเดอร์ X-Shopify-Hmac-Sha256 โดยคำว่าดิบหมายถึงข้อมูลก่อนผ่านการแปลงเป็น JSON หรือมิดเดิลแวร์ใด ๆ ทั้งสิ้น ซึ่งการตรวจสอบในส่วนนี้สำคัญมากเพราะการตรวจสอบอัตโนมัติของ Shopify App Store จะส่งเว็บฮุกที่จงใจใส่ลายเซ็นผิดมาทดสอบและต้องการผลลัพธ์เป็นรหัส 401นอกจากนี้ยังมีข้อกำหนดด้าน Content Security Policy (CSP) ในส่วนของ frame-ancestors ที่ต้องถูกคำนวณแบบรายคำขอจากพารามิเตอร์ของร้านค้า และข้อกำหนดที่สำคัญอีกข้อที่มักมองข้ามในเลย์アウトแบบ Twig คือ App Bridge จะต้องเป็นสคริปต์แรกในแท็ก &lt;head&gt; ที่โหลดแบบ synchronous จาก CDN ของ Shopify โดยห้ามทำการมัดรวม (bundle) หรือเลื่อนการโหลด (defer) เด็ดขาดบทความต้นฉบับยังได้ยกตัวอย่างปัญหาชวนปวดหัวในระบบแปลภาษาของ Symfony เมื่อข้อความหัวอีเมลอย่างเช่น digest.attachment : ' Attached: your restock list (%count% items).' ถูกตัดคำสองคำแรกออกอย่างไร้ร่องรอยในระบบจริง เนื่องจาก %count% เป็นตัวเลข ทำให้ข้อความถูกส่งผ่านลอจิกการทำพหูพจน์ของ Symfony และตรงกับเงื่อนไขการตรวจจับข้อความที่มีเครื่องหมายโคลอน ทำให้คำนำหน้าถูกกลืนหายไปโดยไม่มีการบันทึก Log หรือแจ้งข้อผิดพลาดใด ๆ บทเรียนสำคัญจากเหตุการณ์นี้คือ อย่าให้ข้อความที่มีตัวแปร %count% ขึ้นต้นด้วยคำที่มีเครื่องหมายโคลอนตามหลัง และควรเขียนชุดทดสอบที่ตรวจสอบสตริงตั้งแต่ตัวอักษรแรกเสมอที่มา: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/mollenthiel/building-an-embedded-shopify-app-in-symfony-session-tokens-token-exchange-and-the-parts-nobody-438g" target="_blank" rel="noopener noreferrer">Dev.to</a>

<div class="key-takeaways"><ul><li>Developers using languages other than Node face unique challenges handling embedded apps inside iframes.</li><li>Embedded Shopify apps cannot use PHP sessions, relying instead on short-lived JWT session tokens valid for one minute.</li><li>Token exchange utilizes the OAuth 2.0 token exchange standard (RFC 8693) instead of traditional authorization-code flows.</li><li>This guide features production-grade code from StockPilot, a live app running on Symfony 7.4 and PHP 8.5.</li></ul></div>Shopify's official application documentation notoriously provides one primary, first-class path utilizing Node, the official CLI, and a Remix template that handles authentication automatically. Choosing any alternative programming language means stepping off the paved path immediately, primarily because all critical interactions occur before your framework's router ever processes the incoming request. The application operates inside an iframe within the Shopify admin dashboard, preventing browsers from issuing cookies in that context, while required Admin API tokens must be acquired dynamically on the fly.None of these implementation steps are inherently difficult; rather, comprehensive documentation simply does not exist outside the JavaScript ecosystem. This publication outlines the complete authentication and security workflow for an embedded Shopify application built on Symfony 7.4 and PHP 8.5, extracted directly from StockPilot—a live application that successfully cleared Shopify's App Store review process. Every code snippet provided below represents actual production code rather than conceptual sketches.An embedded application resides directly within admin.shopify.com inside a cross-origin iframe architecture. Because third-party cookies are entirely deprecated in this environment, traditional PHP sessions are unavailable and will remain permanently inaccessible. Shopify addresses this constraint through a short-lived JSON Web Token known as a session token. App Bridge, Shopify's JavaScript library served via their CDN, generates one token per request with a one-minute expiration window, automatically appending it to every same-origin fetch() request executed by the page.This mechanism necessitates a structural separation that most PHP developers do not implement by default:<ul><li>The application shell and admin UI: Designed for high-speed delivery, simple caching, and zero server-side authentication overhead.</li><li>The application API requests: Fully stateless endpoints requiring session token verification on every single incoming request.</li></ul>This architectural split intentionally inverts standard Symfony instincts, which typically dictate securing controllers and rendering data on the server side. In this environment, server-side data rendering inside the shell would require authenticating a page load completely devoid of valid credentials. The resulting advantage is a trivially cacheable shell backed by a clean security surface consisting of a single firewall managing one path prefix.Security configurations within config/packages/security.yaml follow this precise structure:<ul><li>webhooks: Authenticators verify HMAC signatures directly within controllers rather than utilizing firewall rules.</li><li>api: Handles embedded admin API requests by validating App Bridge session tokens as stateless connections.</li><li>main: Configured as lazy with user providers stored directly in memory.</li></ul>The session token operates as an HS256-signed JWT utilizing the application's client secret. While verifying cryptographic signatures represents standard practice, subsequent claim validation steps are frequently omitted despite closing critical security vulnerabilities. Omitting audience (aud) validation accepts tokens minted for unrelated applications sharing the same algorithm, whereas ignoring issuer and destination (iss / dest) validation permits mismatched shop credentials.<div class="ai-insight">Mastering Shopify's security architecture within an enterprise framework like Symfony is crucial for maintaining compliance with strict App Store guidelines. By enforcing stateless APIs and rigorous JWT validation, developers effectively eliminate common vulnerabilities such as Cross-Site Request Forgery (CSRF) and cross-origin attacks, bridging the gap between traditional PHP session management and modern token-based architectures.Furthermore, understanding edge cases like translation engine parsing rules prevents silent failures in production environments, highlighting the importance of thorough end-to-end testing.</div>A session token merely establishes the identity of the requester but does not grant direct access to the Admin API. To acquire API access, the session token must be traded for an access token via OAuth 2.0 token exchange (RFC 8693), bypassing legacy authorization-code redirect flows entirely. With managed installations, this approach streamlines the installation sequence completely, eliminating dedicated /auth routes, redirection loops, and callback endpoints. The initial authenticated request from a newly installed shop triggers the exchange immediately.Webhooks operate independently of session tokens, relying instead on cryptographic signatures. Specifically, Shopify calculates an HMAC-SHA256 signature over the raw request body, base64-encoded within the X-Shopify-Hmac-Sha256 header. Raw data processing must occur prior to any JSON decoding or middleware interaction. Automated Shopify App Store reviews explicitly test this requirement by dispatching intentionally corrupted signatures, expecting a strict HTTP 401 response.Additional production requirements include scoped frame-ancestors Content Security Policies calculated per request using shop parameters, alongside critical App Bridge placement rules. App Bridge must load synchronously as the absolute first script inside the &lt;head&gt; tag directly from Shopify's CDN, prohibiting bundling, deferral, or asynchronous loading on embedded pages.Production environments can also reveal subtle framework quirks, such as Symfony translation issues where subject lines like digest.attachment : ' Attached: your restock list (%count% items).' unexpectedly truncated their initial words. Because %count% evaluates as a numeric value, Symfony routes the string through pluralization logic containing regular expressions matching explicit-interval syntax, treating introductory words followed by colons as rule definitions without throwing errors or generating logs. The primary takeaway involves avoiding colon-prefixed phrasing directly adjacent to count variables and ensuring test suites assert strings starting from their exact initial character.Source: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/mollenthiel/building-an-embedded-shopify-app-in-symfony-session-tokens-token-exchange-and-the-parts-nobody-438g" target="_blank" rel="noopener noreferrer">Dev.to</a>

medium_shopify-symfony-token-exchange-php-mscepz7l.jpg

small_shopify-symfony-token-exchange-php-mscepz7l.jpg

thumbnail_shopify-symfony-token-exchange-php-mscepz7l.jpg

shopify-symfony-token-exchange-php-mscepz7l.jpg

เจาะลึกวิธีการพัฒนาแอปพลิเคชัน Shopify แบบ Embedded บน Symfony 7.4 และ PHP 8.5 ตั้งแต่การจัดการ Session Token, Token Exchange ไปจนถึงส่วนที่เอกสารทางการไม่ค่อยพูดถึง

A deep dive into developing embedded Shopify applications using Symfony 7.4 and PHP 8.5, covering session tokens, token exchange, and undocumented PHP challenges.

Inewgen

Inewgen

#Symfony

สร้างแอป Shopify ฝังตัวด้วย Symfony: คู่มือเจาะลึกความปลอดภัยและ Token Exchange ใน PHP

Inewgen