คลังเก็บรายเดือน: ตุลาคม 2012

Datepicker ใน JQuery UI สำหรับปีไทย

เขียนบน โดย
ตอบกลับ

วันนี้อยู่ๆ นึกครึ้มเลยอัพโปรเจ็คใน Github ที่อยู่มาข้ามปี ซึ่งตัวหนึ่งในนั้นที่ยังไงอนาคตคงได้ใช้คือ Datepicker ของ JQuery UI ที่ทำให้รองรับปี พ.ศ. !!!

มันเป็นอะไรที่เมื่อช่วง 10 เดือนที่แล้ว ผมมานั่งปวดหัว เพราะการเก็บลงฐานข้อมูลเป็น ค.ศ. ผมไม่เกี่ยงมันหรอก แต่ผู้ใช้งานมักชินกับ พ.ศ. มากกว่า พอเวลามีการเพิ่มข้อมูลลงไป มันก็กลายเป็น record จากอนาคตในอีก 543 ปีข้างหน้าไปซะงั้น

แล้วพอผมค้น Google ก็พบว่ามีคนทำแล้ว นั้นคือจากเว็บนี้ (ณ ช่วงเวลาที่ผมเขียนบล็อก เว็บของเขานั้นเขาไม่ได้ ผมจึงไม่ทราบว่ามีการอัพเดตอะไรไหม) ตอนนั้นผมรู้สึกขอบคุณเขาจริงๆ ที่ทำของดีๆ มาให้ แต่ช่วงนั้นเท่าที่ผมจำได้คือผมจำเป็นต้องใช้กับรุ่น 1.8.16 + effect แต่เขากลับมี 1.8.10 แค่ datepicker เพรียวๆ ผมจึงทำเวอร์ชั่น 1.8.16 โดยอาศัยการตรวจสอบร่องรอยการแก้ไขใน JQuery UI แทน ซึ่งใครเคยเปิดอ่านโค้ดจะทราบว่ามันโดน minify เอาไว้ จึงเป็นเรื่องปวดกระบาลยิ่ง แต่ก็รอดมาจนได้

หลังจากนั้นมาจนวันนี้ผมก็ลืมไปซะสนิท (ไม่มีงานให้ใช้) ผมก็เลยเอากลับมาลองๆ ดูแล้วทำเวอร์ชั่นล่าสุดลงไปเพิ่มแทน เป็น 1.8.24 กับ 1.9.1 ดังนั้นเชิญไปเสพได้ Github

ถ้าชอบใจโหลดไปอย่าลืมกด Watch เพราะเวลามีอัพเดตมันจะแจ้งเตือนไปหาคุณ ส่วนใครกด Star ก็จะดีใจมากเลยครับ

/love

Dark theme for Laravel Docs

เขียนบน โดย
ตอบกลับ

This post is short bacause it’s about my css modified that for my need. I found laravel put laraverl’s docs inside package and I can view this via route name “docs”. I want to modified to dark theme for my eye can read easier. If you want same as me, you can do follow these steps.

  1. open http://paste.laravel.com/8Rs
  2. copy and replace all code inside /public/laravel/css/style.css
  3. go to your laravel public folder via webbrowser with “docs” route such as “http://localhost/my_project/public/docs/” and see!

I hope you like it.  /ee

EDIT: New css – fix bg color of “.content table th”

งานวิจัยเผย SSL มีความเสี่ยงต่อการแฮกเมื่อไม่ได้ใช้งานผ่านเว็บเบราว์เซอร์

เขียนบน โดย
ตอบกลับ

คงไม่มีใครปฏิเสธได้ครับว่า SSL คือเทคโนโลยีหนึ่งที่สำคัญมากแบบขาดเสียไม่ได้ ทั้งในด้านธุรกรรมการเงิน การส่งต่อข้อมูลความลับต่างๆ ซึ่งเหตุผลหลักคือเพื่อป้องกันการโจมตีจากเหล่าบรรดาแฮกเกอร์ แต่เมื่อไม่นานมานี้ได้มีการเปิดเผยว่า SSL เมื่อถูกใช้งานในบางสถานการณ์นั้นอาจไม่ปลอดภัยอย่างที่เคยคิดกัน

เมื่อไม่นานมานี้ได้มีงานประชุม ACM Conference on Computer and Communications Security (CCS2012) ที่จัดเสร็จสิ้นในวันที่ 16-18 ตุลาคมที่ผ่านมา ซึ่งเป็นงานรวมตัวของนักพัฒนาโปรแกรม ผู้เชี่ยวชาญด้านความปลอดภัยทั้งจากภาครัฐ สถานศึกษา และเอกชน ได้เข้ามานำเสนอถึงทฤษฎีหรืองานวิจัยต่างๆ โดยหลังจากจบงานและเปเปอร์งานวิจัยต่างๆ ได้ขึ้นเว็บแล้วที่เว็บของ CCS 2012

ในงานนี้ได้มีงานวิจัยชิ้นหนึ่งที่สำคัญมาก ซึ่งจัดทำโดยนักวิจัยจากมหาวิทยาลัยเทคซัสในเมืองออสตินและมหาวิทยาลัยสแตนฟอร์ด ได้ระบุว่า SSL ที่ไม่ได้มีการใช้งานผ่านเว็บเบราว์เซอร์มีความเสี่ยงจะถูกโจมตีแบบ man-in-the-middle attack ได้ (อ่านคำอธิบายเพิ่มได้ที่ท้ายข่าว) โดยการใช้งานที่ไม่ได้ผ่านเว็บเบราว์เซอร์ ในงานวิจัยได้ยกตัวอย่างดังนี้

  • JAVA library ของ Amazon EC2
  • SDK ระบบซื้อขายของ Amazon และ Paypal (เฉพาะ Paypal นี้ SDK จะถูกใช้เชื่อมกับ osCommerce, ZenCart, Ubercart และ PrestaShop)
  • AdMob ผู้ให้บริการโฆษณาบนมือถือ ที่ Google เป็นเจ้าของ
  • ระบบ Mobile Banking ของ Chase.com
  • โปรแกรมสำหรับทำ web service ที่เขียนด้วยภาษา JAVA รวมถึง Apache Axis, Axis 2,
  • Codehaus XFire, และ Pusher library สำหรับ Android
  • รวมถึงโปรแกรมอะไรก็ตามที่ทำหน้าที่เป็นตัวกลางในการติดต่อผ่าน SSL

อย่างไรก็ตามไม่ได้หมายความว่าโค้ดที่ถูกเขียนบนระบบที่กล่าวมาจะถูกเขียนแบบผิดพลาด ในความเป็นจริงนั้นได้เขียนถูกต้องด้วยซ้ำ แต่เพราะโค้ดดังกล่าวจะมีการติดต่อผ่านไลบรารี่ที่ใช้ควบคุมการส่งข้อมูล เช่น Apache HttpClient หรือ cURL ซึ่งปัญหาเกิดจากนักพัฒนาเกิดความเข้าใจผิดทั้งการกำหนดพารามิเตอร์หรือการตรวจสอบค่าย้อนกลับ ทำให้กระบวนการยืนยัน SSL certificate มักจะล้มเหลวในท้ายที่สุด

เท่าที่ผมอ่านงานวิจัยคร่าวๆ ขอสรุปว่าสำหรับนักพัฒนาโปรแกรมด้วยภาษา JAVA และ PHP ที่ได้มีการใช้งานระบบใดระบบหนึ่งที่ได้กล่าวถึงไปหรือมีการใช้งาน SSL ในกระบวนการติดต่อเบื้องหลัง สมควรอ่านงานวิจัยนี้เพื่อแก้ไขหรือหาทางออก เพราะในงานได้มีบอกไว้ว่าจุดใดคือความเสี่ยงครับ

งานวิจัยดังกล่าวสามารถโหลดอ่านได้ที่นี้ Full paper

ที่มา – The Applied Crypto Group of Stanford University

คำอธิบายเพิ่ม
man-in-the-middle attack เป็นการโจมตีโดยการเบี่ยงเบนการเดินทางของข้อมูลที่ควรจะเดินทางระหว่างคอมพิวเตอร์ผู้ใช้งานกับเครื่องแม่ของผู้ให้บริการ ให้เดินทางมายังเครื่องของแฮกเกอร์แทนด้วยการหลอกทั้งเครื่องผู้ใช้งานและเครื่องแม่ว่าเครื่องตัวเองเป็นเครื่องของอีกฝ่ายที่กำลังติดต่อด้วย เป้าหมายคือการดักจับข้อมูลที่ถูกเข้ารหัสไว้หรือการปลอมแปลงข้อมูลให้ผิดไปจากเดิม

บทความนี้ถูกเผยแพร่ที่ Blognone