EmDash – ผู้สืบทอดทางจิตวิญญาณของ WordPress ที่แก้ปัญหาความปลอดภัยของปลั๊กอิน
(blog.cloudflare.com)- EmDash ที่พัฒนาโดย Cloudflare คือ โอเพนซอร์ส CMS ที่ออกแบบใหม่ด้วย TypeScript และสถาปัตยกรรมเซิร์ฟเวอร์เลส เพื่อก้าวข้ามข้อจำกัดเชิงโครงสร้างของ WordPress
- รัน ปลั๊กอินแต่ละตัวในสภาพแวดล้อม sandbox แบบแยกออกจากกัน จึงปิดกั้น ช่องโหว่ของปลั๊กอิน ซึ่งเป็นต้นตอของปัญหาความปลอดภัยของเว็บไซต์ WordPress ถึง 96% ได้ตั้งแต่ระดับโครงสร้าง
- มี มาตรฐานการชำระเงิน x402 ในตัว รองรับ การจ่ายเงินตามการใช้งาน (pay-per-use) ระดับคอนเทนต์ และมอบโครงสร้างการสร้างรายได้ที่เหมาะกับยุคเว็บทราฟฟิกที่ขับเคลื่อนด้วย AI
- ด้วย โครงสร้างเซิร์ฟเวอร์เลสบน Cloudflare Workers ระบบจึงขยายและหดตัวอัตโนมัติตามคำขอ ช่วยให้ได้ทั้ง การลดต้นทุนและประสิทธิภาพสูง พร้อมกัน
- ผสานฟีเจอร์สมัยใหม่อย่าง การจัดการ AI agent, การยืนยันตัวตนด้วย Passkey, โครงสร้างธีมแบบ Astro ฯลฯ ทำให้เป็น CMS ที่สืบทอดจิตวิญญาณของ WordPress แต่ถูกสร้างใหม่ทั้งหมด
ภาพรวมของ EmDash
- EmDash คือ โอเพนซอร์ส CMS ที่ออกแบบใหม่เพื่อแก้ข้อจำกัดเชิงโครงสร้างของ WordPress โดยเลือกใช้ TypeScript แบบเต็มรูปแบบ และ สถาปัตยกรรมเซิร์ฟเวอร์เลส
- เข้ากันได้กับความสามารถหลักของ WordPress แต่ไม่ได้ใช้โค้ดเดิม จึงสามารถเผยแพร่ภายใต้ MIT License ได้
- ใช้ Dynamic Worker ของ Cloudflare Workers เพื่อรันปลั๊กอินแต่ละตัวใน สภาพแวดล้อมแบบแยก (isolate) อย่างอิสระ
- สร้างบน เฟรมเวิร์ก Astro เพื่อมอบประสิทธิภาพที่เหมาะกับเว็บไซต์ที่เน้นคอนเทนต์เป็นหลัก
- EmDash เปิดเผยบน GitHub และสามารถ deploy ได้โดยตรงทั้งบน บัญชี Cloudflare หรือ เซิร์ฟเวอร์ Node.js
- ปรับปรุงปัญหาที่ WordPress แก้ไม่ได้ในระดับรากฐาน เช่น ความปลอดภัยของปลั๊กอิน, การลดการผูกติดกับตลาด, การจัดการด้วย AI, และ การรองรับการชำระเงิน x402
ความสำเร็จและข้อจำกัดของ WordPress
- WordPress ขับเคลื่อนอินเทอร์เน็ตมากกว่า 40% และเป็นกรณีศึกษาความสำเร็จของโอเพนซอร์สที่เป็นตัวแทนของ การทำให้การเผยแพร่เข้าถึงได้อย่างเป็นประชาธิปไตย
- แต่หลังผ่านไป 24 ปี สภาพแวดล้อมโฮสติ้งและกระบวนทัศน์การพัฒนา ได้เปลี่ยนไปอย่างมาก
- ในยุคแรกต้องเช่า VPS แต่ปัจจุบันสามารถ deploy ได้เพียงอัปโหลด JavaScript bundle ไปยังเครือข่ายแบบกระจายทั่วโลก
- EmDash สืบทอดจิตวิญญาณของ WordPress แต่ถูกสร้างขึ้นใหม่ให้สอดคล้องกับ โครงสร้างพื้นฐานเว็บสมัยใหม่และข้อกำหนดด้านความปลอดภัย
การแก้ปัญหาความปลอดภัยของปลั๊กอิน WordPress
- ปัญหาความปลอดภัย 96% ของเว็บไซต์ WordPress มาจากปลั๊กอิน
- ปลั๊กอินเป็นสคริปต์ PHP ที่เข้าถึงฐานข้อมูลและไฟล์ระบบได้โดยตรง
- เมื่อติดตั้งแล้วมักได้รับสิทธิ์แทบทั้งหมด โดยไม่มีการแยกหรือจำกัดสิทธิ์
- EmDash รันปลั๊กอินแต่ละตัวใน สภาพแวดล้อม sandbox บน Dynamic Worker
- ปลั๊กอินจะร้องขอเฉพาะ capabilities ที่จำเป็นผ่าน การประกาศแบบชัดเจน (manifest)
- ตัวอย่างเช่น
read:content,email:sendจะได้รับเฉพาะสิทธิ์ที่ต้องใช้เท่านั้น - การเข้าถึงเครือข่ายก็ถูกจำกัดเฉพาะโฮสต์ที่ระบุไว้
- ก่อนติดตั้งสามารถตรวจสอบสิทธิ์ที่ปลั๊กอินร้องขอได้อย่างชัดเจน จึงให้ โครงสร้างการอนุญาตสิทธิ์ที่โปร่งใสคล้าย OAuth
- ผู้ดูแลระบบยังสามารถทำ นโยบายการติดตั้งแบบอัตโนมัติ โดยอิงจากเกณฑ์การร้องขอสิทธิ์ได้
ความปลอดภัยของปลั๊กอินและการลดการผูกติดกับมาร์เก็ตเพลส
- WordPress.org มี กระบวนการตรวจสอบแบบแมนนวล เนื่องจากปัญหาความปลอดภัยของปลั๊กอิน และมีคิวรอมากกว่า 800 รายการ
- ข้อจำกัดของไลเซนส์ GPL ทำให้ การนำโค้ดกลับมาใช้ซ้ำและการทำเชิงพาณิชย์ถูกจำกัด
- EmDash ลด การผูกติดกับตลาด (lock-in) ผ่านการปรับปรุงเชิงโครงสร้าง 2 ประการ
- ทำให้ไลเซนส์ของปลั๊กอินมีอิสระมากขึ้น: เนื่องจากไม่ได้แชร์โค้ดกับ EmDash นักพัฒนาจึงเลือกไลเซนส์ที่ต้องการได้
- รันใน security sandbox: เว็บไซต์สามารถเชื่อถือปลั๊กอินได้โดยไม่จำเป็นต้องมองเห็นโค้ดปลั๊กอินโดยตรง
- เพราะปลั๊กอินทำได้เฉพาะ capability ที่ประกาศไว้ จึงสามารถ ประเมินความเสี่ยงด้านความปลอดภัยได้อย่างละเอียด
- โครงสร้างนี้นำไปสู่ การพึ่งพา centralized marketplace ที่ลดลง
- เมื่อมีโมเดลความปลอดภัยที่เชื่อถือได้แล้ว ทั้งนักพัฒนาและผู้ใช้ก็สามารถ ขยาย ecosystem ได้อย่างอิสระ
มีมาตรฐานการชำระเงิน x402 ในตัว — ทำคอนเทนต์แบบเสียเงินเข้าถึงได้
- EmDash รองรับ มาตรฐาน x402 โดยค่าเริ่มต้น ทำให้รองรับ การจ่ายเงินแบบ on-demand ผ่านการตอบกลับ HTTP 402 Payment Required
- ผู้ใช้สามารถ จ่ายตามคอนเทนต์แต่ละชิ้น (pay-per-use) ได้โดยไม่ต้องสมัครสมาชิก
- ผู้ดูแลเว็บไซต์สามารถ สร้างรายได้ได้เพียงตั้งค่าที่อยู่กระเป๋าเงินและราคา
- นี่คือโมเดลธุรกิจใหม่ที่ออกแบบมาสำหรับ ยุคเว็บทราฟฟิกที่ขับเคลื่อนด้วย AI agent
- ทุกเว็บไซต์ EmDash จึงมี โครงสร้างการสร้างรายได้ในตัวที่เหมาะกับยุค AI
การขยายตัวและการลดต้นทุนบนพื้นฐานเซิร์ฟเวอร์เลส
- WordPress ต้องมีการ provision เซิร์ฟเวอร์ จึงเกิด ต้นทุนจากทรัพยากรที่ว่างอยู่
- EmDash ใช้ สถาปัตยกรรม v8 isolate บนพื้นฐาน Cloudflare workerd
- สร้างอินสแตนซ์ได้ทันทีเมื่อมีคำขอ และหากไม่มีคำขอก็ scale-to-zero อัตโนมัติ
- คิดค่าบริการตามเวลาใช้งาน CPU เท่านั้น
- ผ่าน Cloudflare for Platforms จึงสามารถ ขยายอัตโนมัติไปได้ถึงหลายล้านอินสแตนซ์
- โครงสร้างต้นทุนต่ำและประสิทธิภาพสูงนี้เหมาะทั้งกับ การรองรับทราฟฟิกขนาดใหญ่และการให้บริการฟรี tier
โครงสร้างธีมสมัยใหม่บนพื้นฐาน Astro
- ธีมของ EmDash ถูกจัดเป็น โปรเจกต์ Astro และประกอบด้วยองค์ประกอบต่อไปนี้
- Pages: route สำหรับเรนเดอร์คอนเทนต์
- Layouts: โครงสร้าง HTML ร่วม
- Components: องค์ประกอบ UI ที่นำกลับมาใช้ซ้ำได้
- Styles: การตั้งค่า CSS หรือ Tailwind
- ไฟล์ Seed: นิยามประเภทคอนเทนต์ที่ CMS จะสร้าง
- Astro เป็น เฟรมเวิร์กยอดนิยมที่อยู่ในข้อมูลฝึกของ LLM จึงเป็นมิตรกับนักพัฒนา
- ต่างจากโครงสร้างธีมของ WordPress ที่อิง
functions.phpธีมของ EmDash ไม่สามารถเข้าถึงฐานข้อมูลได้ จึงปลอดภัยกว่า
AI-native CMS — MCP, CLI, Agent Skills
- EmDash ถูกออกแบบให้เป็น CMS ที่ AI agent จัดการได้โดยตรง
- ช่วยทำงานซ้ำ ๆ อย่างการย้ายคอนเทนต์หรือการแปลงฟิลด์ให้เป็นอัตโนมัติ
-
Agent Skills
- อินสแตนซ์ของ EmDash มี Agent Skills ในตัว เพื่อให้ AI เข้าใจโครงสร้างปลั๊กอิน, hook, วิธีพอร์ตธีม ฯลฯ
- AI จึงสามารถเข้าใจ codebase ของ EmDash และทำ การปรับแต่งอัตโนมัติ ได้
-
EmDash CLI
- ผ่าน CLI สามารถทำงานจัดการอย่าง ค้นหาคอนเทนต์, อัปโหลดมีเดีย, สร้างสคีมา ฯลฯ
- ควบคุมได้ทั้งอินสแตนซ์แบบ local และ remote
-
MCP server ในตัว
- แต่ละอินสแตนซ์มี Model Context Protocol server ของตัวเอง
- สามารถทำงานทั้งหมดที่ทำได้ใน UI ผู้ดูแลผ่านทางรีโมตได้
การยืนยันตัวตนด้วย Passkey และการจัดการบทบาท
- EmDash ใช้ การยืนยันตัวตนด้วย Passkey เป็นค่าเริ่มต้น
- ป้องกันการรั่วไหลของรหัสผ่านและการโจมตีแบบ brute force
- รองรับ การควบคุมการเข้าถึงตามบทบาท (RBAC) โดยพื้นฐาน
- แยกสิทธิ์ตามบทบาท เช่น ผู้ดูแล, บรรณาธิการ, ผู้เขียน, ผู้ร่วมเขียน
- ระบบยืนยันตัวตนสามารถ ขยายได้ผ่านปลั๊กอิน และรองรับการเชื่อมต่อ SSO กับเมทาดาทาของ IdP
การย้ายเว็บไซต์ WordPress
- เว็บไซต์ WordPress เดิมสามารถย้ายมาได้ผ่าน การส่งออกไฟล์ WXR หรือ ปลั๊กอิน EmDash Exporter
- ปลั๊กอิน Exporter จะสร้าง endpoint เฉพาะที่ป้องกันด้วย WordPress Application Password
- ย้ายทั้งคอนเทนต์และมีเดียไปยังไลบรารีของ EmDash โดยอัตโนมัติ
- EmDash รองรับ โครงสร้างคอนเทนต์แบบอิงสคีมา
- แปลง Custom Post Type ของ WordPress เป็น คอลเลกชันอิสระ ของ EmDash
- ผ่าน Block Kit Agent Skill ยังสามารถสร้างบล็อกแบบกำหนดเองด้วย AI ได้
ทดลองใช้และมีส่วนร่วม
- ตอนนี้ EmDash อยู่ในสถานะ v0.1.0 preview และ ดาวน์โหลดได้จาก GitHub repository
- สามารถลองใช้งาน UI ผู้ดูแลได้โดยตรงที่ EmDash Playground
- คำสั่งติดตั้งแบบ local:
npm create emdash@latest - สามารถ deploy ได้จากแดชบอร์ด Cloudflare เช่นกัน
- ยินดีรับ feedback และการมีส่วนร่วม จากชุมชน WordPress, แพลตฟอร์มโฮสติ้ง, และนักพัฒนาปลั๊กอิน/ธีม
6 ความคิดเห็น
ผมเป็นคนที่เคยใช้ WordPress กับบล็อกส่วนตัว แล้วสุดท้ายก็ทิ้งมันไปย้ายเป็นสแตติกเพราะปัญหาความปลอดภัยนั้นเลยครับ
ผมปล่อยบล็อกส่วนตัวทิ้งไว้เฉย ๆ อยู่พักหนึ่ง แล้วสแปมแปลก ๆ ก็บุกเข้ามาจริง ๆ จนทำให้บล็อกกลายเป็นแหล่งสแปมไปเลย พวกมันใช้วิธีประหลาดด้วยการอาศัยแท็กไปลงทะเบียนหน้าเว็บที่ไม่มีอยู่ในเครื่องโลคัลของผมกับ Google ครับ ตอนนี้ก็ยังลบจนเหนื่อยอยู่เลย เศร้าจัง
ผมเองก็จำได้ว่าเคยงงเหมือนกันตอนที่มี URL แปลก ๆ ถูกจับในเครื่องมือเว็บมาสเตอร์
"วิธีแปลก ๆ ที่ใช้แท็กเพื่อไปลงทะเบียนหน้าที่ไม่มีอยู่ในเครื่องโลคัลของผมกับ Google" นี่มันเป็นวิธีแบบไหนกันเหรอครับ??
มีวิธีบล็อกสิ่งนี้ไหมครับ?
ยังมีสแปมแบบที่เอา URL หน้าผลการค้นหาจากการค้นหาวลีสแปมไปใส่เป็นแบ็กลิงก์ในโพสต์ของบล็อกอื่นด้วย;
ไม่ว่าแบบไหน สุดท้ายก็ต้องลบด้วยมือนั่นแหละ...
โดยปกติแล้ว วิธีการเจาะระบบคืออาศัยปลั๊กอิน/ธีมที่มีช่องโหว่เกี่ยวกับการอัปโหลดไฟล์ เป็นต้น
พอเข้ามาได้แบบนี้ ก็จะฝังเนื้อหาไว้ใน tag/category เป็นต้น โดยที่เจ้าของบล็อกตัวจริงไม่รู้ตัว
ในความเป็นจริงมันจะไม่แสดงบนหน้าบล็อกเลย เลยทำให้ไม่รู้ แต่จะใช้วิธีเรนเดอร์ให้ URL นี้มองเห็นได้เฉพาะกับ Google bot เท่านั้น (อย่าง BabaYaga ก็เป็นแบบนั้น)
พอถูกเจาะเข้ามาแบบนี้แล้ว ในทางปฏิบัติก็แทบไม่มีวิธีอื่นนอกจากทำให้ทุกการเข้ามาที่ที่อยู่ดังกล่าวไปเป็น 410 Gone ทั้งหมด ที่เซิร์ฟเวอร์ก็ตั้งให้ที่อยู่ที่ไม่จำเป็นทั้งหมดแสดงเป็น 410 และต้องไปขอใน Search Console แบบแมนนวลให้ลบรูปแบบการเข้ามาบางอย่างออกเป็นเวลา 6 เดือน ตัวอย่างเช่นต้องลบทุกอย่างที่ขึ้นต้นด้วย /tag ออก
ผมยื่นคำขอลบมา 1 เดือนแล้ว แต่ตอนนี้ก็ยังลบออกไม่หมดเลย ต้องรอให้ Google indexing ทำงานให้เรียบร้อย ซึ่งใช้เวลานานมากครับ.
อ๋อ อย่างนั้นเอง ขอบคุณที่บอกนะครับ/ค่ะ ดูท่าจะต้องใส่ใจหลายเรื่องเลย
ความเห็นจาก Hacker News
ผมทำงานกับ WordPress มานานกว่าสิบปีแล้ว และคิดว่าโปรเจกต์นี้จับสองเรื่องได้ลงตัวมาก คือ TypeScript และ Worker plugins
ช่วงหลังผมคิดเรื่องปัญหาความปลอดภัยของ WP เยอะมาก เพราะปลั๊กอินไม่พึงประสงค์อาจเข้าถึง DB หรือตัวแปรสภาพแวดล้อม หรือก่อให้เกิด XSS ได้ แต่ถ้าระบบปลั๊กอินออกแบบมาดี ก็สามารถลดความเสี่ยงนี้ได้
ส่วนตัวตอนนี้กำลังพัฒนา HotsauceCMS อยู่ โดยเลือกใช้ปลั๊กอินแบบ NodeJS หรือ Deno Worker ได้ ทำให้ปลั๊กอิน first-party รันแบบ in-process เพื่อความเร็ว ส่วน third-party แยกไปรันใน worker ได้
มี dependency แค่ 4 ตัวและไม่มี transitive dependency เลย เพราะผมเบื่อทั้ง Dependabot alerts และ npm supply-chain attacks
โครงสร้างเป็น schema-first บน Drizzle ทำให้ควบคุมโครงสร้าง DB ได้ทั้งหมด และกำหนดฟีเจอร์อย่างการอัปโหลดไฟล์ผ่าน schema hints ได้
ไม่ยึดติดกับ DB ตัวใดตัวหนึ่ง จึงทำงานได้กับทุก DB ที่ Drizzle รองรับ เช่น Postgres, MySQL, SQLite
ฝั่งฟรอนต์เอนด์เลือกได้อิสระ และส่วนตัวผมชอบ JSX ที่ไม่มี React
ยินดีรับฟีดแบ็ก อยากรู้ว่าผมพลาดอะไรไปไหม และทิศทางนี้ถูกต้องหรือเปล่า รวมถึงตั้งตารอดูการพัฒนาต่อไปของ EmDash ด้วย
เขาบอกว่า EmDash เป็นผู้สืบทอดทางจิตวิญญาณของ WordPress แต่ผมคิดว่าทิศทางที่ CMS ควรไปนั้นตรงกันข้ามเลย
น่าจะต้องทำให้ง่ายขึ้นและกลับไปเป็น เว็บไซต์ที่ใช้ไฟล์สแตติก มากกว่า แคชง่าย เร็ว และดูแลง่าย
แน่นอนว่าในมุมของ Cloudflare ดูเหมือนจะเลือกโครงสร้างนี้เพื่อขาย Workers product ของตัวเองมากกว่า ส่วนจะช่วยแก้ปัญหาความปลอดภัยระดับรากฐานได้จริงไหม ผมยังสงสัยอยู่
ผมคิดว่า Cloudflare กำลังเข้าหาจากทิศทางที่ผิด
เหตุผลที่ WordPress ประสบความสำเร็จคือ ติดตั้งง่าย และมี network effect ไม่ใช่เพราะความปลอดภัย แต่เพราะมีนักพัฒนาที่คุ้นกับ WP อยู่แล้วจำนวนมาก
ถ้า EmDash จะสำเร็จ มันต้อง ง่ายกว่า เร็วกว่า และยืดหยุ่นกว่า Wix หรือ Squarespace ไม่อย่างนั้นก็ยากจะสร้าง network effect ได้
ในฐานะนักพัฒนา WordPress ความเจ็บปวดที่สุดของผมคือ สถาปัตยกรรมปลั๊กอิน
WP เอาปลั๊กอินไปไว้ในโฟลเดอร์
wp-contentแบบเดียวกับรูปภาพ ทำให้ CI/CD กลายเป็นฝันร้าย ส่วน EmDash ใช้ปลั๊กอินเป็น TS modules เลยดูสะอาดกว่ามากแนวคิดเรื่อง มาตรฐานการชำระเงิน x402 ของ Cloudflare น่าสนใจดี
มันเป็นโครงสร้างที่ให้เอเจนต์ส่ง micropayment โดยอัตโนมัติเพื่อแลกสิทธิ์เข้าถึงเนื้อหา ฟังดูน่ากลัวนิด ๆ แต่ก็ล้ำอนาคตดี
พูดเล่น ๆ ว่าถ้าสร้าง HTTP 402 honeypot ที่เก็บ 10 เซ็นต์ทุกครั้งที่เข้าชม มันอาจเป็นการกลับมาของไอเดีย “1 พิกเซล 1 ดอลลาร์” เวอร์ชันใหม่ก็ได้
คุณค่าของ WordPress ไม่ได้อยู่ที่โค้ด แต่อยู่ที่ ecosystem และระบบสนับสนุน
คุณภาพโค้ดอาจไม่ดีนัก แต่ SaaS แทบทุกเจ้ามีตัวเชื่อมต่อกับ WP
ถ้า EmDash จะสำเร็จ คนที่ไม่ใช่นักพัฒนาต้องสามารถไปจ้างคนบน Fiverr ให้มาคัสตอมให้ได้ง่าย ๆ เรื่องนี้ไม่ใช่ปัญหาเชิงเทคนิค แต่เป็น ปัญหาของตลาดแรงงาน
การที่มันเป็น WordPress เวอร์ชันสืบทอดจาก Cloudflare ก็น่าสนใจ แต่การแยกปลั๊กอินบนพื้นฐาน Dynamic Workers นั้นใช้งานได้เฉพาะบน Cloudflare runtime เท่านั้น
บนโฮสต์อื่นมันก็เป็นแค่ TS CMS ธรรมดา ดังนั้น การผูกกับสถาปัตยกรรมเฉพาะ จึงเป็นปัญหา
ผมสงสัยว่าทำไมโปรเจกต์ AI ถึงยังทำด้วย JavaScript อยู่
เดี๋ยวนี้ใช้ภาษาแบบ คอมไพล์ อย่าง Go ก็ทำแอปได้เร็วเหมือนกัน ทั้งเล็กกว่า เร็วกว่า และ deploy ง่ายกว่า
JS เป็นภาษาแบบ interpreted เลยช้าและซับซ้อน ในอดีตข้อดีคือรันทันทีได้ แต่ตอนนี้การคอมไพล์ก็เร็วแล้ว
น่าสนใจที่ EmDash ไม่ได้ใช้โค้ดของ WordPress เลย จึงแจกจ่ายภายใต้ MIT license ได้
แต่มันก็ทำให้นึกถึง Malus ซึ่งเป็น Cleanroom as a Service ที่เพิ่งโผล่มาเหมือนกัน จังหวะเวลาเลยดูบังเอิญแปลก ๆ