Cloudflare memiliki kemampuan untuk memeriksa trafik sebelum permintaan diteruskan ke server website. Dengan konfigurasi yang tepat, pengunjung manusia tetap dapat mengakses halaman, sementara trafik yang dianggap mencurigakan dapat diperiksa terlebih dahulu.

Yang tidak kalah penting, crawler terpercaya seperti mesin pencari tetap perlu mendapatkan perlakuan yang berbeda. Jika seluruh bot diblokir tanpa pengecualian, proses pengindeksan website dapat ikut terganggu.

Mengapa Website Perlu Perlindungan dari Bot?

Tidak semua kunjungan ke sebuah website berasal dari manusia. Saat sebuah halaman dibuka, server dapat menerima permintaan dari browser, crawler mesin pencari, aplikasi otomatis, maupun berbagai jenis bot.

Sebagian crawler memang memiliki fungsi penting. Googlebot, misalnya, membantu mesin pencari menemukan dan memahami halaman website. Namun, ada pula bot yang melakukan permintaan dalam jumlah besar tanpa memberikan manfaat bagi pemilik situs.

Trafik otomatis yang berlebihan dapat meningkatkan penggunaan sumber daya server. Selain itu, aktivitas scraping juga dapat mengambil konten website secara otomatis.

Karena itu, pengelola website membutuhkan sistem yang mampu membedakan trafik berdasarkan tingkat kepercayaannya.

Apa Itu Managed Challenge Cloudflare?

Managed Challenge Cloudflare merupakan mekanisme pemeriksaan yang dapat digunakan untuk membantu menentukan apakah sebuah permintaan berasal dari pengguna yang layak mendapatkan akses.

Berbeda dari CAPTCHA tradisional yang selalu menampilkan teka-teki kepada pengguna, Managed Challenge memungkinkan Cloudflare menentukan bentuk pemeriksaan berdasarkan kondisi permintaan.

Jika pemeriksaan berhasil, pengguna dapat melanjutkan ke website. Dengan demikian, perlindungan dapat diterapkan tanpa harus selalu memberikan pengalaman yang sama kepada setiap pengunjung.

Pendekatan seperti ini cukup menarik bagi website yang menerima banyak trafik dari internet terbuka.

Verified Bots Tetap Perlu Diberi Akses

Salah satu bagian penting dalam konfigurasi perlindungan bot adalah Verified Bots.

Pengelola website sebaiknya tidak langsung menganggap semua bot sebagai ancaman. Crawler mesin pencari memiliki fungsi penting dalam proses indeks dan penemuan konten.

Cloudflare menyediakan penanda cf.client.bot untuk mengenali bot yang telah diverifikasi sebagai crawler yang dikenal. Dengan memanfaatkan penanda tersebut, pengelola website dapat membuat pengecualian sebelum menerapkan pemeriksaan kepada trafik lainnya.

Konsepnya sederhana.

Verified Bot dikenali terlebih dahulu. Setelah itu, trafik yang bukan Verified Bot dapat diberikan pemeriksaan tambahan.

Pendekatan ini lebih baik dibandingkan sekadar memeriksa tulisan seperti Googlebot pada User-Agent. Sebab, User-Agent dapat dipalsukan oleh bot otomatis.

Mengapa Tidak Cukup Memblokir Semua Bot?

Memblokir semua bot memang terlihat sederhana. Namun, cara tersebut dapat menimbulkan masalah.

Mesin pencari menggunakan crawler untuk menemukan halaman baru. Jika crawler tersebut ikut diblokir, konten website dapat mengalami hambatan dalam proses crawling dan indexing.

Selain itu, ada bot lain yang sebenarnya berguna, misalnya crawler dari layanan tertentu yang membantu memantau website atau menyediakan fungsi tertentu.

Karena itu, strategi yang lebih masuk akal adalah memisahkan bot terpercaya dari trafik yang perlu diperiksa.

Konfigurasi Cloudflare Free

Perlindungan tersebut juga dapat diterapkan pada pengguna Cloudflare Free dengan memanfaatkan Custom Rules yang tersedia pada dashboard Cloudflare.

Dalam konfigurasi yang dibahas, rule pertama digunakan untuk mengenali Verified Bots melalui expression:

cf.client.bot

Kemudian action yang digunakan adalah Skip untuk memberikan pengecualian terhadap rule tertentu.

Setelah itu, rule berikutnya dapat digunakan untuk menangani request yang bukan Verified Bot:

not cf.client.bot

Action yang digunakan adalah Managed Challenge.

Dengan pola tersebut, alurnya menjadi lebih mudah dipahami.

Verified Bot

Crawler yang dikenali Cloudflare sebagai Verified Bot tidak diarahkan ke challenge yang dibuat untuk trafik lainnya.

Pengunjung Selain Verified Bot

Request yang bukan Verified Bot mendapatkan Managed Challenge. Pengunjung manusia kemudian dapat melewati pemeriksaan tersebut dan melanjutkan akses.

Mengapa Menggunakan Managed Challenge?

Managed Challenge memberikan pendekatan yang lebih fleksibel dibandingkan langsung menggunakan Block.

Jika sebuah request belum tentu berbahaya, memblokirnya secara langsung dapat meningkatkan risiko false positive. Challenge memberikan kesempatan kepada pengguna yang sah untuk membuktikan bahwa akses tersebut valid.

Karena itu, Managed Challenge dapat menjadi pilihan yang lebih aman ketika tujuan utama adalah mengurangi trafik otomatis tanpa langsung menutup akses bagi seluruh pengunjung yang belum dikenal.

Perlindungan Berlaku untuk Halaman Website

Ketika Custom Rule dibuat tanpa membatasi hostname atau path tertentu, rule tersebut dapat diterapkan terhadap request yang sesuai di zone Cloudflare.

Artinya, perlindungan tidak hanya harus berlaku pada halaman utama.

Misalnya, sebuah website memiliki:

• halaman utama;
• halaman berita;
• halaman kategori;
• halaman arsip;
• halaman pencarian;
• dan halaman lainnya.

Selama request tersebut melewati Cloudflare dan memenuhi expression yang dibuat, rule dapat ikut diterapkan.

Hal ini penting bagi website berita karena bot tidak selalu mengakses halaman depan. Bot otomatis justru dapat langsung meminta URL artikel tertentu.

Bagaimana dengan Subdomain?

Subdomain juga dapat memperoleh perlindungan Cloudflare apabila subdomain tersebut menggunakan proxy Cloudflare.

Misalnya:

salira.tv
dir.salira.tv

Jika record DNS subdomain menggunakan status Proxied, request subdomain tersebut melewati jaringan Cloudflare.

Namun, ada hal yang perlu diperhatikan. Status proxy, konfigurasi rule, hostname, dan cookie clearance dapat memengaruhi apakah pengguna melihat challenge pada setiap akses.

Jadi, tidak tepat menganggap bahwa setiap URL pasti akan menampilkan challenge setiap kali dibuka.

Jangan Mengandalkan Nama Googlebot

Salah satu kesalahan yang perlu dihindari adalah membuat aturan seperti:

User-Agent contains "Googlebot"

kemudian langsung memberikan akses.

Masalahnya, bot lain dapat mengubah User-Agent dan berpura-pura menjadi Googlebot.

Karena itu, identifikasi bot terpercaya sebaiknya menggunakan mekanisme verifikasi yang disediakan oleh Cloudflare, bukan sekadar mencocokkan teks User-Agent.

Pendekatan tersebut membuat konfigurasi keamanan menjadi lebih masuk akal dan tidak mudah dimanipulasi.

Uji Konfigurasi Setelah Rule Aktif

Setelah rule diterapkan, pengelola website sebaiknya melakukan pengujian.

Pertama, akses website menggunakan browser biasa. Jika Managed Challenge muncul kemudian pengguna dapat masuk, berarti mekanisme pemeriksaan berjalan.

Selanjutnya, pengelola dapat memeriksa Security Events pada Cloudflare untuk melihat bagaimana request dikategorikan.

Pengujian juga penting dilakukan pada halaman yang berbeda. Jangan hanya menguji homepage karena bot dapat mengakses URL artikel secara langsung.

Untuk website yang memiliki subdomain, subdomain juga sebaiknya diuji secara terpisah.

Perlindungan Bot Harus Tetap Seimbang

Keamanan website tidak hanya tentang memblokir sebanyak mungkin request.

Konfigurasi yang terlalu agresif dapat membuat pengguna asli mengalami challenge berulang kali. Bahkan crawler yang sebenarnya penting dapat ikut terganggu jika rule dibuat tanpa pengecualian.

Sebaliknya, konfigurasi yang terlalu longgar dapat membuat bot otomatis tetap memperoleh akses tanpa pemeriksaan berarti.

Karena itu, pendekatan yang lebih baik adalah menggunakan beberapa lapisan.

Verified Bot dapat diberikan pengecualian, sedangkan trafik lain dapat diperiksa menggunakan Managed Challenge. Setelah sistem berjalan, data dari Security Events dapat digunakan untuk mengevaluasi apakah aturan tersebut perlu diperketat atau dilonggarkan.

Kesimpulan

Melindungi website dari bot tidak selalu berarti harus memblokir seluruh trafik otomatis. Website tetap membutuhkan crawler terpercaya untuk membantu mesin pencari menemukan dan mengindeks konten.

Dengan memanfaatkan Cloudflare Free, pengelola website dapat mulai membangun perlindungan menggunakan Custom Rules. Salah satu pendekatan yang dapat digunakan adalah mengenali Verified Bots terlebih dahulu, kemudian menerapkan Managed Challenge kepada request yang bukan Verified Bot.

Pendekatan tersebut memberikan keseimbangan antara keamanan dan aksesibilitas. Pengunjung manusia masih memiliki kesempatan untuk melewati pemeriksaan, sementara trafik otomatis yang tidak dikenali dapat diberikan lapisan verifikasi tambahan.

Pada akhirnya, konfigurasi keamanan terbaik bukanlah konfigurasi yang paling agresif, melainkan konfigurasi yang mampu mengurangi trafik berbahaya tanpa mengorbankan pengunjung dan crawler yang memang dibutuhkan website.

Reporter: Tim Redaksi Suara Salira
Editor: P. Pirmansyah

The post Managed Challenge Cloudflare untuk Lindungi Situs dari Bot appeared first on Suara Salira.

Nah, di artikel ini kita bahas dengan bahasa santai dan mudah dipahami.

Apa Itu Aplikasi WebView?

Aplikasi WebView adalah aplikasi Android yang hanya menampilkan halaman website di dalam aplikasi. Jadi tampilannya seperti aplikasi, tapi isinya sebenarnya website.

Biasanya aplikasi seperti ini:

• Mengambil konten dari satu domain tertentu
• Bisa berubah tampilannya tanpa update APK
• Hanya berfungsi sebagai pembungkus web

Sebaliknya, aplikasi native dibuat langsung menggunakan kode Android seperti Java atau Kotlin, dan semua tampilan ada di dalam file APK itu sendiri.

Cara Cek Aplikasi Android WebView Atau Native

Berikut langkah praktisnya.

1. Gunakan Aplikasi JADX

Download dan buka file APK menggunakan jadx-gui di Windows.

Kemudian tekan:

Ctrl + Shift + F

Lalu cari kata:

WebView

Kalau muncul:

import android.webkit.WebView;

atau

WebView webView;

Hampir bisa dipastikan itu aplikasi WebView.

2. Cari loadUrl()

Coba cari juga:

loadUrl(

Jika ada kode seperti:

webView.loadUrl("https://domain.com");

Itu bukti kuat bahwa aplikasi hanya membuka halaman website tertentu.

3. Jangan Hanya Cari “http”

Banyak orang salah kaprah.

Mencari kata http memang bisa membantu, tapi bukan bukti utama. Karena aplikasi native juga menggunakan HTTP untuk:

• API
• Streaming audio
• Iklan
• Analytics
• Update sistem

Jadi, HTTP bukan indikator paling kuat.

Ciri Aplikasi Native

Kalau aplikasi bukan WebView, biasanya kamu akan menemukan kode seperti:

MediaPlayer
ExoPlayer
setDataSource(

Artinya aplikasi benar-benar memproses data di dalam sistem Android, bukan hanya menampilkan website.

Kesimpulan

Cara cek aplikasi Android WebView atau native yang paling akurat adalah dengan mencari penggunaan WebView di dalam kode APK.

Urutannya:

1. Cari WebView
2. Cari loadUrl(
3. Baru audit semua http

Kalau tidak ada WebView sama sekali, kemungkinan besar aplikasi tersebut adalah native.

Sekarang kamu bisa melakukan investigasi sendiri sebelum menilai sebuah aplikasi.

Reporter: Tim Redaksi Suara Salira
Editor: P. Pirmansyah

The post Cara Cek Aplikasi Android WebView Atau Native appeared first on Suara Salira.

Mikrofon lavalier nirkabel ini hadir dengan sistem 3 in 1 receiver, yang sudah mendukung adaptor iPhone, Type-C, dan jack audio kamera 3,5 mm. Artinya, Sahabat bisa langsung menggunakannya di berbagai perangkat tanpa ribet ganti alat. Cukup nyalakan, mikrofon akan otomatis terhubung alias plug and play.

Shorush H68 menggunakan pita digital 2.4 GHz dengan pola omni-directional, sehingga suara bisa ditangkap lebih merata dari berbagai arah. Jarak transmisinya pun cukup jauh, hingga 60 meter, cocok untuk kebutuhan rekaman indoor maupun outdoor.

Soal kualitas suara, mikrofon ini sudah dibekali chip DSP dengan teknologi pengurangan noise. Hasilnya, suara vokal tetap terdengar jernih meski digunakan di lingkungan ramai, termasuk area perkotaan. Ditambah lagi dengan windsheld anti angin, rekaman tetap stabil meski Sahabat mengambil video di luar ruangan.

Desain clip-on membuat Shorush H68 mudah disematkan di pakaian atau aksesori lain. Ukurannya kecil, ringan, dan nyaman dipakai dalam waktu lama. Dengan baterai 350mAh, mikrofon ini mampu digunakan hingga 10 jam nonstop, jadi Sahabat tak perlu sering-sering mengisi daya saat produksi konten.

Dalam paket penjualannya, Shorush H68 sudah dilengkapi kantong penyimpanan, kabel pengisian daya USB, mikrofon, receiver 3 in 1, dan windsheld. Tersedia pilihan 1 mic 1 receiver maupun 2 mic 1 receiver, yang bisa disesuaikan dengan kebutuhan rekaman solo atau wawancara.

Dengan harga yang ramah di kantong, Shorush H68 cocok untuk konten kreator pemula hingga semi profesional, mulai dari vlogger, podcaster, pewawancara, videografer, sampai kreator live streaming. Praktis, serbaguna, dan siap dipakai kapan saja.

Tim Mawar Suara Salira

The post Shorush H68, Mikrofon Clip On Praktis Untuk Konten Harian appeared first on Suara Salira.

Sayangnya, bagian ini sering dianggap sepele. Banyak yang langsung memilih Channel: AUTO karena dianggap paling praktis. Padahal, di kondisi tertentu, mode auto justru jadi sumber masalah.

Apa Sebenarnya Channel WiFi Itu?

Channel WiFi bisa dibayangkan seperti jalur lalu lintas. Di frekuensi 2.4 GHz, tersedia channel 1 sampai 13. Masalahnya, channel-channel ini tidak semuanya berdiri sendiri. Banyak yang saling tumpang tindih dan akhirnya bikin sinyal saling ganggu.

Di 2.4 GHz, channel yang benar-benar aman dan tidak saling tumpang tindih hanya ada tiga:

• Channel 1
• Channel 6
• Channel 11

Selain itu, sinyal akan saling bertabrakan dan membuat koneksi tidak maksimal.

Kenapa Mode AUTO Sering Jadi Masalah?

Saat channel diset AUTO, router akan memilih jalurnya sendiri. Masalahnya, router tidak selalu memilih channel terbaik. Sering kali router justru memilih channel “nanggung” seperti 3 atau 4, yang bertabrakan dengan channel di kiri dan kanannya.

Selain itu, router juga bisa berpindah channel sendiri saat merasa jalurnya ramai. Buat pengguna yang sedang streaming, meeting, atau siaran online, perubahan ini bisa menyebabkan koneksi terputus sesaat tanpa disadari.

Di lingkungan padat WiFi seperti perumahan, kos-kosan, atau tempat umum, mode AUTO juga sering kalah dengan WiFi tetangga yang sinyalnya lebih kuat dan sudah diatur manual.

Channel Width Juga Tidak Boleh Asal

Selain channel, ada pengaturan lain yang sering diabaikan, yaitu Channel Width. Untuk 2.4 GHz, pilihan paling aman adalah 20 MHz. Lebih sempit memang, tapi jauh lebih stabil dan minim gangguan.

Menggunakan 40 MHz atau AUTO di area yang ramai WiFi justru sering bikin koneksi naik turun karena jalurnya melebar dan saling tumpang tindih.

Setting Aman Untuk WiFi Rumah

Untuk penggunaan harian di rumah, pengaturan yang paling direkomendasikan adalah:

• Frekuensi: 2.4 GHz
• Channel Width: 20 MHz
• Channel: Manual – pilih 1, 6, atau 11

Pilih channel yang paling sepi di sekitar rumah. Dengan setting sederhana ini, WiFi biasanya jadi lebih stabil, jarang putus, dan lebih nyaman dipakai.

Bagaimana Kalau Dalam Satu Tempat Ada Banyak WiFi?

Masalah channel WiFi tidak hanya terjadi di rumah. Di tempat seperti warkop, kafe, kantor kecil, atau coworking space, sering kali terpasang lebih dari satu perangkat WiFi dalam satu lokasi.

Kalau ada enam perangkat WiFi, apakah semuanya harus pakai channel berbeda?

Jawabannya, tidak harus, dan sebenarnya tidak mungkin juga kalau masih menggunakan frekuensi 2.4 GHz.

Kenapa Tidak Bisa Semua Pakai Channel Berbeda?

Di 2.4 GHz, jalur bersih memang hanya tiga: 1, 6, dan 11. Artinya, mau ada tiga, enam, atau sepuluh perangkat WiFi sekalipun, tetap saja harus berbagi channel.

Namun perlu dipahami, berbagi channel bukan berarti tabrakan parah.

Berbagi Channel Lebih Aman Daripada Salah Channel

Banyak orang mengira dua WiFi di channel yang sama pasti bikin kacau. Padahal, dua perangkat di channel yang sama masih bisa berbagi giliran mengirim data.

Yang justru bermasalah adalah menggunakan channel yang saling tumpang tindih, seperti channel 3 atau 4. Ini ibarat satu kendaraan nyelonong di tengah dua jalur dan bikin macet semuanya.

Karena itu, dua perangkat di channel 1 jauh lebih aman dibanding satu perangkat di channel 3.

Contoh Aman Untuk Banyak Perangkat WiFi

Kalau ada enam perangkat WiFi dalam satu lokasi, pembagian yang paling aman adalah:

• Dua perangkat di channel 1
• Dua perangkat di channel 6
• Dua perangkat di channel 11

Semua perangkat sebaiknya diset dengan channel width 20 MHz agar sinyal tidak melebar ke mana-mana.

Selain itu, kekuatan sinyal juga sebaiknya tidak disetel maksimal. Sinyal yang terlalu kuat justru bisa saling “teriak” dan mengganggu perangkat WiFi lain yang jaraknya berdekatan.

Kesimpulan

Mode AUTO memang terlihat praktis, tapi bukan berarti paling aman. Baik di rumah maupun di tempat ramai seperti warkop atau kafe, pengaturan manual yang tepat justru membuat WiFi lebih stabil.

Sedikit repot di awal, tapi hasilnya koneksi lebih nyaman, lebih konsisten, dan jauh dari drama WiFi lemot.

Tim Mawar Suara Salira

The post Rahasia WiFi Stabil, Jangan Percaya Mode Auto Sepenuhnya appeared first on Suara Salira.