Tag Archives

11 Articles
Konfigurasi CAS 5.1.2
Arsitektur SSO dasar.

Konfigurasi CAS 5.1.2

Apereo CAS (sebelumnya Jasig CAS) banyak dipakai untuk SSO. Cara pemasangannya agak ribet dan sulit. Kebetulan, versi CAS 5.1.2 sekarang sudah menggunakan Spring Boot sebagai dasarnya.

Keuntungan penggunaan Spring Boot adalah Jasig CAS menggunakan banyak keunggulan framework Spring. Misalnya, teknologi Spring Cloud untuk teknologi devops, Spring Web Flow untuk arsitektur layanan mikro (micro service), service discovery, dan konfigurasi melalui YAML. Sehingga, kita bisa memasang infrastruktur SSO melalui CAS tanpa harus mengoding seperti dahulu. Atau, kita bisa mengembangkan layanan yang terpisah dari SSO ala layanan mikro.

Sebelum infrastruktur bertambah rumit, saya ingin memberikan jembatan keledai. Sebab, saya pikir SSO ini agak sulit pada awalnya kalau tidak tahu caranya. Saya harap ketika selesai membaca artikel ini, pembaca ada gambaran bagaimana SSO bisa dikembangkan.

Arsitektur yang dipilih

Arsitektur SSO

Arsitektur SSO dasar.

Ada banyak pilihan, tetapi saya memilih kapabilitas komponen yang bisa diskalakan secara horizontal dan modern. Misalnya, ada banyak pilihan untuk ruang penyimpan tiket (Ticket Storage), tetapi saya memilih Redis karena dia implementasi modern yang banyak dipakai untuk teknologi dewasa ini.

Setiap komponen yang saya pilih ini dapat dikluster. Saya memilih untuk mengembangkan satu layanan per mesin. Nanti kalau sudah mengerti teknologi perawanan, [uhuk colek Utian Ayuba] Anda bisa mengubah setiap ini menjadi konfigurasi devops macam Ansible, Puppet, Chef, Vagrant,  atau apa pun agama Anda.

CAS IdP

CAS IdP adalah mesin utama yang menyediakan profil, otentikasi, dan otorisasi. Semua klien terhubung ke sana.

Cara buat:

CAS IdP Server

CAS Ticket Storage

Secara baku CAS IdP menyimpan tiket sesi pada memori. Namun, untuk arsitektur kluster dan skalabilitas, lebih baik menggunakan Redis. Mengapa Redis? Karena Redis utamanya menggunakan memori.

Untuk peladen Redis tidak perlu dikluster. Lebih baik satu instans Redis yang memakan memori 24 GB dari pada membuat kluster.

Cara buat:

Redis Ticket Storage

CAS Service Storage

Satu situs/sistem/aplikasi yang menggunakan CAS untuk SSO disebut satu layanan (service). Setiap layanan dapat didefinisikan logo, URL, ACL pengguna, dan sebagainya secara granular. Itu semua secara baku disimpan oleh CAS IdP di berkas JSON.

Untuk pengelolaan yang lebih baik, saya memilih PostgreSQL sebagai ruang penyimpan. Pengalaman saya membandingkan PostgreSQL dengan MySQL mengatakan bahwa PostgreSQL rajanya basisdata untuk basisdata perangkat lunak bebas terbuka. Waktu itu saya membandingkan layanan Roundcube Webmail dengan MySQL dan PostgreSQL. Anda sebagai pengguna Webmail UI pasti merasakan bagaimana Webmail UI itu seperti mengakses sistem HTML statik.

Saya, sih, tidak apa kalau ada yang mau menggunakan MongoDB atau yang lainnya. Tetapi saya memilih karena daftar layanan ini tidak perlu kecepatan khusus. Selain itu, daftar layanan butuh untuk tahan banting, saya lebih memilih PostgreSQL. Tentu saja, saya takkan memilih Redis.

Cara buat:

CAS Service Registry

CAS Authentication Provider

Normalnya CAS menggunakan Spring Security dengan login casuser dan sandi Mellon. Tentunya, ini buat yang main-main. Untuk yang lebih serius, gunakan LDAP, basis data, atau bahkan layanan REST.

Penyedia otentikasi CAS dapat lebih dari satu (komposit). Tetapi, untuk kali ini, gunakan saja LDAP.

Cara buat:

CAS Auth LDAP

CAS Service Management Webapp

Aduh, lupa menulis dokumentasi. Silakan simpan URL ini, nanti saya coba tulis. Untuk sementara, langsung saja buat di basisdata. He… he… he….

Studi Kasus: WordPress

Penasaran dengan hasilnya? Langsung saja, buat aplikasi WordPress. Mengapa WordPress? Karena gampang memasangnya. Tinggal pakai plugin WP Cassify, daftarkan URL WP sebagai satu layanan, dan beres!

Cara buat:

WordPress Cassify

TODO:

  • Personalisasi halaman login.
  • Membuat CAS IdP terkluster (lebih dari satu instans)
  • Entahlah….
WordPress 4.9.1 dengan PHP 7.2

WordPress 4.9.1 dengan PHP 7.2

Saya biasanya kalau mau memperbaharui WordPress selalu menunggu versi minor .1 atau lebih. Soalnya, suka ada perilaku tak terduga kalau versi mayor baru terbit. Kali ini, WordPress 4.9.1 sudah terbit.

Menurut situsnya, WordPress merekomendasikan penggunaan PHP 7.2. Saya sendiri baru tahu kalau sudah ada PHP 7.2. Pantas saja WordPress berhenti di versi 4.8.4 pada beberapa peladen.

Saatnya memasang PHP 7.2!

Pemasangan PHP 7.2

Saya pernah membahas tentang PHP 7.1+ di artikel terdahulu. Jadi, ini sekedar mengulang saja.

Aktifkan modul APT untuk mengakses repo berbasis HTTPS dan beberapa paket lainnya.

Aktifkan repo Suri.

Lalu, pasang PHP 7.2 untuk menggantikan PHP 5.

Kalau hanya sekedar php-fpm, yang terpasang bakal versi 7.1. Harus secara eksplisit disebutkan versi 7.2.

Selanjutnya, menyalin konfigurasi fpm dari /etc/php5/fpm/pool.d ke /etc/php/7.2/fpm/pool.d untuk setiap pool.

Saya sejauh ini tidak ada masalah.

Fungsi Yang Mulai Ditinggalkan

Nampaknya PHP7 dan terbaru hendak dibuat menjadi domain yang ketat (strict typecast). Mungkin pengembang PHP ingin menjadikan PHP sebagai bahasa yang lebih aman. Kalau saya melihat log, biasanya akan diprotes bentuk akses senarai (array). Saya mendapati fungsi count() terutama yang paling sering dicatat.

Ada orang-orang yang memutuskan untuk kembali ke PHP 7.1. Tapi saya tidak! Agar sesuai dengan PHP7.2 dan terbaru, misalnya ada variabel:

count($elements[‘#value’])

Diubah dengan menambahkan uji tipe senarai :

Atau, saat diubah menjadi tipe senarai:

Penyebab ini semua kalau saya lihat di kode sumber WordPress adalah biasanya karena penggunaan variabel global.

Untung saja, untuk yang lain pun WordPress dan plugin-nya sudah cukup bersahabat.

Bacaan Lebih Lanjut

Dunia Tak Seindah Dulu

Dunia Tak Seindah Dulu

Sebagai janitor yang berbakti, saya suka berkunjung ke situs-situs yang seharusnya dikelola oleh orang lain. Kebetulan lapak orang itu menempati lahan yang saya kelola. Ya, sebagai bakti sosial, saya juga suka membantu lapak-lapak itu.

Suatu hari, saya secara tak sengaja menemukan akses ke URL yang seharusnya tidak ada, yakni akses ke kfc.i.illuminationes.com/snitch, pada peramban saya. [Pada Firefox tekan F12 pada jaringan

Hmm… domain apakah ini?

Ternyata usut punya usut, ini adalah  salah satu domain yang digunakan oleh spyware!

Menurut ddmcleod, penyebab injeksi ini adalah komputer yang terinfeksi oleh malware khusus. Malware ini mendeteksi pengguna yang merupakan admin WordPress. Sehingga, ketika pengguna sedang login ke situsnya yang berbasis WordPress, malware ini akan menginjeksi situs tersebut dengan menambahkan skrip Javascript pada setiap header.php tematik yang ada di situs itu.

Niat sekali pembuat malware ini. Mereka berusaha menginjeksi komputer-komputer di seluruh dunia dengan harapan ada admin WordPress yang memakai komputer terinjeksi malware tersebut untuk mengakses situsnya.

The malicious code.

The malicious code. I screen-captured it so that Google won’t block my site.

Canggih sekali malware zaman sekarang.

Cara saya mendeteksi setiap tematik itu adalah dengan menjalankan berikut:

dan saya pun menemukan skrip aneh. Lalu, saya satu persatu menghapus tematik yang tak diperlukan dan menghapus baris injeksi.

Selamat berburu.

Bacaan Lebih Lanjut

WordPress Modus Pemeliharaan

WordPress Modus Pemeliharaan

WordPress mematikan semua aktivitas saat diperbaharui. Dia akan muncul halaman Dalam Pemeliharaan (Maintenance Mode). Sayangnya, tampilan yang ada saat ini kurang menarik.

Saatnya mengubah tampilan menjadi lebih baik.

Buat Halaman PHP maintenance.php

Tanpa perlu plugin, cukup buat sebuah berkas PHP di wp-content/maintenance.php yang berisi:

Berkas ini sebenarnya hanya modifikasi dari modus pemeliharaan yang dimiliki WordPress. Saya menambahkan tiga berkas: dua berkas CSS yang ada di CDN dan satu berkas gambar (wp-content/uploads/Maintenance.php) yang saya buat sendiri menggunakan MyPaint. Klik gambar untuk mendapatkan kode sumber.

maintenis

A custom maintenance mode.

Bacaan Lebih Lanjut

Galat WP Cron Pada WordPress 4.3

Galat WP Cron Pada WordPress 4.3

Ada kesalahan pemrograman pada WordPress 4.3 sehingga mengakibatkan WP Cron menginjeksi tugas dengan rangkaian yang panjang. Galat ini ada di Galat #33423. Tambalan tersedia pada Tambalan #33646.

Masalah ini membuat beberapa situs yang saya kelola berbasis WordPress jatuh. Hal ini karena WordPress secara otomatis memperbaharui dirinya ke WordPress 4.3.

Saya memodifikasi Tambalan #33646 untuk menambal WordPress 4.3 menjadi berkas WP4.3-WPCronError.patch untuk lebih gampangnya. Berikut cara membetulkan WordPress 4.3:

  1. Unduh berkas WP4.3-WPCronError.patch. Supaya mudah, saya asumsikan berkas ada di /tmp.
  2. Masuk ke direktori WordPress (misalnya /var/www)
  3. Setelah itu, tambal WordPress 4.3 Anda. Sekali lagi, saya asumsikan berkas tambalan ada di /tmp. Kalau Anda beda, sesuaikanlah.
  4. Selesai.

Semoga bermanfaat.

WordPress, NGINX, HHVM, dan Monit

WordPress, NGINX, HHVM, dan Monit

Bagi yang sudah pernah berurusan dengan situs yang berat, Anda pasti juga jengah dengan kelakuan PHP-FPM. Ada beberapa solusi yang saat ini tersedia:

Beberapa waktu yang lalu saya sudah membahas tentang uWSGI. Sekarang, saya mau mencoba teknologi HHVM. Doakan saja supaya saya tidak malas dan juga mau mencoba HippyVM dan PHP7-FPM sehingga saya bisa menuliskan untuk Anda.

Pasang HHVM

Cara pasang HHVM di berbagai sistem operasi ada di sini. Saya asumsikan hendak dipasang di sistem operasi Debian Jessie.

Perintah-perintah ini pada intinya memasang kunci paket repo HHVM dan menambahkan repo tersebut ke daftar repositori sistem. Kemudian, perbaharui daftar paket yang tersedia dan pasang HHVM.

Selanjutnya, ubah konfigurasi HHVM di /etc/hhvm/server.ini menjadi

Ada beberapa perbedaan dengan konfigurasi biasa. Berikut yang penting:

  • Saya memilih untuk menggunakan socket dari pada port TCP karena lebih aman dalam menentukan hak akses.
  • Saya menyuruh HHVM untuk segera mengaktifkan optimasi dari sejak awal. Hal ini mengakibatkan peladen agak lama di awal.
  • Saya mematikan fungsi profiling. Fungsi ini berguna kalau Anda mau men-debug kode PHP Anda yang dieksekusi oleh HHVM. Kemungkinan besar, Anda terlalu malas seperti saya. Fungsi ini hanya akan memenuhi /tmp dengan berkas peta performa.

Pasang NGINX

Pertama-tama, pasang NGINX:

Set upstream NGINX ke HHVM di berkas /etc/nginx/conf.d/upstream.conf

Lalu, buat sebuah blok konfigurasi /etc/nginx/php-hhvm

Ini saya ambil dan modifikasi sedikit dari hhvm.conf yang biasanya terpasang saat kita memasang HHVM.

Nah, setiap Virtual Host yang mau menggunakan, tinggal mengikutkan berkas php-hhvm di dalam berkas konfigurasinya. Misalnya, kita buat sebuah berkas /etc/nginx/sites-available/default

Jangan lupa, ini cuma contoh! Untuk mesin produksi, tolong ubah berkas direktori dan tambahkan beberapa aturan untuk menghindari injeksi.

Selanjutnya, pasang seperti biasa ala Debian:

Beres.

Eits! Nanti dulu, Kisanak! Supaya situs tetap berjalan, mari pasang Monit untuk memonitor keberadaan HHVM. Menurut pengalaman saya, awal-awal HHVM rentan terhadap aplikasi yang harus dinyalakan ulang.

Pasang Monit

Pasang Monit.

Buat konfigurasi Monit untuk HHVM di /etc/monit/conf.d/hhvm yang isinya:

Untuk dapat memonitor Monit, langkah opsional yang dapat diambil adalah dengan mengubah 3 baris berikut pada /etc/monit/monitrc

Kalau pada konfigurasi Jessie, baris-baris itu mulai dari baris ke-130.

Setelah selesai, muat ulang Monit:

Kalau mau lihat Monit, silakan ketik:

Tentunya, langkah opsional dikerjakan. Bila tidak, maka Monit tak dapat dilihat.

Selesai!

Salt (IV/Initial Value) untuk WordPress

Salt (IV/Initial Value) untuk WordPress

Kalau Anda malas menggunakan pwgen dan tetap ingin punya situs WordPress yang cukup handal, gunakan IV yang benar untuk nonce dan kunci-kunci WordPress. Situs untuk memproduksi nilai-nilai itu ada di:

https://api.wordpress.org/secret-key/1.1/salt/

Contoh isinya: (berubah-ubah tiap kunjungan)

 

WordPress Tidak Bisa Menambah Menu

WordPress Tidak Bisa Menambah Menu

Tidak bisa menambah menu di WordPress. Penyebabnya karena menu disimpan di dalam variabel $_POST melebihi memori yang disediakan.

Cara mengatasinya

Tambahkan di php.ini

Tambahkan di suhosin.ini

Demikian.

Coretan tentang WordPress, Buddypress, dan BBPress

Coretan tentang WordPress, Buddypress, dan BBPress

Database Connection Error

Ini bisa disebabkan oleh banyak hal, tapi yang paling penting pastikan isi wp_options:

option_id option_name option_value autoload
1 siteurl http://[DOMAIN_NAME]/ yes

Hal ini diperlukan karena opsi tersebut menentukan di mana situs tersebut dibuat.

Buddypress Tidak Bisa Akses Avatar

Secara baku, upload_path yang diberikan oleh Buddypress untuk avatar adalah:

Terkadang kita membuat aturan ketat di pelayan web agar dapat mengakses di daerah tertentu dan terisolasi. Selain itu, konsensus baru dari WordPress  semenjak versi 3.5+ menyarankan setiap situs sebaiknya menaruh di direktori masing-masing.

option_id option_name option_value autoload
167 upload_path wp-content/blogs.dir/1/files yes

Dengan demikian, membatasi akses tak perlu di luar situs masing-masing.

Buddypress Terintegrasi dengan BBPress

Sekarang BuddyPress semenjak versi 1.7+ tidak perlu mengaktifkan forum internal. BBPress sudah bisa mendeteksi Buddypress dan menawarkan untuk mengonfigurasi dirinya untuk menjadi komponen forum grup Buddypress.

Tulisan ini catatan buat saya. Memang, ada banyak tulisan di luar sana. Namun, tak ada yang abadi seperti utopia Tim Berners-Lee pernah cita-citakan mengenai Internet. Semua fana.

Fixing WordPress Network Admin on 3.1.x

Fixing WordPress Network Admin on 3.1.x

Having upgraded from WPMU, there were problems since our blog, MHS Blog and Staff Blog, jumped to 3.x series. The biggest problem is when we jumped into 3.1. The Network Admin is no longer accessible. It always redirects us to “/wp-admin/network/” not “/admin/wp-admin/network/” even when we tried to set the address manually.

A temporary fix was to set “PATH_CURRENT_SITE” from “/” to “/admin/”. That could only enabling the Network Admin. But, all of the other user blogs became unaccessible.  So, I have to set back and forth just to switch to maintenance mode or operational.

The real solution however is to set your admin blog (usually blog id “1”) to “/”. Apparently, the problem was because the Network Admin section searched for “/” path. While, we the relic from WPMU uses “/admin/” path in our main blog.

So, in wp_blogs  table, we change the path of blogid 1 from “/admin/” to “/”. It works.

Btw, thx char101 for the solution. 🙂