การบังคับให้ Browser บันทึกไฟล์

ในบางครั้งที่เราทำลิ้งค์ไปยังไฟล์ใดๆ โดยเฉพาะไฟล์ที่เปิดใช้งานได้ด้วย browser เช่น ไฟล์เสียง และ ไฟล์วีดีโอ แต่ในบางกรณีก็มีข้อจำกัด เช่น server ของเราอาจจะไม่สามารถให้บริการไฟล์ได้อย่างต่อเนื่อง (streaming) หรือผู้ใช้บางรายใช้ browser ที่ไม่รองรับ format ของไฟล์บางชนิด เราจึงอาจจะต้องการให้ผู้ใช้บันทึกไฟล์ไว้ แทนที่จะเปิดดูในขณะนั้น

การจะใช้คำสั่ง JavaScript จัดการให้ browser บันทึกไฟล์อัตโนมัติ ก็จะทำไม่ได้ เนื่องจากจะติดปัญหาเรื่องความปลอดภัย เพราะหากเปิดช่องตรงนี้ไว้ จะทำให้เว็ปที่ไม่ปลอดภัยสามารถแอบปล่อยไวรัสไว้ในเครื่องของผู้ใช้งานได้ง่ายๆ

วิธีการที่ดีที่สุดคือการใช้ Content-Disposition ใน header ของ HTTP โปรโตคอล โดยวิธีการนี้ต้องอาศัยการเขียนโปรแกรมทางฝั่ง server เพื่อรองรับการตอบกลับแบบนี้ ซึ่งทำได้ทุกภาษาเช่น PHP, ASP.NET, Perl/CGI หรือ JSP เป็นต้น แต่ในกรณีทั่วไปที่เราใช้บริการฟรี server เราอาจจะไม่สามารถเขียนโปรแกรมใดๆได้ จึงอาจจะเป็นข้อจำกัดของวิธีการนี้

รูปแบบของ Content-Disposition

รูปแบบของ Content-Disposition สำหรับ HTTP ได้กำหนดไว้ใน RFC6266 (อ้างอิง 1) โดยสรุปคือ

Content-Disposition: <value> [; <param>]

โดยที่ <value> มีค่าเป็น (ไม่สนใจตัวอักษรใหญ่-เล็ก)

1. inline หมายถึง แสดงผลอัตโนมัติ โดยทั่วไปไม่ต้องระบุก็จะแสดงอัตโนมัติเป็นปกติ
2. attachment หมายถึง ผู้ใช้ควบคุมการแสดงผล

ซึ่งหมายความว่า หากต้องการบังคับให้ผู้ใช้บันทึกไฟล์ เราจะต้องกำหนด Content-Disposition มีค่าเป็น attachment นั่นเอง

ส่วน <param> มีค่าเป็น (ไม่สนใจตัวอักษรใหญ่-เล็ก)

1. filename = <name> หมายถึงชื่อไฟล์ <name>
2. filename* = <name> หมายถึงชื่อไฟล์ <name> ที่เข้ารหัสแบบที่ไม่ใช่ ISO-8859-1

หมายเหตุ: บาง borwser อาจจะไม่รองรับค่า filename* จึงควรจะส่งค่าทั้งสองแบบ

Content-Disposition: attachment;

                          filename="EURO rates";

                          filename*=utf-8''%e2%82%ac%20rates

ตัวอย่าง

ภาษา PHP

<?php
header('Content-disposition: attachment; filename=movie.mpg');
header('Content-type: video/mpeg');
?>

ภาษา JSP

<% //Set the headers.
response.setHeader("Content-Disposition", "attachment; filename=downloaded.pdf");
response.setContentType("application/x-download");
%>

อ้างอิง

1. IETF, RFC6266
2. W3, HTTP/1.1 Appendices
3. IANA, Content Disposition Values and Parameters

ทดลองติดตั้ง Team Foundation Server 2013

หลายปีมาแล้วที่ผมพยายามจะทดลองใช้ Team Foundation Server(TFS) ตั้งแต่สมัย Visual Studio 2008 แต่สุดท้ายก็เลิกใช้ เนื่องจากมันใช้ทรัพยากรค่อนข้างมาก ซึ่งตอนนั้นผมไม่ได้มี Windows Server ดูแลประจำอยู่ ก็เลยหันไปใช้ Subversion บน Ubuntu แทน และเนื่องจากตอนนั้นก็ต้องการเพียงแค่เรื่องของ Version Control เท่านั้นด้วย ก็เลยลงตัว แต่ผมก็ยังติดตามดูความสามารถของโปรแกรมตัวนี้อยู่เรื่อยๆ เพราะคิดว่าสักวันคงต้องได้ใช้มันแน่ๆ

ผ่านไปหลายปี หลังจากดูๆมานาน และหลายปีแล้วที่มหาวิทยาลัยสงขลานครินทร์ลงทุนซื้อลิขสิทธิ์ซอฟต์แวร์ของค่าย Microsoft ไว้ทุกๆปี ก็เลยคิดว่าน่าจะเอามาใช้ให้คุ้มค่า 2-3 วันมานี้ก็เลยได้เวลาทดลองติดตั้งดู ซึ่งผมได้ทดลองติดตั้งไว้ใน Virtual Machine โดยลืมไปว่ามันค่อนข้างใช้ทรัพยากรนะ ทีแรกผมกำหนด RAM ไว้เพียง 4GB พอเริ่มต้นติดตั้ง ก็ต้องหยุดเพื่อเพิ่ม RAM เข้าไปอีก จะใช้มากหรือน้อยก็อยู่ที่ว่าเราจะเลือกติดตั้งแบบใด ซึ่งมีอยู่ 3 แบบคือ

1. Basic สำหรับติดตั้งบนเครื่องระดับ Windows Client เช่น Windows 8.1 เป็นต้น โดยไม่จำเป็นต้องมี Microsoft SQL Server แต่มันจะติดตั้งรุ่น Express ให้ และจำกัดขนาดทีมได้ไม่เกิน 5 คน ซึ่งจะเทียบเท่ากับ Team Foundation Server Express ที่ Microsoft ให้ดาวโหลดใช้ได้ฟรี
2. Standard สำหรับติดตั้งบนเครื่องระดับ Windows Server เช่น Windows Server 2012 เป็นต้น โดยติดตั้งทุกอย่างอยู่บนเครื่องเดียว ซึ่งจะต้องมี Microsoft SQL Server อยู่ด้วย (ต้องการ RAM อย่างน้อย 8GB) และให้เลือกทำงานร่วมกับ SharePoint ได้ด้วย (ต้องการ RAM อย่างน้อย 10GB) ซึ่งผมเลือกที่จะไม่ลง SharePoint (ยังไม่อยากปวดหัว เอาไว้โอกาสหน้านะ)
3. Advance สำหรับติดตั้งบนเครื่องระดับ Windows Server โดยที่ SQL Server หรือ SharePoint  Server อยู่ที่เครื่องอื่น

สำหรับการติดตั้งแบบ Standard นั้น เราควรจะติดตั้ง SQL Server ให้เรียบร้อยเสียก่อน โดยจะต้องเลือกติดตั้ง Reporting Service ไว้ด้วย ซึ่งถ้าหากเราไม่ได้ใช้ SharePoint ก็จะต้องเลือกติดตั้ง Reporting Service แบบ Native Mode 

เมื่อเสร็จสิ้นการติดตั้ง เราจะสามารถเข้าถึง TFS ได้ที่ URL http://<servername>:8080/tfs

Eclipse Plug-In

ส่วนหนึ่งที่ผมตัดสินใจทดลองติดตั้ง TFS ดูอีกสักครั้ง ก็เพราะค้นพบว่ามี Eclipse Plug-In สำหรับใช้ทำงานร่วมกับ TFS อยู่ด้วย ซึ่งหากทีมพัฒนาซอฟต์แวร์ของเราใช้ IDE คนละตัวกัน โดยเฉพาะ IDE สองขั้วตรงกันข้ามอย่าง Visual Studio และ Eclipse แต่ถ้ายังสามารถทำงานร่วมกันในระบบเดียวได้ ก็จะทำให้การทำงานราบรื่นขึ้น

สำหรับการติดตั้ง Plug-In นี้ไม่ได้ยุ่งยากอะไรเลย เพียงแค่ Add Repository ของ Plug-In ไว้ โดยใส่ URL คือ http://dl.microsoft.com/eclipse/tfs ดังภาพ

จากนั้นก็เลือกติดตั้ง

เท่านี้ก็ติดตั้งได้เรียบร้อย

Netbeans Plug-In

สำหรับผู้ที่ใช้ Netbeans นั้น เท่าที่ผมค้นมา พบว่ามีการร้องขอให้ทาง Microsoft ทำ Plug-In ออกมาเหมือนกัน ตั้งแต่เมื่อปี 2010 แล้ว แต่ก็ไม่ได้รับการตอบสนอง และมีโครงการ NetBeans Plugin for Team Foundation Server ที่พัฒนามานานแล้วแต่ยังไม่เสร็จสักที สุดท้ายก็มีกระทู้ใน StackOverflow แนะนำให้เลี่ยงไปใช้วิธีอื่น เช่น ใช้ SVN Bridge เป็นต้น แต่ก็จะได้ความสามารถเพียงแค่เรื่องของ Version Control เท่านั้น

สรุป

สำหรับผู้ที่สนใจจะนำเอากระบวนการพัฒนาซอฟต์แวร์ตามหลักการมาใช้ในทีม เครื่องมืออย่าง Team Foundation Server นี้ก็เป็นสิ่งที่น่าสนใจไม่น้อย หากไม่มีงบเพียงพอที่จะซ์้อ สามารถใช้รุ่น Express ก็ได้ และเดี๋ยวนี้ทาง Microsoft ก็มีบริการแบบ Online ที่เรียกว่า Visual Studio Online ให้สามารถทำงานได้เช่นกัน

ประตูหลัง

ชื่อเรื่องอาจจะแปลกๆกึ่งๆออกจะติดเรดผู้ปกครองควรพิจารณาสักหน่อย แต่ก็คิดว่าเหมาะสมกับเรื่องที่อยากจะเขียนมาก เพราะควรพิจารณาจริงๆกับเรื่องนี้ เพราะเป็นเรื่องที่สำคัญมากๆ และมักจะมีคนชอบใช้ประตูหลังกันบ่อยๆ

ผมขอเข้าเรื่องเลยก็แล้วกัน ไม่อย่างนั้นจะคิดกันไปต่างๆนานา หาว่าผมเขียนอะไรที่ไม่สมควร ความจริงแล้วมันก็คือเรื่องความปลอดภัยของซอฟต์แวร์นี่แหละ โดยเฉพาะซอฟต์แวร์สำคัญๆ ที่ใช้งานในองค์กร เรามักจะต้องระวังเรื่องความปลอดภัยเป็นที่สุด แต่โดยทางทฤษฎีแล้ว ถ้าเราปิดประตูไว้ได้หมด ก็หมดเรื่อง ไม่ต้องกังวล และในทางปฏิบัติแล้ว ประตูหน้า ซึ่งมักจะจงใจสร้างขึ้นเป็นช่องทางเพียงช่องทางเดียวสำหรับเข้าออกระบบ ก็จะต้องได้รับการคิดวิเคราะห์เรื่องความปลอดภัยไว้เรียบร้อยแล้ว โดยประตูหน้า มักจะต้องจำกัดให้เฉพาะผู้ที่สามารถยืนยันตัวตนได้เท่านั้น ผ่านเข้าออกระบบได้ เสมือนมียามเฝ้าคอยตรวจบัตรผ่าน

ทีนี้ปัญหามันก็มีอยู่ว่า ช่องทางประตูหน้า มักมีข้อจำกัดหลายอย่าง จนทำให้เวลาเกิดปัญหาขึ้นในระบบ เช่น ไฟไหม้ การเข้าออกเพียงช่องทางประตูหน้าที่มีการตรวจสอบรัดกุมเพียงทางเดียวจึงไม่เพียงพอ ผู้ออกแบบระบบจึงมักจะทำทางออกฉุกเฉิน เช่น บันไดหนีไฟ และ ประตูหลังไว้ แต่จุดนี้ก็จะกลายเป็นช่องโหว่ของระบบ ทำให้เกิดความเสี่ยงเรื่องความปลอดภัยมากขึ้น อย่างในหนังจารกรรมหลายๆเรื่อง โจรก็มักจะใช้บันไดหนีไฟและประตูหลังเป็นช่องทางเข้า-ออกระบบ เพราะโดยปกติแล้ว จะเปิดทิ้งไว้ตลอด และไม่มีใครดูแล

ถ้าเป็นไปได้ เราก็ไม่ควรจะมีประตูหลังสินะ เหมือนตู้นิรภัย ที่ไม่มีประตูหลัง และผนังทุกด้านปิดผนึกแน่นหนา ไม่มีช่องแม้แต่จะให้อากาศเข้าไปได้ แต่นั่นเป็นอุดมคติและใช้ได้เฉพาะกรณีอย่างตู้นิรภัยสำหรับเก็บสิ่งของมีค่าเท่านั้น หากจะให้คนเข้าไปอยู่ก็คงจะไม่ได้ ดังนั้น ตึกหรืออาคารต่างๆ จึงออกแบบให้ต้องมีประตุหลัง เพื่อให้มีความปลอดภัยและใช้งานได้จริงในทางปฏิบัติ

ในทำนองเดียวกัน ระบบซอฟต์แวร์หลายๆระบบ จึงมีประตูหลัง เพราะผู้ใช้งานต้องการความสะดวก และต้องการช่องทางพิเศษในการจัดการกับปัญหาบางปัญหาที่พิเศษจริงๆ แต่นั่นก็ต้องแลกมากับความไม่ปลอดภัยและช่องโหว่ต่างๆ ในทางปฏิบัติ หลายๆที่จึงต้องมียามเฝ้าประตูหลังไว้ด้วย หากไม่มียามเฝ้า ประตูหลังก็ควรจะเป็นประตูที่ออกแบบมาให้เปิดได้จากข้างในเท่านั้น จะเปิดจากด้านนอกไม่ได้