Zellij ซึ่งเป็นเครื่องมือจัดการพื้นที่ทำงานเทอร์มินัลและ multiplexer ที่ได้รับความนิยม เพิ่งเปิดตัวฟีเจอร์ web client ที่ช่วยให้ผู้ใช้สามารถเข้าถึงเซสชันเทอร์มินัลผ่านเว็บเบราว์เซอร์ได้ แม้ว่านวัตกรรมนี้จะนำมาซึ่งความสะดวกสบายและความเป็นไปได้ใหม่ๆ แต่ก็ได้จุดประกายการอฟสุษในชุมชนนักพัฒนาเกี่ยวกับผลกระทบด้านความปลอดภัยและการขยายพื้นผิวการโจมตี
web client ช่วยให้ผู้ใช้สามารถบุ๊กมาร์กเซสชันเทอร์มินัลด้วย URL ทำให้สามารถแชร์เซสชันหรือเข้าถึงสภาพแวดล้อมการพัฒนาเฉพาะได้อย่างรวดเร็ว อย่างไรก็ตาม ความสะดวกสบายนี้มาพร้อมกับการแลกเปลี่ยนที่ทำให้ชุมชนแบ่งออกเป็นสองฝ่าย
เทคโนโลยีที่ใช้ใน Web Client ของ Zellij
| คอมโพเนนต์ | เทคโนโลยี | วัตถุประสงค์ |
|---|---|---|
| Web Server | Axum (Rust) | จัดการ HTTP/WebSocket |
| TLS | rustTLS | การเข้ารหัส HTTPS |
| Client Terminal | xterm.js | จำลองเทอร์มินัลในเบราว์เซอร์ |
| Authentication | Token-based กับ SQLite | ควบคุมการเข้าถึงของผู้ใช้ |
| Communication | ช่องทาง WebSocket คู่ | แยกข้อมูลเทอร์มินัลและการควบคุม |
| Static Assets | include_dir macro | รวมไว้กับไฟล์ปฏิบัติการ |
 |
|---|
| web client ของ Zellij : ฟีเจอร์ใหม่ที่ช่วยให้ผู้ใช้เข้าถึง terminal sessions ผ่านเบราว์เซอร์ของตน |
ความกังวลด้านความปลอดภัยขึ้นเป็นประเด็นหลัก
การอภิปรายที่เข้มข้นที่สุดหมุนรอบผลกระทบด้านความปลอดภัยของการขยายการเข้าถึงเทอร์มินัลเกินขอบเขตดั้งเดิม สมาชิกในชุมชนได้แสดงความไม่สบายใจเกี่ยวกับการขยายการเปิดรับของเดสก์ท็อปและเซิร์ฟเวอร์ผ่านการเข้าถึงเทอร์มินัลแบบเว็บ ความกังวลนี้เกิดจากหลักการพื้นฐานที่ว่า terminal multiplexer ควรรักษาการเปิดรับเครือข่ายให้น้อยที่สุด
อย่างแน่นอนมาก โปรเจกต์นี้ยังรวมถึงการปล่อย binary แยกต่างหากที่มีฟีเจอร์นี้ถูก compile ออกไปทั้งหมด แต่ผมอยากให้ฟีเจอร์แบบนี้ไม่เคยถูกคิดขึ้นหรือดำเนินการตั้งแต่แรกเลย
ความกังวลเหล่านี้ไม่ใช่เรื่องไร้เหตุผล เทอร์มินัลให้การเข้าถึงทรัพยากรระบบที่อ่อนไหว และอินเทอร์เฟซแบบเว็บใดๆ ย่อมเพิ่มพื้นผิวการโจมตีโดยธรรมชาติ แม้ว่า Zellij จะได้นำมาตรการยืนยันตัวตนมาใช้ รวมถึงความปลอดภัยแบบ token-based และการบังคับใช้ HTTPS แต่นักพัฒนาบางคนยังคงสงสัยเกี่ยวกับความจำเป็นของฟีเจอร์ดังกล่าวในซอฟต์แวร์เทอร์มินัล
คุณสมบัติด้านความปลอดภัย
- การยืนยันตัวตนแบบ token ที่สร้างขึ้นจากภายใน Zellij sessions
- Token ที่ผ่านการ hash เก็บไว้ในฐานข้อมูล SQLite ในเครื่อง (ไม่เคยเก็บในรูปแบบข้อความธรรมดา)
- คุกกี้แบบ HTTP-only สำหรับ session tokens
- การบังคับใช้ HTTPS สำหรับอินเทอร์เฟซภายนอก
- อนุญาต HTTP เฉพาะบน localhost เท่านั้น
- Session tokens ชั่วคราวที่แลกเปลี่ยนระหว่างการ handshake
ความท้าทายในการบูรณาการและวิธีแก้ปัญหา
นอกเหนือจากความปลอดภัยแล้ว นักพัฒนายังกำลังอภิปรายความท้าทายในการใช้งานจริง ผู้ใช้บางคนต้องเผชิญกับข้อจำกัดขององค์กร เช่น websocket ที่ถูกบล็อก ซึ่งป้องกันไม่ให้พวกเขาใช้ฟีเจอร์ web client ได้ คนอื่นๆ กำลังสำรวจความเป็นไปได้ในการบูรณาการกับเครื่องมือและโปรโตคอลที่มีอยู่
ชุมชนได้แสดงความสนใจในความเข้ากันได้ที่กว้างขึ่น โดยเฉพาะกับโปรโตคอลที่มีอยู่แล้วเช่น tmux control mode ซึ่งช่วยให้ terminal emulator สามารถแสดงแท็บ multiplexer เป็นแท็บดั้งเดิมได้ สิ่งนี้แสดงให้เห็นความปรารถนาสำหรับการมาตรฐานมากกว่าโซลูชันที่เป็นกรรมสิทธิ์
การตัดสินใจด้านสถาปัตยกรรมทางเทคนิค
ตัวเลือกทางเทคนิคของ Zellij ยังได้รับความสนใจเช่นกัน ทีมงานเลือกใช้แนวทาง dual-websocket ที่มีช่องทางเทอร์มินัลและควบคุมแยกกันเพื่อป้องกันการบล็อกและปรับปรุงประสิทธิภาพ พวกเขาเลือกใช้เทคโนโลยีที่ใช้ Rust รวมถึง Axum สำหรับเว็บเซิร์ฟเวอร์และ xterm.js สำหรับการจำลองเทอร์มินัลในเบราว์เซอร์
น่าสนใจที่ทีมงานตัดสินใจไม่ใช้ TypeScript แม้ว่าจะมาจากพื้นฐาน strongly-typed โดยอ้างถึงความกังวลเรื่องความซับซ้อนของการ build สำหรับโค้ดฝั่งไคลเอนต์ที่ค่อนข้างเล็ก การตัดสินใจนี้สะท้อนแนวทางปฏิบัติในการสร้างสมดุลระหว่างความซับซ้อนในการพัฒนากับประโยชน์ของความปลอดภัยของประเภทข้อมูล
web client แสดงถึงก้าวสำคัญในการทำให้เซสชันเทอร์มินัลเข้าถึงได้และแชร์ได้มากขึ้น อย่างไรก็ตาม การตอบสนองของชุมชนเน้นย้ำถึงความตึงเครียดที่ดำเนินต่อไประหว่างนวัตกรรมและความปลอดภัยในเครื่องมือนักพัฒนา เมื่อการพัฒนาระยะไกลกลายเป็นเรื่องธรรมดามากขึ้น การอภิปรายเหล่านี้มีแนวโน้มที่จะกำหนดรูปแบบการพัฒนาของ terminal multiplexer เพื่อตอบสนองความต้องการของเวิร์กโฟลว์สมัยใหม่ในขณะที่รักษามาตรฐานความปลอดภัย
อ้างอิง: Terminal sessions you can bookmark: Building Zellij's web client