How to use a system journal linux

By default, newer systemd based linux systems now uses two logging services for the system logs:

systemd-journald, which is configured to only keep logs in memory
rsyslogd, which gets messages sent to it by systemd-journald (and others) and stores them on disk.

To view messages in the system journal, a tool called journalctl can be used. If used without any parameters it will show the full contents of the system journal, presented in a pager (by default less is used). The output of journalctl can be modified by using both options and filters. Options can be used to change the number of lines displayed, to turn on follow mode, change the displayed field, specify a time range, etc. Filters can be used to modify for what services and units information is displayed, which executables to display information for, etc.

journalctl examples
journalctl -ef
Jump to the end of the journal (-e, and enable follow mode (-f). This will keep the journal open on screen, displaying new messages as they come in.
# journalctl -ef

journalctl _SYSTEMD_UNIT=httpd.service
This will display all messages generated by the httpd.service systemd unit.
# journalctl _SYSTEMD_UNIT=httpd.service

journalctl -u httpd.service
This will display all messages generated by, and about, the httpd.service systemd unit.
# journalctl -u httpd.service

journalctl -p emerg..err
Display all messages in the journal with a priority in the range emerg up to and including err.
# journalctl -p emerg..err

If a single priority is specified, for example, -p err, all messages up to and including that level are displayed.
# journalctl -p err

journalctl -b -1
Only show journal messages from the last system boot. This is useful for searching for information about a system crash. This requires a persistent journal to be configured.
# journalctl -b -1

journalctl –since “2015-02-02 20:30:00” –until “2015-03-31 12:00:00”
Displays all journal messages between February 2, half past eight in the evening, and noon on March 31st. This requires a persistent journal to be configured.
# journalctl --since "2015-02-02 20:30:00" --until "2015-03-31 12:00:00"


For a complete list of options and filters, refer to the journalctl(1) man page.
# man journalctl

journalctl -o verbose
Use verbose output mode (-o verbose). This will show all fields stored in the journal with their field name and contents. All field names can be used as filters on the journalctl command line.
# journalctl -o verbose

Persisting the journal
By default, CentOS/RHEL 7 stores the system journal in /run/log/journal, which is stored on a tmpfs. This implies that on a reboot all stored information will be lost. If the directory /var/log/journal is present the journal will be stored there, thus enabling a persistent journal across reboots.



Enabling a persistent journal can be done by using the following steps:

1. Create the directory /var/log/journal.

# mkdir /var/log/journal
2. Set the group ownership of the new directory to systemd-journal, and the permissions to 2755.

# chown root:systemd-journal /var/log/journal
# chmod 2755 /var/log/journal
3. Inform systemd-journald that the new location should be used by sending a USR1 signal to it. A reboot will also suffice.

# killall -USR1 systemd-journald
Enabling verbose information
Many tools and services can increase the amount of logging they perform, as well as the amount of information they display when run from the command line, by using various configuration options or command-line flags.

Command-line options typically include -v, which can sometimes be specified multiple times, to increase verbosity, or include a –debug option that can be used. Services will typically have configuration options, either in their main configuration file or in /etc/sysconfig/SERVICENAME, that can be used to increase their logging level and/or verbosity as well. Refer to the documentation for these individual services to increase their verbosity and logging levels.

Read More

Apa itu Progressive Web Apps?

Progressive Web Apps adalah pengalaman yang menggabungkan dari web dan aplikasi. Sangat berguna bagi users dari kunjungan pertama di tab browser, tidak ada instalasi yang diperlukan. Sebagai pengguna(user) akan selalu berinteraksi dengan App dari waktu ke waktu, menjadi lebih baik dan kuat. loading menjadi lebih cepat, bahkan pada jaringan yang kurang bagus, mengirimkan pemberitahuan push relevan, memiliki ikon pada layar awal dan beban sebagai top-level, pengalaman layar penuh.

Apa yang dimaksud dengan Progressive Web Apps?

Progressive Web Apps adalah:

1. Progressive - Bekerja untuk setiap pengguna, terlepas dari pilihan browser karena mereka dibangun dengan peningkatan progressive sebagai prinsip inti.
2. Progressive - Bisa berupa bentuk faktor: desktop, seluler, tablet, atau apa pun yang berikutnya.
3. Konektivitas independen - Ditingkatkan dengan kinerja layanan untuk bekerja secara offline atau pada jaringan berkualitas rendah.
4. App-like - Merasa seperti sebuah aplikasi bagi user dengan style aplikasi interaksi dan navigasi karena dibangun di atas model aplikasi shell.
5. Fresh - Selalu up-to-date berkat proses update system layanan.
6. Aman - Berjalan dengan HTTPS untuk mencegah mengintip dan memastikan konten tidak dirusak.
7. Ditemukan - Apakah diidentifikasi sebagai "aplikasi" berkat memanifestasikan W3C dan ruang lingkup pendaftaran system layanan yang memungkinkan mesin pencari untuk menemukannya.
8. Re-engageable - Membuat re-engagement mudah melalui fitur seperti push notifikasi.
9. Diinstal - Memungkinkan pengguna untuk "menjaga" aplikasi yang mereka anggap paling berguna di home screen tanpa kerumitan app store.
10. Linkable - Mudah berbagi melalui URL dan tidak memerlukan instalasi yang rumit.

Read More

Inilah Lima Aplikasi Android Terbaik Tahun 2015

Selama tahun 2015 berjalan, Vendor aplikasi smartphone berlomba membuat macam-macam aplikasi di playstore Android.

Pengguna android tentu bisa memilih aplikasi mana saja yang cocok untuk mereka gunakan. Inilah lima aplikasi Android terbaik sepanjang 2015 seperti dikutip Mashable, Senin (28/12).

1. Adobe Photoshop Lightroom
Aplikasi Adobe banyak digunakan oleh poto graper profesional. Bereda dengan versi desktop, Adobe keluaran smartphone bisa digunakan kaum amatir sekalipun. Aplikasi ini sangat mudah digunkan untuk membentuk foto sesuai keinginan.

2. Apple Music
Meski baru berdar dalam versi Beta, keberadaan aplikasi ini tentu memutus hambatan yang dimiliki Apple terhadap Android. Aplikasi ini membantu pengguna Android untuk menikmati fasilitas yang dimiliki iTunes.

3. Cardboard Camera
Aplikasi ini mmeberikan pengalaman kepada pengguna untuk menikmati virtual reality. Cardboard Camera milik google memungkinkan pengguna membuat video 360 interaktif dengan mudah.

4. Crossy Road
Aplikasi ini merupakan permainan paling diminati dalam platform iOS pada 2014 kemarin. Baru pada 2015 pengguna Android juga bisa menikmati uniknya permainan 'kodok lari' ini. 

5. Google Photos
Google Photos menjadi aplikasi manajemen foto terbaik di 2015. Aplikasi ini secara otomatis mem-'back up', menata, dan memudahkan pengguna untuk mencari foto dalam telepon pintar yang mereka gunakan secara alfabet. Baiknya lagi aplikasi mampu menyimpan foto tidak terbatas.
sumber republika.co.id

Read More

Membangun Restfull Webservices Dengan Codeigniter

Web Services

Sebelum masuk lebih dalam ada baiknya kita membahas sedikit tentang dasarnya, walapun tidak detil mudah-mudahan bisa membantu untuk tahap selanjutnya, apa itu Webservices ? teknologi Web telah diperkirakan akan menjadi teknologi yang lebih dari sekedar untuk mengirimkan web pages (Dokumen HTML) antara HTTP client dan server, terlebih dengan semakin luasnya penggunaan teknologi ini untuk saling mengirim informasi dan service (Service disini diartikan sebagai fungsi software yang mengandung bussiness task, menyediakan akses ke file-file teks, dokumen, gambar, video, audio dll, atau melakukan fungsi common seperti authentication dan logging). Istilah Web Services akhirnya muncul.

Secara terminologi web service memiliki berbagai definisi,

Quote:web service adalah interface yang dapat diakses melalui jaringan untuk memanggil fungsi aplikasi yang dibangun menggunakan standard teknologi internet [Tidwell, Snell, Kulchenko: 2001].

Quote:Web service adalah sebuah e-service yang diidentifikasi dengan URI yang ditampilkan ke khalayak umum[Weindhart:2011].

Sedangkan menurut World Wide WebConsortium (http://www.w3.org)

Quote:web service adalah sistem komputer yang saling bertukar XML message dengan sistem lain yang menggunakan HTTP sebagai protokol komunikasinya.

Dengan kata lain jika sebuah aplikasi dapat diakses melalui jaringan menggunakan kombinasi dari berbagai protokol seperti HTTP,XML,SMTP atau Jabber maka itu dapat dikatakan sebagai web service.

Ide untuk memanfaatkan teknologi Web hal tersebut mulai terealisasi secara nyata ketika pada tahun 1990-an akhir dan salah satu pendekatan implementasi web service yang paling banyak digunakan disebut dengan Simple Access Object Protocol (SOAP) yang memanfaatkan Extensible Markup Language (XML) yang belum lama muncul saat itu sebagai paket format untuk mekanisme Remote Procedure Call (RPC). Konsep SOAP yang merupakan web implementasi dari konsep RPC menjadi daya tarik bagi banyak orang untuk mengimplementasikannya dan setuju bahwa SOAP adalah web service sesungguhnya.
Setelah beberapa waktu sebagian orang mulai berpendapat SOAP tidak mengimplementasikan model sebenarnya dari “Web Service”. Menurut mereka SOAP “hanya” mengimplementasikan RPC melalui web. Beberapa tahun setelah kepopuleran “Web Service berbasis SOAP” muncul model implementasi yang dianggap lebih tepat disebut “Web Service” karena memiliki kedekatan prinsipal secara arsitektur terhadap teknologi web.

Model tersebut dinamakan REpresentational State Transfer (REST) dan karena prinsip tersebut menggunakan model REST maka web service yang menerapkannya disebut RESTful Web Services. Meskipun sebenarnya istilah REST sendiri pertama kali muncul tahun 2000 dari disertasi Roy Fielding.Meskipun muncul berbagai model implementasi dari web service, namun ada dua hal tambahan (tidak wajib, namun umum) yang umumnya diterapkan pada web service terlepas dari model implementasi yang diacu, yaitu :

Web Service harus self describing. Ketika developer mem-publish sebuah web service baru, maka harus disertakan pula public interface untuk service nya, minimal service baru tersebut menyediakan dokumentasi sebagai informasi untuk developer pengguna (client dari web service) sehingga developer pengguna lebih mudah mengintegrasikan aplikasi nya dengan web service tersebut. Jika menggunakan model implementasi SOAP, developer idealnya menyediakan public interface yang ditulis menggunakan grammar XML yang umum, XML tersebut dapat digunakan untuk mengenali semua method public, parameter dan nilai kembalian

Web Service harus discoverable. Ketika developer mem-publish sebuah web service baru, maka harus disediakan mekanisme sederhana agar pihak yang akan menggunakan web service tersebut mudah menemukannya.

Terdapat 2 area dimana web service menjadi solusi yang paling tepat untuk diimplementasi. Pertama adalah perusahaan software yang membuka API mereka kepada publik. Yang kedua adalah internal perusahaan besar untuk mendukung bisnin prosesnya.

Perusahaan web seperti Google, Yahoo!, Amazon dan Facebook menggunakan web service untuk menawarkan produk mereka dengan menggunakan infrastruktur hardware yang sudah sangat besar. Google dan Yahoo! Menawarkan search service, Amazon menawarakan on- demand hosting storage mereka dan Facebook menawarkan platform mereka untuk target marketing dan periklanan. Dengan adanya web service hal-hal tersebut menjadi sesuatu yang memungkinkan untuk dilakukan.

Web service juga digunakan untuk internal perusahaan besar untuk saling terhubung antar department yang terpisah. Proses implementasi untuk internal perusahaan besar relatif lebih mudah bagi web service developer karena penggunaan internal, hemat biaya, resiko keamanan yang tidak tinggi karena web service nya tidak terbuka untuk umum.
Dengan melakukan implementasi web service untuk internal perusahaan untuk menghubungkan banyak departemen agar dapat saling berbagi informasi melalui web service dibutuhkan arsitektur yang mendukung. Disinilah Service-Oriented Architecture(SOA) diterapkan. Mengimplementasikan SOA dalam internal perusahaan juga tidaklah mudah karena penerapannya bukan hanya melibatkan departemen IT namun juga level management yang lebih tinggi. Dengan kata lain menerapkan SOA membutuhkan investasi yang besar di IT dan perubahan strategi operasi

REST

REST sebenarnya bukan merupakan sebuah arsitektur tapi lebih mendekati kumpulan constraint(batasan) yang ketika diterapkan pada desain sebuah sistem, akan menjadi jenis arsitektur perangkat lunak. RESTful service harusnya memenuhi constraint-contraint seperti:

Resource Identification: Semua Resource (serta statenya) yang berhubungan dengan aplikasi diberikan identifier yang unik dan identifier tersebut harus bersifat global. Konsep resource disini bukan hanya hal statis yang langsung berhubungan dengan aplikasi namun juga termasuk informasi yang dibutuhkan seperti dokumen transaksi. RESTful resource adalah semua hal yang bisa diakses dan ditransfer melalui web antara client dan server. Dan karena protokol yang digunakan untuk berkomunikasi adalah HTTP, berbagai macam tipe file bisa ditransfer, teks file, flash movie,gambar dll. Sehingga dalam RESTful system representasi dari resource tergantung dari tipe yang direquest client (MIME type) yang didefinisikan didalam protokol request.

Uniform Interface: Semua interaksi sebaiknya dibangun dengan interface yang seragam. RESTful service menampilkan semua resource dan interaksinya dengan interface yang seragam, tidak seperti RPC yang menampilkan fungsi yang ada melalui method yang bisa dipanggil secara remote. Dalam RESTful web service untuk uniform interface ini menggunakan Uniform Resource Identifier(URI). URI pada RESTful webservice berupa hyperlink terhadap resource meskipun RESTful constraint tidak menyatakan URI harus berupa hyperlink, namun karena teknologi yang digunakan pada web service adalah web sehingga URI berupa hyperlink. Jika menggunakan teknologi lain, RESTful URI tentu akan berupa hal yang berbeda, namun tetap berupa address terhadap sebuah resource

Self-Describing Message: untuk setiap interaksi dengan resource melalui interface yang seragam, REST membutuhkan representasi dari resource yang menggambarkan semua aspek penting yang dimiliki oleh resource tersebut. Representasi dari resource sendiri adalah semua hal yang dikirim antara cilent dan server. Representasi merupakan state sementara dari data sebenarnya yang terletak di suatu tempat penyimpanan. Dengan kata lain representasi merupakan stream biner besama metadata yang menjelaskan bagaimana stream tersebut digunakan baik untuk client maupun untuk server. Bisa terdapat banyak jenis client yang me-request resource yang ada, oleh karena itu representasi setiap client pun dapat berbeda. Representasinya dapat berupa gambar, text file, stream XML atau stream JSON, tapi kesemua representasi tersebut harus tersedua melalui URI yang sama. Untuk kasus request yang dilakukan oleh manusia (human user) biasanya representasi berupa laman web sehingga menjadi bentuk representasi yang dapat dibaca.

Stateless Interaction: Setiap interaksi antara client dan server harus memiliki state sendiri (atau dengan kata lain tidak dipengaruhi session client). Jadi server hanya akan memantau resource state bukan client session

Semua Constraint tersebut tidak berpengaruh dengan teknologi yang akan digunakan untuk implementasi. Constraint tersebut hanya mendefinisikan bagaimana data ditransfer antar komponen dan keuntungan apa yang didapat. Dan tidak perlu mencari teknologi atau protokol jaringan baru untuk mengimplementasikannya, karena RESTful system dapat diaplikasikan ke infrastruktur jaringan yang sudah ada seperti web, sehingga muncullah RESTful service
Uniform Interface melalui HTTP Request

Representasi adalah mapping dari resource sebenarnya yang ditransfer antara client dan server. Pada web service representasi tersebut diajukan dengan komunikasi antara client dan server melalui protokol komunikasi HTTP.

Membangun sebuah RESTful web service akan sejalan dengan cara membangun sebuah aplikasi web masa kini. Akan tetapi hal paling dasar yang berbeda untuk membangun aplikasi web yang modern dan tradisional adalah bagaimana memodelkan aksi ke abstraksi data. Modern development menitikberatkan pada pertukaran resource, sedangkan tradisional development menitik beratkan pada aksi remote untuk mengambil data. Sehingga dapat disimpulkan modern development mengimplementasi RESTful web service sedangkan yang tradisional mengimplementasikan RPC-like service (Remote Procedure Call).

Pada proses development web modern tingkat ambiguitas design dan implementasi harus dibatasi karena sudah terdapat empat aksi spesifik yang bisa dilakukan terhadap resource, yaitu Create,Retrieve, Update dan Delete (CRUD). Sedangkan pada development tradisional web banyak sekali aksi yang tidak memiliki strandard penamaan dan implementasi yang dapat dilakukan.

Sehingga pada development web modern aksi CRUD tersebut dapat dimappingkan dengan HTTP method sebagai berikut :

Code:

CREATE -> POST
RETREIVE -> GET
UPDATE -> PUT
DELETE -> DELETE

Jadi secara sederhana dapat disimpulkan RESTful web service melakukan aksi dengan memanipulasi data dengan aksi crud, meskipun RESTful web service pun tidak selalu dibatasu dengan 4 aksi dasar tersebut, kerena bisa saja RESTful web service mengeksekusi logika pada server.

Metode GET

Metode ini digunakan untuk mengambil resource. Sebagai contoh terdapat web service yang menangani mahasiswa yang terdapat dalam universitas, dengan alamat http://api.server.local:8888/ Dalam contoh dibawah XML digunakan sebagai representasi data nilai siswa

Code:

<item>
<nama_siswa>Kurosaki Ichigo</nama_siswa>
<id_siswa>1</id_siswa>
<n_bahasa>90.90</n_bahasa>
<n_matematika>78.90</n_matematika>
<n_binggris>90.95</n_binggris>
</item>

Dan list dari nilai siswa akan direpresentasikan sebagai berikut.

Code:

<listSiswa>
<item>
<nama_siswa>Kurosaki Ichigo</nama_siswa>
<id_siswa>1</id_siswa>
<n_bahasa>90.90</n_bahasa>
<n_matematika>78.90<n_matematika>
<n_binggris>90.95</n_binggris>
</item>
<item>
<nama_siswa>Kurosaki Ichigo</nama_siswa>
<id_siswa>1</id_siswa>
<n_bahasa>90.90</n_bahasa>
<n_matematika>78.90<n_matematika>
<n_binggris>90.95</n_binggris>
</item>
</listSiswa>

Dengan representasi data nilai siswa seperti diatas maka jika membutuhkan web service untuk mengambil seluruh data nilai siswa URI yang digunakan adalah http://api.server.local:8888/api/nilai , dan jika hanya akan mengambil data nilai siswa tertentu maka gunakan URI http://api.server.local:8888/api/nilai/1. jika kita gambarkan dengan langkah-langkah metode get web service secara sederhana bisa seperti berikut:

Client melakukan HTTP request dengan metode GET dan menggunakan id_siswa sebagai parameter yang dikirimkan
Client menyiapkan tipe representasi pada accept request header.
Web server menerima dan menerjemahkan GET request menjadi aksi retrieve. Setelah ini web server akan meneruskan aksi ke RESTful framework untuk menangani request yang datang. RESTful framework tidak secara otomatis mengambil resource yang diminta karena fungsi dari framework tersebut adalah untuk implementasi REST constraint sedangkan logika bisnis dan lain lain akan ditangani logika si pembuat layanan Webservices
logika code pada server akan mencari resource yang di request dengan mengambil data dari database, file atau pun memanggil web service yang lain. Setelah resource ditemukan, resource tersebut akan di convert menjadi representasi yang direquest client, dalam kasus ini adalah XML Dengan representasi yang telah diubah menjadi XML server mengirim HTTP response beserta XML nya

Metode POST

Untuk melakukan aksi create, digunakan metode HTTP POST, sebagai ilustrasi URI http://api.server.local:8888/api/nilai/ akan kembali digunakan. Dengan asumsi data nilai siswa belum terdapat dalam list siswa maka representasi XML dari nilai soswa akan tampil sebagai berikut:

Code:

<item>
<id_siswa></id_siswa>
<nama_siswa>Yondaime Hokage</nama_siswa>
<n_bahasa>90.90</n_bahasa>
<n_matematika>78.90<n_matematika>
<n_binggris>90.95</n_binggris>
</item>

Terdapat sedikit perbedaan dengan representasi nilai siswa pada metode GET sebelumnya. Pada representasi diatas tag <id_siswa> kosong, karena data nilai untuk siswa Dengan nama Yondaime Hokage belum ada di list dan nilai untuk tag <id_siswa> digenerate pada saat proses create. jika kita sekenariokan dari metode Create bisa menjadi seperti berikut.

Client melakukan HTTP request dengan metode POST
POST request membawa representasi xml dari nilai siswa yang akan dicreate.
Web server menerima request dan framework memprosesnya, code logik menyimpan data dalam storage yang digunakan
Setelah proses penyimpanan selesai, respose dikirim kembali ke client.

Metode PUT

Untuk update data resource, pertama resource yang terdapat dalam storage harus diambil lalu update nilai yang akan diubah lalu kirim put request serta xml request yang merupakan representasi data yang baru. Proses metode PUT ini seperti metode get dan post dilakukan secara berurutan, hanya saja metode post digantikan metode PUT.

Metode DELETE

Untuk menghapus resource, URI yang sama masih digunakan seperti tiga metode sebelumnya. Diasumsikan resource nilai siswa akan dihapus maka kirim DELETE request melalui URI http://api.server.local:8888/api/nilai/.

Rest Security

Pada web service, hal yang menjadi fokus dari sisi keamanan adalah kontrol terhadap resource. Meskipun pada umumnya web service dapat diakses oleh publik, pengaksessan data dan traffic harus tetap dikontrol. Sebagai contoh google translate API membatasi jumlah kata yang diterjemahkan per hari untuk setiap user yang telah terregistrasi dan telah membayar untuk menggunakan google translate API. Terdapat 2 cara yang umum digunakan untuk RESTful web service yaitu custom token authentication dan HTTP basic authentication

Custom Token Authentication

Secara sederhana cara ini diimpelemntasikan dengan men-generate token yang unik untuk setiap user yang telah terdaftar lalu user tersebut mengirimkan token yang telah di-generate pada setiap request web service. Cara ini relatif mudah diimplementasi, biasanya diterapkan pada proses registrasi user. Setiap ada registrasi user baru, user tersebut diberikan token yang unik. Dan karena setiap request token tersebut ikut dikirimkan maka akses terhadap resource terkontrol dengan baik.

Token untuk proses authentication ini dikirimkan untuk setiap request dengan 2 macam cara, menjadi bagian dari URI atau ditambahkan pada HTTP request header. Berikut adalah contoh yang menjadi bagian URI

Code:

GET https://www.googleapis.com/language/translate/v2?key=INSE RT-YOUR-KEY&source=en&target=de&q=Hello%20world

URI diatas adalah web service untuk google translate, dimana dalam URI tersebut terdapat parameter key. Parameter key tersebut adalah token yang unik terhadap setiap user. Untuk semua service yang disediakan parameter key tersebut menjadi hal yang wajib dalam URI yang digunakan.

Secara garis besar cara ini dapat memberikan developer kontrol terhadap web service yang disediakan. Sebagain contoh google translate memberikan limit 2 juta karakter per hari untuk regular user yang sudah terigistrasi, jika limit tersebut sudah terlampaui maka akses terhadap web service ini untuk user tersebut dapat ditutup sampai hari berikutnya. Namun cara ini sangat beresiko karena key dikirim setiap request dan bisa saja ada pihak lain yang mencuri key tersebut dan menggunakannya sendiri dan penyedia web service pun tidak bisa mengetahui yang mana yang memang memiliki otorisasi.

HTTP basic authentication

Cara ini diimplementasikan dengan mengirimkan teks Base64 encoded username dan password pada HTTP header Authorization. Username dan password tersebut selalu dikirimkan untuk setiap HTTP request untuk proses authorization, Client melakukan request terhadap resource /listmhs namun karena resource ini diproteksi dengan HTTP basic authentication dan didalam request client tidak terdapat authentication credential yang diperlukan maka server memberikan HTTP response 401, client yang menerima response tersebut akan melakukan aksi membuat request baru dengan menyertakan credential yang diperlukan untuk proses authentication dan dikirimkan ke URI yang sama, jika credential yang disediakan benar maka server akan memberikan response yang diminta


Jika melihat proses yang terjadi untuk cara ini, client request dapat dibuat oleh aplikasi apapun yang memiliki koneksi HTTP, dan jika yang digunakan adalah web browser, ada satu hal yang harus diperhatikan, yaitu cache. Jika credential yang diperlukan disimpan dalam cache maka user tidak perlu selalu menyertakan credential pada setiap request. Namun karena disimpan di cache web browser maka untuk menghapusnya perlu dilakukan secara manual. Jika tidak dihapus bisa terjadi penyalahgunaan oleh pihak lain. Selain itu penggunaan basic authentication ini masih memiliki resiko yang cukup tinggi karena username dan password hanya diencode menggunakan Base64 encoding yang cukup mudah dipecahkan, walaupun memang penggunaan Base64 ditujukan untuk penyeragaman karakter yang diencode untuk ditransfer melalui HTTP. Namun resiko ini dapat sedikit dikurangi dengan menggunakan HTTPS (SSL) bukan HTTP

Client request yang dibuat melalui web browser akan memiliki urutan proses seperti sequence diagram yang ditampilkan sebelumnya. Request dikirim server mengirim response 401 dan web browser akan menampilkan form untuk mengisikan credential yang diminta. Web browser secara otomatis akan mengirimkan kembali request ke URI yang sama

Cara lain adalah dengan langsung menyertakan credential pada request pertama. Cara ini dapat dilakukan dengan menambahkan credential pada saat request pertama kali dilakukan. Tentu saja hal ini perlu ditambahkan di code yang akan melakukan request. Berikut adalah contoh source code java untuk menambahkan credential pada HTTP header dengan menggunakan Commons HTTP client library.

Code:

HttpClient client = new HttpClient();
client.getState()
.setCredentials(
new AuthScope("api.server.local",8888,"basic"),
new UsernamePasswordCredentials("username","password")
);
GetMethodget = new GetMethod("http://api.server.local:8888/api/nilai/");
get.setDoAuthentication(true); client.executeMethod(get);

Method setCredentials() menyertakan credential pada HTTP Header dan setelah itu melakukan get method. Dengan cara ini, tidak perlu menunggu response 401 dari server karena credential telah disertakan sejak request pertama. Jika credential sesuai maka response yang diminta akan diberikan oleh server. Untuk metode request yang lain pun (POST,PUT,DELETE) dapat menggunakan cara yang sama.

huff…… panjang juga teorinya yak    ,

Codeigniter Sebagai Restfull Webservices

Setelah membaca panjang lebar teori diatas pastinya teman-teman sudah sedikit mengerti tentang landasan dasar dan cara penggunaan secara singkat tentang Webservies, pada bagian ini kita akan mencoba membangun Layanan Webservices Sederhana yang menyediakan informasi tentang nilai siswa seperti yang telah kita bahas sebelumya diatas tadi, pada bagian ini sebaiknya teman-teman sudah sedikit paham tentang penginstalan PHP framewok Codeigniter, karena core yang kita gunakan adalah Framework Codeigniter, oke untuk kebutuhan pertama kita download dulu Codeigniter, Kemudian install pada root direktori webserver masing-masing, struktur folder dari Codeigniter sendiri seperti berikut

kemudian kita membutuhkan sebuah library pendukung lainya, dalam tulisan ini saya menggunakan CodeIgniter Rest Controller yang dikembangkan oleh Phil Sturgeon, Chris Kacerguis, untuk mendownloadnya bisa langsung ke https://github.com/philsturgeon/codeigniter-restserver, setalah di dowload, extract hasil download, kemudian copy file application/libraries/REST_Controller.php dan application/libraries/Format.php ke folder Codeigniter pada Folder Codeigniter yang sebelumnya kita install, lakukan hal yang sama untuk file /application/config/rest.php sehingga struktur file pada Codeigniter yang baru seperti berikut


hal-hal yang perlu kita perhatikan adalah, beberapa konfgurasi dasar seperti berikut (Sesuaikan dengan kebutuhan)

PHP Code:

#Location: ./system/application/config/rest.php$config['rest_keys_table'] = 'keys';$config['rest_enable_keys'] = TRUE;#Location: ./application/config/config.php$root = "http://".$_SERVER['HTTP_HOST'];$root .= str_replace(basename($_SERVER['SCRIPT_NAME']),"",$_SERVER['SCRIPT_NAME']);$config['base_url']    = "$root";$config['encryption_key'] = 'inikeyrahasia';#Location: ./application/config/autoload.php$autoload['libraries'] = array('database');$autoload['helper'] = array('url');#Location: ./application/config/database.php$db['default']['hostname'] = 'localhost';$db['default']['username'] = 'root';$db['default']['password'] = 'root';$db['default']['database'] = 'api_server';$db['default']['dbdriver'] = 'mysql'; 

setelah kita konfigurasi, kita buat dulu database untuk kebutuhan penyimpanan data nantinya, karena Webservices sederhana kita akan memberikan informasi tentang nilai siswa, dan setiap client nantinya akan diberikan API Key sebagai kunci agar bisa mendapatkan informasi, untuk itu kita butuh 2 buat tabel dengan nama keys dan siswa

Code:

CREATE TABLE `keys` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`key` varchar(40) NOT NULL,
`level` int(2) NOT NULL,
`ignore_limits` tinyint(1) NOT NULL DEFAULT '0',
`is_private_key` tinyint(1) NOT NULL DEFAULT '0',
`ip_addresses` TEXT NULL DEFAULT NULL,
`date_created` int(11) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Code:

CREATE TABLE `siswa` (
`id_siswa` int(11) unsigned NOT NULL AUTO_INCREMENT,
`nama_siswa` varchar(32) DEFAULT NULL,
`n_bahasa` decimal(11,2) DEFAULT NULL,
`n_matematika` decimal(11,2) DEFAULT NULL,
`n_binggris` decimal(11,2) DEFAULT NULL,
PRIMARY KEY (`id_siswa`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=latin1;

kemudian kita coba jalankan, untuk memastikan semua berjalan dengan lancar, jika tidak ada masalah maka tampilan awal codeigniter akan tetap seperti semula, alias tidak ada yang berubah.


tahap selanjutnya kita akan mendesain sebuah logic untuk memproses setiap request yang akan diproses, pada tingkatan ini, semua client harus menggunakan API Key untuk dapat melakuakn request dan menerima respon dari server, kita bisa analogikan prosesnya seperti berikut ini

client mengirimkan request – Server melakukan proses pengecekan terhadap API KEY dari Client – jika API Key Benar maka proses akan dilanjutkan – Jika API KEY tidak benar maka server akan memberikan pesan bahwa API KEY tidak valid, mari kita lihat dulu fungsi-fungsi yang nantinya kita butuhkan

PHP Code:

<?php if ( ! defined('BASEPATH')) exit('No direct script access allowed');/**
 * API Controller
 *
 * Contoh pengunaan fungsi dalam Restfull Web Services
 *
 * @package        CodeIgniter
 * @subpackage    Rest Server
 * @category    Controller
 * @author        Khairu Aqsara
 * @link        http://khairu.my.id
*/require APPPATH.'/libraries/REST_Controller.php';
class Api extends REST_Controller{
    # fungsi untuk melihat nilai siswa
    function nilai_get($id_siswa=null){}
    ## fungsi untuk simpan nilai siswa
    function nilai_post(){}
} 

pada fungsi diatas terdapat 2 buah fungsi utama, yang pertama adalah fungsi untuk menampilkan nilai siswa, dan fungsi ke-dua untuk menambhkan nilai siswa, yang perlu diperhatikan adalah penamaan fungsi pada barisan code diatas, RestFull Webservices akan memproses semua request dengan metode-metode yang sudah dijelaskan sebelumnya, jika kita perhatikan nama fungsi di atas terlihat nilai_get() _get() diatas menunjukan jika fungsi tersebut direquest menggunakan metode _GET, sedangkan pada fungsi berikutnya dipanggil dengan menggunakan metode _POST, jika kita terjemahkan dalam bentuk request mungkin sederhananya akan menjadi seperti berikut

Code:

GET http://api.server.local:8888/api/nilai
GET http://api.server.local:8888/api/nilai/1
POST http://api.server.local:8888/api/nilai

sekarang kita akan mencoba menambahkan beberapa baris code pada kedua fungsi diatas sesuai dengan kebutuhan kita,berikut code untuk fungsi nilai_get()

PHP Code:

# fungsi untuk melihat nilai siswafunction nilai_get($id_siswa=null){
    if($id_siswa!=null){
        $nilai = $this->db->get('siswa', array('id_siswa'=>$id_siswa));
        if($nilai->num_rows() == 1){
            $respon = array(
                    'status'=>true,
                    'id_siswa'=>$nilai->row()->id_siswa,
                    'nama_siswa'=>$nilai->row()->nama_siswa,
                    'n_bahasa'=>$nilai->row()->n_bahasa,
                    'n_matematika'=>$nilai->row()->n_matematika,
                    'n_binggris'=>$nilai->row()->n_binggris
                );
            $this->response($respon, 200);
        }else{
            $this->response(array('status'=>false,'msg'=>'Data tidak ditemukan'), 500);
        }
    }else{
        $nilai = $this->db->get('siswa');
        if($nilai->num_rows() > 0){
            $respon = array(
                    'status'=>true,
                    'data_nilai_siswa'=>$nilai->result_array(),
                );
            $this->response($respon, 200);
        }else{
            $this->response(array('status'=>false,'msg'=>'Data tidak ditemukan'), 500);
        }
    }
} 

Kemudian pada fungsi berikutnya

PHP Code:

# fungsi untuk simpan nilai siswafunction nilai_post(){
    $data = array(
            'nama_siswa'=>$this->post('nama_siswa'),
            'n_bahasa'=>$this->post('n_bahasa'),
            'n_matematika'=>$this->post('n_matematika'),
            'n_binggris'=>$this->post('n_binggris')
        );
    if($this->db->insert('siswa', $data)){
        $this->response(array('status'=>true,'data'=>$data,'msg'=>'Data Berhasil disimpan'), 200);
    }else{
        $this->response(array('status'=>false,'msg'=>'Data tidak berhasil disimpan!!'), 500);
    }
} 

untuk mencoba hasil dari program kita, kita bisa menggunakan Rest Client, disini saya menggunakan Rest Client untuk Add Ons Mozila Firefox (http://www.restclient.net/), seperti dijelaskan diatas, client akan membutuhkan API Key sebagai kunci untuk bisa mendapatkan data dari server, jika request tidak menyertakan API KEY maka server akan memberikan respon bahwa API KEY tidak valid, seperti gambar berikut

untuk itu kita akan menambahkan X-API-KEY pada HTTP header, untuk value dari API KEY silahkan diambil dari tabel Key yang telah kita buat sebelumnya, pada contoh ini saya mengunakan jenis hash sha1 dengan panjang 40 karakter bentuk hash, contohnya seperti gambar berikut

setelah API Key di tambahkan pada bagian Header HTTP, kita ulangi proses request, maka hasilnya akan muncul dalam bentuk XML, seperti gambar berikut


data diatas diambil dari database yang telah kita buat sebelumnya, begitu juga dengan metode pengiriman data menggunakan POST, setiap request harus menyertakan API KEY, jika kita menggunakan RestClient kita juga harus menentukan Content Type agar server memeriksa request sebagai request dari sebuah form, seerti berikut


kemudian kita tambahkan value yang akan dikirimkan keserver dalam mode http query seperti berikut

Code:

nama_siswa=Yondaime Hokage&n_bahasa=90&n_matematika=80&n_binggris=100

jika kita kirimkan request ke server maka kita akan mendapatkan respon seperti berikut


sekian dulu dari saya, mudah-mudahan bermanfaat, apa yang ada dalam tulisan ini banyak yang bisa kita terapkan, tergantung kebutuhan dan kretifitas kita. 

Sumber: http://devilzc0de.org/forum/printthread.php?tid=22549

Read More

Perbedaan antara 4G dengan 4.5 G

Jaringan 4.5G kini resmi hadir di Indonesia yang ditandai dengan peluncuran layanan 4G LTE-Advanced Smartfren di Jakarta, Rabu.

Menurut Senior Manager Project Management Office (PMO) ZTE Indonesia, Vimal Kanagalingman, perbedaan 4G dan 4.5 terletak pada jumlah frekuensi sehingga menghasilkan kecepatan yang lebih baik.
"Perbedaan 4G dan 4.5 adalah 4G menggunakan single carrier, sedangkan 4.5G dua carrier," kata dia.
Jaringan 4.5G yang tersebar dapat mendukung mode TDD (Time Division Duplex) dan FDD (Frequency Division Duplex) secara bersamaan.
Jaringan tersebut dioperasikan pada frekuensi 800MHz dan frekuensi terbaru 2.300MHz.
Dengan didukung dua standar LTE, yaitu TDD dan FDD, perangkat yang telah mendukung jaringan 4G LTE bekerja lebih optimal dibandingkan dengan dengan jaringan-jaringan yang hanya didukung satu standar LTE.

Jaringan tersebut juga dapat bekerja di dua frekuensi sehingga dapat menghadirkan kombinasi antara cakupan data yang luas dan bandwidth yang optimal.

"Pada intinya, dengan 4.5G download akan semakin cepat," ujar Vimal.

Tidak hanya dari segi kecepatan, Vimal mengatakan bahwa jaringan  4.5G lebih stabil.

Read More

Microsoft Windows 10 adalah Versi Terakhir

Dalam konferensi Ignite Microsoft, pengembang Microsoft Jerry Nixon mengisyaratkan bahwa Windows 10 merupakan versi terakhir dari Windows.

"Saat ini kami sedang merilis Windows 10, dan karena Windows 10 adalah versi terakhir dari Windows, kami semua masih mengerjakan Windows 10," kata dia, seperti dilansir GSM Arena.

Windows 10 adalah versi terakhir dari Windows, dalam arti tidak akan ada rilis utama Windows.

Microsoft berencana untuk mengubah Windows ke sebuah layanan, di mana Windows akan terus mendapatkan update, namun tidak akan ada rilis utama.

Sistem operasi yang ada saat ini telah menjadi titik balik di mana Microsoft dapat memperbarui bagian tersebut sesuai dengan yang direncanakan.
Update berikutnya akan dirilis tahun 2016, dengan nama kode Windows Redstone, tetapi masih dengan Windows 10, bukan Windows 11 atau yang lainnya.

Pada dasarnya, tidak ada lagi peluncuran Windows X, di mana X adalah nomor versi atau nama.

Meski demikian, hal tersebut mungkin tidak banyak berubah bagi pengguna. Pengguna akan terus mendapat update setiap bulan.

Hanya saja ke depannya tidak akan ada lagi rilis versi bernomor lebih besar dari 10, namun Windows itu sendiri akan terus berkembang dan menjadi lebih baik.

Read More

Cara Setting SSL Security biar dapat grade A di ssllabs

Untuk mendapatkan Grade yang bagus di ssllabs.com sangat mudah tinggal ikutin langkah-langkah berikut ini.

Rubah file dengan perintah
pico /etc/httpd/conf.d/vhost_domain-name.conf

Cari baris : <VirtualHost *:443>

tambahkan dibawahnya : Strict-Transport-Security "max-age=63072000;"

atau kalau menggunakan SSL wildcard : Strict-Transport-Security "max-age=63072000; includeSubDomains"

Lalu lihat baris setelah: SSLEngine on

kalau belum ada tambahkan kode berikut ini :

SSLCompression on
SSLHonorCipherOrder on
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On


lihat juga isi  SSLCipherSuite

rubah dengan kode berikut:
SSLCipherSuite EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:!aNULL:!eNULL:!LOW:!MEDIUM:!SEED:!3DES:!CAMELLIA:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4

atau coba :
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS


Simpan file dan restart restart Apache dengan perintah: service httpd restart

Tambahan ini berfungsi biar kalau ada yang browsing menggunakan http akan otomatis di forward ke https

pico /home/username/namadomainanda.com/html/.htaccess

Add the following:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</IfModule>

Untuk uji labnya https://www.ssllabs.com/ssltest/analyze.html?d= namadomainanda.com
Selamat mencoba 

Read More