Ngobrolin Otorisasi
Ringkasan Episode
Bantu KoreksiEpisode ini membahas otorisasi (authorization) dan bagaimana ia berbeda dari otentikasi yang pernah dibahas di episode sebelumnya. Otentikasi menjawab "siapa Anda dan benarkah Anda orang itu", sedangkan otorisasi menjawab "Anda boleh melakukan apa saja". Dari pembeda sederhana itu tim Ngobrolin WEB menelusuri empat model hak akses yang lazim dipakai di aplikasi web. Pembahasan dimulai dari RBAC (Role-Based Access Control) yang paling umum dan paling mudah dipahami, contohnya level administrator, editor, writer, dan subscriber di WordPress. Lalu naik ke ACL (Access Control List) yang memecah izin menjadi permission kecil-kecil seperti read, write, publish, dan delete others — model yang juga dipakai S3 bucket. Berikutnya ABAC (Attribute-Based Access Control, disebut juga PBAC) yang memutuskan akses lewat kondisi atas atribut user, resource, action, dan environment, sehingga bisa membatasi akses hanya pada jam kantor atau hanya beberapa hari. Terakhir ReBAC (Relationship-Based Access Control) yang dipopulerkan Google Zanzibar dan terasa seperti model Google Drive atau collaborator di GitHub. Diskusi ditutup dengan sisi implementasi: menyimpan relasi ReBAC butuh satu tabel khusus relationship sehingga memberi akses ke satu orang tidak perlu mengubah data user maupun dokumen, dan untuk relasi yang dalam seperti mutual friend atau second degree connection, graph database seperti Neo4j lebih cocok daripada relational database. Sesi ini terselenggara berkat kerja sama dengan DomaiNesia.
Poin-poin Utama
- •Otentikasi menjawab "siapa Anda" dan memverifikasi kebenarannya, sedangkan otorisasi menjawab "Anda boleh melakukan apa" — dua hal berbeda yang sering tertukar
- •RBAC adalah model paling lazim dan paling mudah diterapkan: role seperti administrator, editor, writer, dan subscriber di WordPress menentukan daftar izin yang menempel padanya
- •ACL memecah izin menjadi kontrol kecil-kecil (read, write, publish, delete milik sendiri vs delete milik orang lain) dan bisa berdiri sendiri maupun dikombinasikan dengan RBAC — S3 bucket memakai pendekatan ini
- •ABAC (atau PBAC) berprinsip "allow access if conditions are true" dengan empat jenis atribut: user, resource, action, dan environment — inilah yang memungkinkan aturan seperti login hanya pada jam kantor atau akses edit yang berlaku dua hari
- •ReBAC yang dipopulerkan Google Zanzibar menentukan akses dari relasi antara subject dan object, persis seperti owner/editor/commenter/viewer di Google Drive atau collaborator di repo GitHub
- •Kelebihan ReBAC adalah pemberian akses ad-hoc ke satu user tertentu cukup mengubah satu baris di tabel relationship, tanpa menyentuh data user, role, maupun atribut dokumen — tetapi ia tidak punya batas waktu bawaan seperti ABAC
- •Untuk relasi yang berjenjang seperti mutual friend atau second degree connection, graph database seperti Neo4j lebih mudah di-query daripada relational database
Dapatkan hanya di Domestika
Halo-halo, Tim.
Hai, kayaknya begitu liat logo ngobrol di web, saya merasa kayaknya kita perlu ganti.
Hah? Logonya, oh iya. Kenapa logonya? Itu masih pakai yang lama ya?
Itu kayaknya pakai yang kapan punya gitu ya. Waktu itu saya masih pakai...
Masih pakai itu ya? Apa mid-journey ya?
Bing. Eh?
Bing? Iya Bing kali ya.
Bing Image Generation itu loh.
Iya, Bing Create ya.
Waktu itu aman-aman, awal-awal baru ada mid-journey.
Apalagi mid-journey kan waktu itu kan masih Discord only ya.
Iya.
Eh sulit banget buat generate image tuh.
Terus, yang baru bisa gratisan generate image itu baru si Bing.
Itu Sora kan? Sora-sora. OpenAI punya dia, kayaknya.
Eh bukan ya?
Sora yang filen itu?
Bukan, bukan. Image.
Pokoknya OpenAI punya Generative Image.
Nggak tahu namanya apa.
Sebelum Sora setau saya.
Oh sebelum Sora ya?
Ya udah, cuma biarin aja sih, teranjur kayak gitu.
Ya udah, oke.
Kalau tiap saat itu Image Generation baru, bikin baru, nggak kelar-kelar.
Image Generation aja, logo generation selalu termasuk vintage ya sekarang ya.
Udah kalau saya dipikirin logo, ya.
Pikirin lah itu, kaos-kaos, kapan kita bikin kaos.
Sudah saya generate loh, tinggal diperusin aja nih.
Lihat transkrip lengkap (891 segmen lagi)
Tunggu tanggal mana ya?
Ngomongin soal kaos tuh, kaos saya malam ini Dominicia dong.
Oh iya.
Setiap malam selasa, selasa malam pasti Dominicia ya.
Selama beberapa episode ke depan juga masih Dominicia, jadi karena kita kolaborasi dengan Dominicia,
buat acara ini, jadi kalau temen-temen punya website atau aplikasi web,
bisa hosting di Dominicia pakai promo Ngobrolin WebDN, diskonnya 10%.
Kalau mau yang next level lagi, bisa pakai VPS, Ngobrolin VPSDN.
Itu diskonnya lebih gede ya.
Jadi diskonnya 50%, setengah harga ya.
Promo kodnya Ngobrolin VPSDN, beraku untuk semua paket, semua siklus,
bisa dipakai lebih dari satu kali, akonnya sama, nggak apa-apa, jadi silahkan digunakan.
Langsung cek aja ke Dominicia.com dan pakai kode promonya.
Wah, Mac Mini nya, oh ke pencet, keren Mac Mini nya restart.
Nah kalau belum bisa beli Mac Mini, sementara ambil VPS Domainnya Sia dulu aja.
Tapi saya belum pakai klo-klo loh, klo-klo nya nggak ada.
Saya nggak ada rencananya bikin klo-kloan.
Ada yang nonton ini, sengpenyanyi coba. Coba dulu kan belum tetap cocok kan, nggak semua orang ngerasa itu solusi yang tepat kan.
Jadi coba dulu pakai yang murah lah, pakai kode promo yang tadi.
Kalau udah cocok, dan ada budget nya baru beli Mac Mini.
Masalah utama dari apa namanya, rajungan-rajungan ini.
Bukan itu penkepiting bakal ya.
Kepiting nge-rebus, kepiting nge-rebus.
Enggak sih itu ini loh, lobster loh itu.
Lobster ya lobster. Lobster ini lebih ke, sebenarnya bukan ya kalau ada yang mau pakai di Mac Mini sih ya oke lah gitu.
Dan harganya juga memang tidak murah kan.
Tapi yang lebih affordable memang dipakai di laptop sendiri bisa.
Kalau mau coba-coba ya, mau coba-coba.
Kalau laptopnya laptop kantor jangan, bahaya ya.
Jadi mendingan coba di VM atau di VPS gitu.
Cuman problem utamanya adalah di tokennya, dia sangat boros sekali.
Kalau nanti dia beli Mac Mini, ya self-pose saja.
Tergantung Mac Mini nya kuat atau enggak.
Mac Mini itu kan kalau yang base modelnya kan cuma 8 atau 16 GB gitu, dan 256 hadisnya.
Nah kalau di youtuber luar, dia enggak pakai Mac Mini, dia pakai Mac Pro.
Baru bisa jalan lokal, kalau mau jalan lokal.
Kalau misalkan Mac Mini itu masih pakai cloud.
- Mac Studio. - Mac Studio.
- Wah, beda lagi tuh. - Iya.
Karena aku udah liat harga Mac Studio, terus liat istri kan, "Apa yang ini aja ya?"
Dia langsung liat dengan tatapan, tatapan yang...
Dia cuma liat tatapan, terus aku bilang, "Nggak jadi deh."
Itu berarti tidak mendapat autorisasi ya?
- Unauthorized. - Iya sih, unauthorized.
- Unauthorized ini. - Unauthorized money.
Jadi topik kita malam ini adalah authorization.
Autorisasi, keren, keren. Segway-nya keren ya. Apa namanya?
Transisinya, view transitionnya bagus nih efeknya.
Tidak diosan-osan lagi. Tidak S&E ya.
Ini ada yang nonton, biasa kok komennya sepi ya?
Biasa, kalau kita udah mau selesai, baru pada muncul biasanya.
Lebih malam ya.
Oh iya ya. Coba absen-absen teman-teman yang ada di YouTube atau yang ada di LinkedIn,
Mungkin masih baru habis terawih ya.
- Bisa sampai rumah, bisa langsung jalanin. - Atau malah habis ngga buburit biasanya.
- Ngga buburit? Bukber, bukber. - Bukber tadi soal lagi.
- Minggunya bukber ya. - Oh bukber ya.
Sudah mulai rame mall biasanya minggu ini. Karena minggu depan udah mulai mudik kan ya.
- Mudik. - Pada mudik mana? Mas Disa mudik ngga?
- Ngga. Di sini saja. - Kan deket.
- Deket. - Hah? Deket dari mana?
- Kan belom ini, belom Medan kan? Apa aja? - Iya, Medan.
- Ya deket lah. - Masa Medan?
- Kan satu ini doang, satu flight doang. Ngga pake nyamung-nyamung.
- Bukan masalah jarak, bukan masalah jumlah flightnya, tapi masalah harganya Pak.
Harganya tuh lebih mahal daripada ke core sale.
- Percaya kalau itu saya, percaya. - Lebih murah.
- Karena sesama orang Medan, kalau mau pulang ke Medan itu mikir, mikirnya dua kali.
- Lebih murah transit dulu ke Kuala Lumpur katanya, baru ke Medan.
- Iya. - Aduh.
- Kok bisa gitu ya? - Makanya aneh kan.
- Kemarin ada yang kasih lihat di sosial media, tiba-tiba muncul, dia bilang, core sale 900.000.
Harga tiket Medan aja 800.000 kalau harga normal.
Kalau harga tidak normal seperti sekarang, mungkin bisa sejuta, sejuta sampai satu setengah ya.
- Nah yaudah, solusinya lebar. - Kayaknya dua jutaan ya.
- Ngga tau ngapain. - Dua jutaan.
- Iya. Dua jutaan. - Dan kemudian di kali empat. Oke terima kasih.
Bukannya nggak mau mudik ya. - Belum lagi rame banget ininya bandaranya.
- Mungkin karena ini ya, karena orang tua dua-duanya udah didekat sini, deket-deketan semuanya.
- Udah diboyong kesini, jadinya ngapain pulang orang tuanya disini.
- Bisa, bisa, bisa. - Jadi itu lah.
- Bisa jadi alternatif juga buat temen-temen yang di luar sana.
Kalau misalnya sudah berkeluarga dan punya dua anak seperti saya, lebih murah mendatangkan orang tua
daripada membawa seluruh keluarga ke orang tua.
- Iya. Betul, betul. Apalagi.. - Seseksi biaya ya, maksudnya ya.
Bukan kangen kampung ya. Kalau kangen orang tuanya, saya..
- Iya mau, nggak mau. - Kalau itu kan memencahkan masalah
kangen orang tua, cuma nggak mencari masalah kangen kampung.
- Iya. Kalau kangen orang tua, saya datangkan orang tuanya.
Tapi kalau kangen kampung halamannya, ya beda. - Nggak bisa, beda.
- Nah itu beda lagi. Kalo mau makan durian, oh Ivan nggak suka durian lagi ya.
- Nggak suka durian. - Makan durian, mau makan apa?
- Emang nggak bisa pesan online gitu? - Mi Bangladesh.
- Eh sudah ada Bing Bangladesh, eh Mi Bangladesh sudah ada di sini.
- Udah banyak di sini ya. - Dan itu bukan asli dari Sono.
Itu mah pendatang yang bukan Mi Bangladesh. - Yang di Medan yang asli apa?
Yang di Medan yang asli apa? Mi Aceh, kan dari Aceh? - Mi Balap, Mi Balap.
- Mi Balap? - Sate Padang, dari Padang.
- Eh di Medan Soto Udah. - Mi Balap itu Soto Medan.
- Soto Medan, Mi Balap. - Makan Soto ada udangnya itu aneh, aneh sih baru pernah.
- Belum pernah, cobain dong. - Masa nya baru pernah itu.
Ya baru pernah, udah. Dan nggak ada di tempat lain, di kota lain mana pun nggak ada kan, Soto yang kayak gitu.
Udangnya besar-besar banget, wah sambungnya.
- Ceritanya kalau mau pulang ke Medan ya, kita ngisi BWAI, ngisi itu aja Comeda, I/O, Google I/O.
- Iya. Boleh, boleh, boleh. - Oke.
- Kita om pimpat dulu Sate mau ngisi. - Om pimpat dulu.
Tau nya yang diundang Pak Dika.
- Iya dicoba lagi selanjutnya.
- Alhamdulillah ya kita sudah ada kedatangan satu penonton.
- Halo. - Halo.
Akhirnya ada yang absen.
Ya ada yang mudik, ini kan gosipnya katanya kan, perang-perang gimana updatenya perang?
Katanya gara-gara perang kan BBM langkah, takutnya berpengaruh kepada mudik.
- Belum kerasa ya? - Belum kerasa ya.
- Sudah mulai kerasa sih kalau untuk BBM itu kayak lebih pada panik baying kali ya, pada panik baying.
- Oh iya, iya, iya. - Dia ditumpuk ya, ditumpuk ya di setel.
- Tapi kayak liat berita, kalau di India kan katanya supply-nya udah mulai, kayak mulai habis gitu, mulai menipis.
- Karena selama ini supply BBM mereka langsung udah di sana, solat formus katanya.
- Supply sih bakal tetap ada, kalau untuk sampai langkah itu mungkin masih panjang kalau sampai langkah.
Supply-nya tetap ada, cuma harganya itu aja naik nantinya.
- Oh iya pasti. - Kalau misalnya yang BBM swasta lah ya, gak usah yang kuning.
Yang swasta itu kan bergantung dengan US Dollar dan harga standardnya mereka.
Jadi kalau misalnya, kayak BP, Shell segala macam tuh, Vivo, kalau memang harga nanti naik ya harganya naik.
Jadi ya kita liat aja lah, yang mau mudik mungkin harus kencangin ikat pinggang.
- Iya, jangan naik yang itu, yang menggunakan BBM. - Harga pasti naik.
- Atau kereta. - Karena banyak yang mau beli kan.
Misalnya kita punya sumber sendiri yang gak affected sama perang.
Tapi kan pasti mau, pasti yang tempat-tempat kayak India dan lain-lain yang supply-nya berkurang,
pasti mau beli dari tempat yang supply yang kita pakai kan.
Kenapa jadi ngobrolin minyak.
- Yang tidak kalah penting adalah teh air belum cair, jadi belum bisa mudik.
Belum cair, belum cair. Halo-halo, Mas Wieta Sendhaya, akhirnya kita ada dua.
- Di Indonesia itu seru ya, ada THR. - THR.
- Saya gak tahu kalau negara mana lagi yang ada THR, saya gak tahu.
- Malaysia gitu? - Teman-teman yang tahu.
- Emang Malaysia gak ada? Malaysia berlungai gitu?
- Iya, Malaysia kan negara Islam.
- Emang THR itu budaya Islam? Bukannya?
- Hari Raya, maksudnya hidul fitri biasanya. Walaupun sekarang sudah diadaptasi.
Gak, dulu awal-awal hidul fitri.
Kalau dulu hidul fitri, terus sekarang oh kalau mau natalan tahun baru,
ya ngambilnya pada saat natal tahun baru. - Boleh milih, apa?
Yang natalan ya boleh milih untuk minta THR-nya sesuai kebutuhan.
- Nah, pertanyaannya, kalau bukan Islam, kalau bukan Kristen, apa dong?
- Kalau boleh milih. Jadi, satu-satunya... - Ikut tahun baru.
- Ya, kalau koding pernah kajan di kursusan bahasa, ini jauh sebelum kerja koding.
Kalau sejak kerja koding, gak pernah kerja di tempat yang ada THR sih.
Dulu itu pilihannya THR cuma keluar, cuma bisa rilis di dua rilis schedule itu, hidul fitri atau natal,
dan ternyata pas itu kejadian ada satu teman kerja yang agamanya bukan keduanya.
Tapi ya ditanya aja mau keluar pas kapan, bebas milih.
Kalau ATS, gak ada THR. Jangan dibahas. Cukup, sebelum lenceng kemana-mana ya.
- Iya. THR itu otorisasi siapa ya? - SR, SR.
- Nah, itu kan gak semua level karyawan dapat THR. Nah, itu balikin ke otorisasi.
- Ya maksudnya kalau Cufa. Kalau OTSORS, gak dapat kan? Gak tahu sih.
- OTSORS? - Gak, gak dapat.
- OTSORS, karyawan kontrak? - Kalau OTSORS bukan karyawan tetap, gak dapat kan?
- Mitra, gak dapat. - Freelancer, gak dapat.
- Ya, itu jelas. - Saya kontraktor, gak dapat.
- Kontraktor juga gak dapat ya? Emang gak ada aturannya kan? Tapi bonus ada kan?
- Gak ada. - Gak ada juga?
- Di tempat saya bekerja maksudnya ya. Pas saya bekerja, gak ada THR, gak ada bonus.
- Tapi gajinya gede. - Gak ada lembur, udah.
- Tapi gajinya gede. - Cukup, bukan gede. Cukup.
Cukup beli mobil, cukup beli Mcmini, ya.
- Semua orang juga cukup. Cukup beli mobil juga cukup. Cuma tinggal mau apa nggak aja.
- Betul. Oke, kita bahasnya dari mana nih, otorisasi.
- Nah, kita kan pernah bahas otentikasi. - Sebelum ini ya?
- Iya, bedanya sama otentikasi apa? Mungkin bahas itu dulu kali ya.
- Saya dulu nih, kan kalau ada autentikasi, ada otorisasi.
Kalau otentikasi itu, kalau di bahasa gampangnya, siapa Anda?
- Apakah betul orang itu? - Siapakah Anda?
- Terus kalau otorisasi, kamu tuh bisa ngapain aja. - Boleh ngapain aja?
- Boleh ngapain aja. Iya. Jadi itu memang membedakan otentikasi dan otorisasi.
- Dan poin yang penting sih, otentikasi kan selain siapa Anda, benar sesuai.
Kan semua orang bisa ngaku-ngaku ya. Siapa Anda, saya, lah bener mereka atau bukan?
- Ya itu proses otentikasi itu.
- Seperti selain siapa juga ada implikasi, kayak benar nggak sesuai jawabannya?
Soal siapa?
- Nah kalau hak akses, kita bisa mengakses apa.
Jadi setelah kita masuk, kita dapat rule biasanya kan.
Oh dia admin, oh dia user biasa, oh cuma bisa ngeliat doang nggak bisa ubah.
Itu adalah bagian dari otorisasi.
- Otorisasi. - Itu disebut rule base access control.
- Access control atau RBAC. - Iya. Ini yang paling lazim nih, paling banyak dimana-mana.
Sebenarnya ya kalau kalian install WordPress, kan ada administrator, editor, writer,
ada subscriber dan public aja gitu.
Kalau misalnya kayaknya si Laravel punya juga deh modul untuk ini, modul untuk otorisasi,
ada kalau nggak salah, yang bisa dibuat berlevel.
Yang sistemnya berlevel itu contohnya yang masih, apa ya, bahasanya ya.
Simplify. Jadi kita dari sisi kode, cuman ngecek, oh si A rolnya administrator.
Berarti administrator tuh bisa ngapain aja.
- Bisa semua biasanya gitu ya. - Iya.
- Atau super admin, ada super admin lagi, lebih gede lagi.
Iya, super admin. Ada yang contohnya misalnya kayak, apa tuh ya namanya ya.
Oh, contohnya kalau WordPress sudah agak manjuk ya.
Kalau misalnya si, siapa ya, kalau kita bikinnya pakai tanpa pakai library apa-apa deh.
Kan pakainya bertingkat yang mungkin dicek secara kondisional.
Rolnya administrator, editor, atau writer misalnya.
Jadi kalau writer boleh nulis, boleh save, tapi nggak bisa publish.
Yang sistem modular seperti ini masih simplified.
Ada yang lebih dalam lagi, yang satu level lebih dalam, itu dibuat secara atribut base namanya.
Atribut base itu contohnya, sorry, bukan.
- Itu salah, atribut base. ACL. Access Control List. - Access Control List.
Jadi contohnya read permission, terus kemudian write permission.
Terus kemudian dia bisa read, write, edit, terus bisa publish.
Itu dibuat bertingkat. Kalau misalnya si administrator bisa semua.
Kalau editor bisa semua juga untuk post ya misalnya ya, post kalau di WordPress ya.
Kalau dia writer, dia bisa read, write, tapi publishnya nggak dikasih.
Kebayang nggak? Terus kalau satu lagi dibawah writer, subscriber, hanya boleh read doang.
Itu ACL namanya, Access Control List.
Jadi bisa banyak atributnya atau kontrol-kontrolnya kecil-kecil.
Jadi lebih modular lagi bahasanya, berdasarkan secara desain atau sistemnya ya.
Jadi kalau misalnya kita punya objek, objek post, artikel.
Biasanya kan paling dasar, read, write, terus kemudian publish, delete.
Terus kalau misalnya si WordPress kita bisa nge-delete punya sendiri,
tapi nggak bisa nge-delete punya orang, delete other, artikel, delete other gitu ya.
Jadi bisa buat berlapis.
Dan nanti disesuaikan kalau misalnya dia login sebagai editor,
langsung ke Access Control List ini, langsung nempel ke rolnya tersebut
dan dia bisa lakukan operasi yang di sistem.
Kemudahannya bagi kita sebagai developer, kita tinggal define Control List-Control List ini
dan langsung diterapkan di code.
Dan ini bisa nambah terus, bisa kembang, kempis.
Tapi secara di codenya sudah ke hardcode.
Banyak kok yang pakai ACL ini, contohnya S3 bucket, itu kan ada pakai ACL kan?
Bisa di akses publik, hanya bisa di akses oleh department tertentu,
bisa di akses oleh yang administrator, segala macemnya.
Itu anamanya ACL.
Berarti ACL sama RBAC itu either/or ya?
Maksudnya itu dua approach yang berbeda. Atau bisa di-compliment?
Bisa di-compliment.
Kalau role-based, kita tentuin rolnya.
Kalau super admin bisa semua jelas, admin bisa semua, editor bisa.
Kita pilih, pick and choose bisa melakukan A, B, C, D, tapi nggak bisa E, F, G.
Terus kalau viewer bisa A, C, D, F, itu kan RBAC ya.
Tapi kalau ACL berarti kita nggak perlu memang, kita nggak perlu design ke role tertentu.
Bisa di-compliment juga.
Bisa berdiri sendiri.
Bukan approach yang berbeda ya, itu bisa di-combine.
Bisa di-combine, misalnya role A punya akses control list-nya, bisa dipakemin.
Misalnya role-nya editor, bisa banyak control list.
Role-nya A, B, C, D, bisa control list yang berbeda.
Tapi bisa berdiri sendiri juga, misalnya tadi yang nggak usah pake role, tapi yang si control list-nya ini langsung member ke user-nya.
Bisa juga.
Jadi bisa berdiri sendiri, bisa di-combine.
Oke, nah ini ada lagi A, B, A, C?
Nah ini saya nggak mengerti, belum pernah pake juga.
Contohnya kayak IAM, sampai sekarang saya nggak ngerti IAM.
Yang itu loh AWS, yang IAM kalau kita bikin ini.
AWS ya, AWS sama GCP.
Google Cloud juga IAM.
Identity and Access Management.
Sampai sekarang belum mengerti secara komplit.
Kalau dari jawaban si Gemini, A, B, A, C itu atribut based akses control.
Bedanya adalah, kalau R, B, A, C itu berdasarkan role, kalau A, B, A, C itu menggunakan atribut.
What, when, oh.
Where dan how? Oh, 4W1H.
Kayak ini ya, kayak bikin prokosal ya.
Musti ada...
Tunggu, itu ada artikelnya, tapi tetap gue nggak bisa buka.
Artikel.
R, B, A, C.
Okta, oh yang bawah ini.
Sama kan?
Nah itu dia.
Tetap nggak ngerti.
Cuma layout-nya bagus.
Zoom in dong.
Zoom in, bentar.
Role-based versus atribut based.
Nah kalau role-based kan lumayan jelas ya.
Masing-masing role punya list of privileges lah.
Boleh ngapain aja.
By role, tapi A, B, A, C determine access by user characteristics, object characteristics, action types.
Ini kita udah tau ya R, B, A, C ya.
Kita langsung ke A, B, A, C aja.
Atribut based access control.
Someone looks into your computer system.
Apa yang bisa dilakukan orang itu?
A, B, A, C menjawab pertanyaan itu melalui user atribut resource-nya atau environment-nya.
Nah contohnya user person's job title, typical task, or senior level.
Senior level.
Resource atribut.
Ketutupan.
Resource atribut jenis filenya.
Jika jenis filenya atau siapa yang membuatnya, atau tingkat sensitivitas document-nya.
Coba lihat intunya gambarnya.
Gak lepul sih gambarnya.
R, B, A, C.
Iya itu salah gambar.
Mana tadi?
Resource atribut environment.
Ini tuh kayak kondisional-kondisional gitu ya berarti. Jika filenya, blablabla, jika user-nya, title-nya, atau position-nya, blablabla.
Jika environment-nya adalah staging, berarti boleh melakukan hal ini, hal itu, dan hal itu.
Kayaknya ini lebih kompleks daripada R, B, A, C ya kayaknya.
Ada relationship juga.
Rodan cons.
Will define, control administrator can define.
Time constraint, defining variable.
Oh, A, B, A, C ini ada time constraint.
Jadi misalkan, saya kasih otorisasi untuk Ivan bisa edit 2 hari, hari ke-3 udah gak bisa lagi.
Oh iya, masuk akal sih.
Kan ada why, where, when, inti yang tadi kan.
Jadi dia ada lebih kompleks lah, lebih kompleks.
Kasih aksesnya cuma berapa hari atau berapa jam gitu.
Maksudnya, yes ada betulnya, tapi itu maksudnya sekarang kata kuncinya di atribut, ini coba gue share ini, penjelasannya si ini ya.
Jadi makin bingung ya.
A, B, A, C sama dengan P, B, A, C.
Ada lagi.
Apa lagi?
Gue suruh jelasin yang lebih mudah ya.
Atribut based access control.
Jadi ada intinya kalau otorisasi itu, allow access if condition are true.
Ini kata kuncinya ya.
Jadi semua otorisasi melakukan hal yang sama ya.
Nah, kondisinya itu ada 4 tipe.
Bisa user atribut, bisa resource atribut, nanti berdasarkan misalnya dokumennya berdasarkan apa.
Terus bisa action atribut dan environment atribut.
Itu atributnya.
Jadi kita bisa ngasih ke user tersebut berdasarkan atributnya.
Misalnya kita bisa anggap aja ya kepala department finance bisa ngedit semua user yang di dalam department finance.
Kita bisa ngasih itu ke kepala user yang mengapalai department finance.
Atau mungkin kalau user dari department finance boleh ngedit entry yang terkait keuangan,
tapi gak boleh tentang strategi atau coding atau apa ya?
Ya mungkin bisa ngedit yang entry.
Entry tadi keuangan payroll, tetapi gak bisa ngedit operation, ya department operation.
Fabrik lah contohnya ya.
Jadi bisa berdasarkan atribut department.
Atau bisa ngasih atribut per dokumen.
Jadi kalau dokumen keuangan hanya bisa diakses oleh user keuangan.
Atau bisa lagi, bisa berdasarkan action.
Contohnya kita bisa ngasih selama dia login, dia boleh read everything.
Kan tadi kondisinya, ini kan allow access if condition are true.
Jadi kalau read boleh, create gak boleh.
Nah ini yang tadi contohnya yang Mas Riza bilang, bisa akses dokumen atau write dokumen
dalam waktu tertentu itu environment attribute.
Contohnya, yang dia contohkan begini.
Employees can read dokumen only if the dokumen belong to the department.
Okay makes sense.
Allow login only during office hour.
Atau boleh ngedit presentasi hanya di office hour.
Nah itu contohnya lagi yang lain kan.
Nah itu A, B, A, C.
User can edit a task if user ID is a task owner ID.
Ini kalau kayak contoh apa?
To do list, to do list.
Boleh ngedit postingannya sendiri.
Oke ada lagi nih, ada REBAK.
Relationship Based Access Control.
Itu coba dibaca lagi.
Dipopularkan oleh Google Zanzibar.
Zanzibar.
Zanzibar itu apa?
Mana coba masukin ini screen lah.
Oh iya bentar.
Zanzibar.
Semi-autonomous Tanzanian Archipelago in the Indian Ocean.
Nah makanya bukan, kayaknya bukan itu.
Bukan, ini bentar disini.
Eh REBAK.
Benar kan? REBAK, relationship bukan role ya, relationship.
Ini punya Google katanya.
Only choice for access control.
Understand how REBAK system function.
Subject in REBAK.
Example, a developer's account. Example, automated service.
Ini subject ya.
Subject dan person.
Ini service.
Subject itu yang dimaksud dengan subject, bisa orang, bisa service.
Bisa misalnya bisa user, bisa service.
Object.
Next there is an object.
Object itu resource maksudnya.
Ini kayak modelnya ini persis kayak ini.
Kayak kalau saya baca dari CGPT, modelnya ini persis kayak Google Drive, rebak ini.
Jadi kita punya dokumen.
Kita bisa ngedit dokumen kita sendiri, dan kita bisa ngasih akses ke orang lain untuk bisa read only.
Bisa edit.
Atau komen, ya atau komen only.
Jadi relationship ceritanya.
User can edit dokumen if user is owner or collaborator.
GitHub juga hal yang sama, kalau kita ngasih GitHub collaborator.
Ini sama kayak ABHC tadi nggak sih?
Intinya sih sama-sama authorization.
Contoh ABHC tadi kan kalau user ID sama dengan task owner ID.
Berarti dia boleh ngedit.
Itu kan cara lain untuk bilang bisa ngedit tasknya sendiri kan.
Atau bisa ngedit resourcenya sendiri.
Kalau, ya maksudnya mirip sih secara pemahaman.
Karena kalau di ABHC, kalau di pemahaman saya, role-nya itu, sorry nggak ada role di ABHC.
Di kondisinya itu terjadi jika kita sudah dipakemkan.
Kita bisa edit file itu kalau kita di department itu.
Sedangkan kalau yang di RBHC, Rebac ini, saya mengerti kita bisa invite orang luar selama dia collaborator, dia bisa ngedit kita punya.
Masih bingung sih saya jelasinnya.
Eh bentar, gimana kalau tanya ke chat GPT, suruh bikin satu tabel, bandingin ketiga approach tadi, RBHC, ABHC, sama Rebac.
Terus suruh kasih use case, jadi use case yang sama.
Bagaimana cara approachnya kalau pakai RBHC, kalau pakai ABHC sama, kalau pakai Rebac.
Rebac itu ada parent child.
Jika parent kita dapat akses, childnya dapat akses.
Nggak kayak Google Docs dong, Google Docs nggak ada parent access kan.
Bisa kita kasih akses untuk satu department.
Nah yang dimaksud parent child itu action yang diperbolehkan, atau subjectnya, atau objectnya kan bisa aja.
Folder ya, oh benar juga.
Kalau foldernya kita kasih akses, semua isi file dari folder itu dapat akses inherit akses yang sama.
Oh iya iya iya, tapi tetap nggak parah.
Coba tunggu jawabannya chat GPT.
Kita soalnya bikin sistemnya belum yang sekompleks-sekompleks kayak gimana ya untuk hak akses ya.
Maksudnya yang bikin sendiri, kalau kita yang pakai.
Sejujurnya sebagai front-end dev, belum pernah bikin sistem desain yang rumit banget sih.
Cuma paham role, sama satu lagi yang belum teradres di sini.
Mungkin secara resmi nggak masuk authorization ya.
Nanti dibahas kepisah aja adalah scopes.
Kalau old kan ada scopes.
- Kelihatan nggak? - Cuma pernah pakai itu.
- Kelihatan tapi bukan. - Gak, gue ini dulu.
- Dah, coba. - Kok nggak masuk?
- Di remove dulu, dah. - Unauthorized.
Dah.
- Kekecilan ya? - Iya.
- Gede nggak? - RBAC Permission R-Group Into Roles.
Jadi gue suruh make table comparison tiga ini, only core differentiation.
Mana ini ya? Oh, ini re-bug.
- RBAC Permission R-Group Into Roles. - Itu udah paling paham sih RBAC.
Ini yang paling mudah ya. Kayak paling sering kita bikin.
- Ini paling sering kita bikin kan. - Kalo admin bisa melakukan semua.
Jadi editor bisa ini, ini, ini, viewer bisa ini, ini, ya dan seterusnya.
Kalo ABAC itu SAS.
Simple Mental Model.
What role does the user have?
Do the attribute satisfy the rule?
- ABAC mulai paham sih. - What relationship exists between objects?
Iya, ianya mulai agak ngerti sedikit sekarang.
Ini scenario yang sama, editor bisa edit dokumen.
Iya, editor kan, ABAC, allow edit if user department sama dokumen.
Kalo ini pake condition, jadi ngeceknya dari kondisional.
Apakah department yang sama atau user ID sama dengan task owner ID.
Tapi pake conditional list of attributes.
Kalo ini ngecek relasi antara user dan kalo re-bug ini ngecek relasi user.
Allow edit if user is collaborator of document.
Resensit graph user, collaborator, dokumen.
Only collaborators can edit dokumen.
Jadi sebenernya sama aja, secara hasilnya user finance employee bisa edit dokumen.
Kalo di re-bug kan, berarti seluruh finance employee adalah collaborator dari finance dokumen.
Kalo di re-bug kan.
Tetapi di sistem re-bug kita bisa aja ngasih di luar finance bisa ngakses dokumen tertentu.
Jika mereka dikasih collaborator.
Ini lebih ke definisinya ya, re-bug itu mendefinisikan seseorang adalah collaborator atau bukan.
Antara si user dan antara subjek dan resource yang mau diberi action.
Itu berarti harus ada suatu relasi tertentu.
Relasi apa ya, berarti kan bisa sebagai collaborator.
Kayak kitab repo, re-bug tuh.
Collaborator.
Dan di collaboratornya di GitHub kan kita bisa ngasih, dia bisa read only, bisa write access,
bisa admin access kan di repo-nya.
Nah itu kan berarti sebetulnya semacam, semacam ya, semacam role juga kan.
-Role juga. -Kalau collaborator itu kan cuma contoh yang kamen ya.
Tapi kan sebetulnya bisa kayak, kalo di GitHub repo kan, ada yang cuma bisa nge-push kode,
tapi ga bisa nge-app lainnya, atau ga bisa, ya apalah ga bisa force-push ke main, dan lain-lain.
Gak bisa ngubah setting.
Berarti kan misalnya ada, kalo Google Drive lah yang simpel, ada viewer,
-commenter, sama editor kan. -Sama editor, ya.
-Sama owner pastinya. -Owner ya.
Tapi maksudnya relation yang bisa dikasih gitu,
ya maksudnya collaborator tuh sekadar contoh, tapi ini kan bisa dikustom kan.
-Kalo Google Drive berarti ada viewer, ada editor. -Oh iya, iya, iya.
Kalo RPC, begitu user login, dia udah dapet rolnya, oh saya editor, jadi saya bisa edit gitu kan.
Tapi kalo di ribak, tergantung sama dokumennya, sama objeknya.
-Kalo kita... -Relation nya, dikasih ga process nya?
Bisa edit ga? Oh cuma bisa liat, atau cuma bisa comment.
Berarti hubungannya kita sama dokumen itu adalah apakah editor, collaborator, atau viewer.
Atau commenter gitu ya.
Dan itu bisa adhokkan maksudnya gini, misalnya sesama user dengan tasta yang sama lah.
Maksudnya misalnya sesama user dari departemen yang sama, atau dari level yang sama.
Tapi kan bisa aja, kita nge-share file Google Drive kita cuma ke satu user ini.
Berarti si user itu bisa mengakses dokumennya kan, misalnya bisa nge-view filenya.
Walaupun sebetulnya kalo dari segi rol kan dia sama aja kayak user lain yang, apa, jenis user rolnya sama.
Atau kalo based on ABAC, misalnya departemennya sama, lokasinya sama, dan lain-lain.
Tapi hal yang dilakukan bisa berbeda, karena khusus satu user ini udah dikasih akses sebagai collaborator atau viewer dari satu file tertentu.
Bisa aja user lain, yang privilege-nya sama, atau level-nya sama, apalah departemennya sama, dikasih akses ke file yang lain lagi.
Jadi itu kayak bisa lebih custom ya, lebih random.
Tapi kekurangannya adalah ribak ini gak bisa, misalkan kasih, oh, saya kasih, kamu jadi collaborator.
Gak bisa. Gak, saya kasih kamu roles untuk, apa, relationship untuk mengubah dokumen ini untuk jadi collaborator.
Tapi 2 hari aja, gak ada kan, gak bisa kan. Harus manual, harus manual.
- Gak bisa ya. - Harus manual. 2 hari kemudian kita ganti lagi.
- Iya, kita ganti rolnya kan. - Eh, ganti relationship-nya, iya.
Jadi kelebihannya ABAC mungkin ke situ ya. Kita bisa banyak variable-nya, gak cuma kasih akses doang, tapi ada variable yang lain.
- Iya, itu kan kita ngomongin ini. - Terlebih asyik dari yang sama.
Scroll ke bawah, key architecture difference-nya apa? RBAC role permission tables, yaitu paham.
ABAC, nah, kalau ABAC itu berarti logic-nya agak susah di store di table ya, kalau RBAC kan statis ya.
- Berarti role ini bisa itu. - ABAC itu justru gak bisa dynamis, dia langsung kayak pemahaman gue seperti di hardcoded.
- Iya, hardcoded. - RBAC.
- Jadi bisa di hardcoded. - Nah, kalau sisanya kan banyak kondisionalnya gitu kan.
Iya, jadi banyak, misalnya mau buka dokumen ini, usernya boleh edit gak? Gitu, langsung di cek. Usernya ada di department yang sama gak? Kita ceknya di kode malah.
- Kode. - Nah, kalau RBAC itu satu tabel lagi khusus buat nge-store relasinya kan, user ini punya relasi apa terhadap file ini, iya kan?
Sepahaman gue begitu.
AWS IAM Policies
Oke.
- Oke, lanjut. - Lanjut.
- Jadi ngerti kan? - Sedikit.
- Kalau suruh nerapin, ngerti sama-sama lah. - Lumayan, lumayan, lumayan.
- Kalau interview terus suruh ngerangin, ya semoga, ya bisa sih asalnya suruh bikin. Suruh bikin masih bingung. - Iya, sama nih.
Gimana cara bikinnya kalau pake query ke database gitu-gitu gimana? Graphic kan tadi, RBAC itu kan?
- Iya, graph. - Apa namanya? Relationship. Itu biasanya lebih mudah menggunakan graph database.
- Graph QL dong. - Bukan.
Graph database itu salah satunya Neo4j. Ada lagi nggak sih yang graph database?
- Mongo? MongoDB? - Mongo, bukan. Mongo itu dokumen database.
- Itu key value, maksudnya. - Iya. Eh, bukan key value. Dokumen-dokumen.
Object, object, object.
Neo4j sih yang paling populer ya. Jadi Neo4j itu, dia menggambarkan database-nya bukan berdasarkan table, skema, dan lain-lain.
Dia pakai relationship. Ya itu. RBAC itu jadinya.
Kalo misalkan temen-temen bikin sosial media kayak Facebook, Twitter gitu. Nah itu kemungkinan menggunakan graph database.
Karena dia bisa dapet tuh gambarannya. Si ini temenan sama si ini, mutual friend-nya siapa?
Kalau gue nih sensor ada second degree.
Second degree. Di link ini juga ada second degree. Itu menggunakan graph database.
Nah kalau itu query-nya gampang. Bukan gampang sih. Lebih mudah lah.
Daripada kalau kita menggambarkan itu di relationship database.
Relational. Padahal namanya relational ya. Sama-sama ada hubungan gitu ya. Tapi beda ya.
Ya bisa itu sih setiap relation jadi satu row.
Ya itu tadi satu tabel bisa buat nge-store ID subject sama ID resource.
Pakai database biasa kali ya coba ya. Make a simple database schema.
Enggak lah. Langsung ke chip-cipitnya aja.
Bikin aplikasi langsung. Weh gila. Mantap.
Buat lah aplikasi seperti Google Drive. Kayak abstract web.
Ini apa? Gue suruh bikin untuk...
Mana mana mana? Shared screen.
Shared screen.
Ngumpung chat-jpt-nya gratis.
Gak kalau yang enterprise yang instant ini gak terbatas.
Tapi kodexnya terbatas.
Cerecon. Cerecon.
Cuma kalau pakai buat chatting-nya aja begini kalau nanya-nanya kayaknya gak bisa abis ininya.
Understandingly back, dia gue suruh bikin simple database schema.
Tuh dia pakai mana dia...
Suruh pakai ini ya.
Relationship. Apa? Relasional database.
Iya. Make mermaid schema gitu ya.
Bisa gak sih mermaid di sini?
Bisa. Atau saya bisa? Make mermaid diagram.
Describe the relation with mermaid diagram.
Ya elah. Mana? Oh ini ada sabar dong.
Di Rd ini ya Rd. Dia itu dulu. Rendering dulu. Rendering.
Loading.
Nah itu berarti...
Oke. User. Jadi tiga entity ya. User, Department, Dokumen.
Kenapa labelnya gak kelihatan ya? Coba di-select deh.
Label relasinya kotak putih.
Kan harus di-select.
Oh emang gak ada isinya gitu?
Iya.
Nah terus gunanya buat apa itu?
Tau deh. Preview, kode, edit.
Itu play apaan play?
Preview.
Bisa kode.
Dalamnya ada tuh dokumen membership.
Member all sama as member.
Kayaknya gara-gara ini deh.
Coba.
Gak sih light mode.
Dimana liatnya?
Oh gak ada ya?
Gak tahu. Ya udahlah.
Jangan-jangan nanti muncul semua data-datanya.
User, Department, Dokumen. Department punya dokumen nih.
User dan Department.
User adalah anggota dari suatu department.
Satu atau lebih department.
Ya user sama department kan end-to-end ya?
Many-to-many.
Many-to-many.
User ke dokumen juga many-to-many.
Department one to many.
Ya iya.
Jadi.
Ya gimana? Bingung saja saya bacanya.
How authorization work with this game?
Ini contoh rebak atau contoh?
Rebak.
Rebak tapi pakai relationship database.
Itu kan di satu tabel khusus buat nge-store relationship.
Yang kanan bawah itu.
Yang kan tadi, nge-store user ID sama resource ID, dokumen ID.
Itu kan di kanan bawah maksud saya.
Ini.
Jadi user A, user ID 1 adalah kolaborator dari file ini.
Adalah viewer dari file itu.
Relation-nya ya?
Jadi contohnya user Alice, department finance, Bob engineering.
Meaning Alice member of finance.
Terus dokumen, budget.
Ininya Alice owner.
Bob viewer.
Alice owner ini, Bob ini.
Oh bisa ya?
Kalau misalnya, oh ini nih, berarti gini ya.
Tadi kan user-nya Alice, dokumennya budget.
Alice itu user ID Alice, dokumen budget, relasinya owner.
Terus kalau si Bob dan si budget, relasinya viewer.
Terus editor can modify.
Berarti relasinya kalau dia owner dan editor, bisa.
Ini berarti di-code ini.
Dan maksudnya intinya adalah tabel yang kanan bawah itu bisa di-update.
Row-nya bisa di-update tanpa mengubah data si user.
Tanpa meng-update, kita nggak perlu meng-update user atau user role.
Atau dokumen atau dokumen atribut.
Nggak perlu meng-update file-nya dari dokumen.
Misalnya si Alice ngasih akses ke Bob untuk suatu dokumen tertentu, dokumen khusus.
Yang di-update berarti kan tabel kanan bawah itu tabel dokumen relationship aja.
User role-nya nggak berubah.
Dokumen atribut atau user atribut, user field apapun nggak berubah.
Cuma tabel dokumen relationship itu doang yang berubah.
Oh, ngerti-ngerti wah.
Bangga. Aku anak-anak.
Wih, emang kayaknya.
Yang owner sama viewer ini itu di-relasen ini.
Ini pengaturnya.
Relasen bug-nya itu, relasen BAC-nya itu ini.
Satu kolum ini.
Oke.
Ada lagi nggak? Ini komentar-komentar.
Oh iya, semoga sama pemikirannya ABAC sama PBAC.
PBAC itu sama emang istilah lain dari ABAC.
Oh istilah lain dari ABAC.
Bedanya middleware, policy, atau gate.
Soalnya di Laravel ada semua.
Laravel yang buat otorisasi ya?
Eh kan yang pakai Laravel gimana?
Nggak tahu. Nggak serumit itu.
Soalnya nggak pakai fitur-fitur itu sih.
Karena semua pakai res API service external.
Cuma itu kayak existing Laravel site, nggak boleh dibongkar.
Semua yang bikin itu udah nggak ada semua.
Iya, mesti nggak perlu dipindahin.
Tapi sebenarnya pakai API, pakai service terpisah.
Ya, cuma pakai middleware aja.
Jangan cek kan udah ada autentic.
Nggak perlu dimaintain itu.
Keren juga ya.
Yang mana nggak perlu dimaintain?
Itu, yang legacy Laravel itu. Perlu dimaintain nggak?
Sempat ngalamin kayak nge-bug gitu nggak?
Cuma controller, view.
Pake middleware sih, middleware buat out.
Nggak, tapi service-nya semua external.
Iya, maksudnya pernah ngalamin broken nggak?
Pernah ngalamin broken nggak?
Aplikasinya bagus.
Maksudnya nggak ada bugs, nggak ada bugs kan?
Pernah ketemu bugs nggak?
Ya bugs ada, cuma bugs-nya ya maksudnya apalah misalnya
salah pasang cash atau punya hal yang bisa dijelasin.
Salah perhitungan misalkan, nggak ada kan?
Salah bisnis logik misalnya.
Salah bisnis logik, betul.
Tapi maksudnya bukan yang kayak bug misterius
gara-gara nggak tahu ini dari mana.
Terus yang sampai apa?
Yang serem kan, maksudnya yang susah,
yang berlarut-larut panjang kan bug misteri yang kayak gitu kan.
Jadi random ininya diubah, nanti malah itu yang rusak.
Nah itu yang males banget.
Kalau di kasus ini nggak sih?
Nggak ya, berarti aplikasinya keren itu.
Bagus, bagus.
Nggak perlu di-maintain.
Jarang kan ada software yang tidak perlu di-maintain.
Ada, banyak.
Banyak.
Oke, saya revisi.
Jarang ada aplikasi buatan kita yang tidak perlu di-maintain.
Maksudnya buatan saya.
Kalau apa ya, aplikasi kayak VLC media player atau 7zip.
Eh tetap di-maintain, ada update loh.
7zip, 7zip, 7zip.
7zip, ada, ada versi nya.
Ada, ada versi nya.
Ada ya?
Ada, cuman kita nggak ngehaja sekarang.
Orang tinggal klik apa, software update atau apa gitu.
Dimana sih dia ini?
Dia host, nggak tahu ya dimana ya?
Nggak tahu.
Ada yang tahu ini nggak sih The Code Project jaman dulu?
Code Project?
Nggak, apa itu?
Jaman dulu GitHub kan belum ada.
Kalau saya dulu mau nge-host open source ini namanya Code Project.
Nggak, nggak tahu.
Nggak ngalamin.
Saya anak jaman dulu berarti.
Dulu sebelum Git saya pakai SPN sama CVS.
Pernah dengar kata code.google nggak jaman dulu?
Kan ada kan code.google?
Oh iya, iya. Kalau itu tahu, punya Google kan.
Maksudnya jaman dulu sebelum ada GitHub, macem-macem tuh tempat menaruh.
Source code?
Source code untuk yang open source.
Source artinya Code Project. Dulu saya tahu di Windows segala macem ada di sana.
Oh kalau Code Project nggak tahu.
Source force itu kan buat taruh source code tapi di zip kan?
Kayak di target zip gitu kan?
Iya.
Nggak ada versiannya, nggak ada versiannya, kontrolnya.
Ini nih Code Project jaman dulu.
Tar, tar, tar. Share screen, Code Project.
Nggak bisa sih, harus Windows.
Bisa lihat?
Hampir.
Ini Code Project yang ini di Wikipedianya jaman dulu.
Code Project, The Code Project.
Tapi ini sudah nggak ada lagi.
Sudah nggak bisa. Web Archive dong, Web Archive.
Niat banget.
webarchive.codeproject.com
Nggak bisa juga.
Eh Web Archive-nya nggak ada.
Bukan Web Archive itu.
Web Archive. Nah way back machine.
Lagi ini Sekar lagi ajeb.
Masih ada 2025.
Iya dia akhirnya putus di 2025.
Terakhir ya.
Udah nyarah.
Puasa-puasa buka ya?
Buka apa?
Itu ajojing.
Ajojing sih. Ini kafe.
Oh kafe.
Ini Code Project.
Oh nggak pernah, nggak pernah ngerasain.
Kalo kayak Stack Overflow.
Iya ini sudah jauh berubah.
Kalo jaman dulunya kan kita bisa download.
Bisa download C++, terus kita compile sendiri.
Banyak lah hal-hal yang bisa.
Tokus sekarang jadi AI sih.
Iya, kayak ada perubahan.
Ya nggak tahu deh ya perubahan perubahan.
Oke.
Community, programming language, ya begitulah.
Ya udah nggak ada.
Saya sendiri udah jarang buka sih.
Banyak hal-hal yang disana dulu dapet projek-projek open source.
Sebelum eranya GitHub ya berarti ya.
Iya.
Eh minggu depan kita masih live nggak sih?
Libur dulu apa ya? Kan udah pada join holiday.
Liburnya rambu sih.
Oh live terakhir.
Gak, libur dulu aja lah.
Berarti liburnya 2 minggu ya?
17 sama 24.
Boleh.
Kita live lagi tanggal 31.
Yes.
Oke. Berarti kita pilih topik untuk tanggal 31.
Iya.
Ini dia. Eh nggak ada.
Mas Riza.
Sedang redesign.
Ada 2 yang mana.
Apa ini 2?
Jadi mas Riza melakukan 2 redesign.
Oh 2.
Satu lagi yang glass morphism kind of style.
Yang ini kayaknya keren.
Oke. Yang satu lagi saya batalin aja ya.
Batalin aja iya iya.
Terlalu rajin.
Karena konflik.
Terlalu rajin.
Terlalu rajin memecut AI.
Nggak mau rugi ya. Udah terlanjur bayar.
Nggak mau rugi.
Udah terlanjur.
Mcode-nya dapat 2 kali lipat.
Jadi harus diambilkan.
Nggak mau banget.
Enak sih bisa punya Mcode.
Saya nggak punya.
Eka juga nggak dapat ya.
Dia nggak dapat sih.
Kan udah dikasih tahu udah lama.
Nggak ngikut ya.
Dapat ini sih dapet.
Majeki di tempat yang lain.
Iya dari kantor kan dapet.
Github Copilot.
Github Copilot.
Kalau teman-teman punya project open source yang cukup terkenal.
Kemungkinan besar kita teman-teman bisa dapet.
Akses ke Github Copilot.
Walaupun ada batasannya juga ya.
Lumayan lho 300 spin.
Sebulan.
Lumayan saya nggak bisa habis ini sampai sekarang.
Oke. Kita pilih topik.
Spin the wheel.
Atau pick random.
Terserah.
Spin.
Spin aja.
Spin.
Biar nggak membasir rodanya.
Pusing ya?
Project Management Tool.
Uy boleh nih.
Jira, Github, Project.
Jira, linear.
Oh sekaligus di...
Sekaligus di konekin sama ini ya.
Apa?
Bagaimana memanage project AI.
Pakai apa? Visi atau apa sekarang?
Linear ya.
Beats.
Beats.
Yang lagi trending. Saat ini ya pakai linear.
Linear. Oh linear ya.
Iya.
Microsoft Project.
Ada yang pakai Microsoft Project.
Notion, betul.
Keren banget lho sih Github Copilot.
Ih saya jadi ambasadur lama-lamanya.
Nah itu kenapa dikasih gratisan.
Tujuannya kan biar kayak gitu.
Kenapa?
Jadi kalau sudah saya dapat punya Github Copilot Subscription nih.
Jadi saya bisa pakai Agent Mode langsung di Github isunya.
Langsung kayak saya bisa assign Github isunya apa, assign Copilot, udah tinggal tidur.
Besoknya dia udah selesai, saya bikin PR-nya.
Jadi Agent Management-nya lewat Github ya?
Jadi nggak hanya CLI, jadi bisa langsung di github.com-nya. Keren sih.
Kan CloudCode juga bisa Pak, kayak gitu.
Tapi kan CloudCode dianya konek dari si Cloud.ai, nge-fetch kita punya repo.
Bukan, enggak. Kita tinggal mention aja. Cloud, si Cloudbot, tolong fix isu ini.
Kalau kita kasih akses.
Iya saya cuma karena CloudCode lebih mahal, banget.
Sedangkan Github Copilot berikan saya gratis, saya pakai Copilot.
Seperti kemarin-kemarin ya, antara VSCode dan Copilot sama Cursor,
begitu juga Copilot CLI atau fitur-fitur yang lain sama CloudCode,
itu kayak masih kejar-mengejar lah, belum memimpin si Copilot ini.
Dia nggak punya diferenciasi lah, bisa dibilang kayak gitu.
- Soon kayaknya ini sih, dia punya, karena si Copilot kan punya Github,
Github punya Microsoft, dia punya ekosistem.
- Dan punya power, bukan power, resource yang tidak terbatas, bisa dibilang tidak terbatas.
- Microsoft bilang, oke semuanya pakai Copilot by default, udah jadi kayak EA aja udah.
- Bukannya sekarang udah ya, udah keinstall semua Copilot itu.
Copilot ini ya, Copilot Microsoft ya, bukan Github Copilot.
- Jadi semua Windows dan Microsoft pasut kan, kayak Clippy, jadi kayak Clippy, tapi versi AI.
- Oh iya bener, di browsernya juga udah ada.
- Yang untuk ini pasti nggak tau Clippy itu apa lah, nggak kejamanin, jangan-jangan.
- Itu AI pertama, yang consumer level, consumer level.
- Baiklah, project manajemen ini.
- Oke, untuk malam ini, project manajemen kita bahas untuk tanggal 30 berapa tadi?
Untuk tanggal 31 ya, akhir bulan.
- Kita rekaman nggak?
- Gak, rekaman yang singkat itu loh.
- Oh, latensi, latensi.
- Iya, iya, iya.
- Iya minggu depan lah, atau iya minggu ini juga nggak apa-apa.
- Iya nanti dia sapa yang gampang.
- Oke, kalau gitu, terima kasih banyak untuk malam ini.
Kita ketemu lagi, tanggal 31 Maret.
Selamat puasa, selamat lebaran, yang mudik, hati-hati di jalan, semoga kembali dalam keadaan sehat.
Walaafiat bisa berkegiatan lagi ya.
- Puasanya lancar juga.
- Yes.
- T.H.R. nya cepet turun.
- T.H.R. nya cepet turun.
Banyak nih doa saya, sebentar saya mau doain.
Puasanya lancar, perang selesai, dolar turun.
- Amin, amin, winter.
- Winter selesai, AI-AI selesai makin banyak.
- Amin.
- Mulai mudik, aman-aman, nggak ada yang aneh-aneh di jalan.
- Amin.
- Banyak ya.
- Banyak.
- Ya sudah, selamat malam, bye bye.
Atau mungkin telah kesekian kali melihat untuk membandingkan kembali dengan lainnya?
Jika Anda mencari tahu mengenai layanan web hosting terbaik, kami pastikan Anda berada di tempat yang tepat.
Dengan Domainizia, dapatkan pengalaman menggunakan layanan hosting yang lebih baik.
Dengan SSD berperforma tinggi dalam infrastruktur cloud yang telah dioptimalkan untuk kebutuhan personal maupun bisnis.
Teknologi ini memungkinkan Anda memperoleh layanan yang lebih stabil serta proteksi dari korupsi data.
Hosting Domainizia juga telah mendukung Node.js, Python, Ruby, Go, PHP, Java serta binary Linux.
Lebih dari 200.000 pelanggan telah mempercayakan layanan hosting di Domainizia.
Kepercayaan yang kami jaga dengan garansi uptime 99,9% serta garansi uang kembali 100%.
Buat website Anda lebih mendingan, segera berali web hosting Domainizia.
Deskripsi asli dari YouTube
Episode kali ini hasil kolaborasi bareng DomaiNesia 🎉 📦 Langganan Cloud VPS Turbo? Gunakan kode: NGOBROLINVPSDN → 50% OFF, bisa digunakan berkali-kali! Kita akan mulai mengudara jam 21:00WIB. Mundur 1 jam dari jadwal biasanya karena bulan ramadan. Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
3 Jul 2024
Ngobrolin Elixir
Episode ini membahas tentang Elixir, bahasa pemrograman fungsional yang berjalan di BEAM (Erlang Virtual Machine), bersa...
1 Okt 2025
File Upload Strategy
Episode ini membahas berbagai strategi upload file dalam pengembangan aplikasi web. Eka dan Ivan berdiskusi tentang trad...
17 Jan 2024
Ngobrolin Form
Episode ini membahas secara mendalam tentang formulir (forms) dalam pengembangan web, yang ternyata jauh lebih kompleks ...
Suka episode ini?
Episode baru setiap Selasa malam. Dengarkan lewat YouTube, Spotify, atau feed podcast favoritmu.
Memuat komentar dari GitHub Discussions...
Jika komentar tidak muncul karena ekstensi privasi / adblocker, kamu bisa berdiskusi langsung di GitHub Discussions .