Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. WordPress

WP REST API: Menyiapkan dan Menggunakan OAuth 1.0a Authentication

by
Read Time:15 minsLanguages:
This post is part of a series called Introducing the WP REST API.
WP REST API: Setting Up and Using Basic Authentication
WP REST API: Retrieving Data

Indonesian (Bahasa Indonesia) translation by Hasannudin Amin (you can also view the original English article)

Di bagian sebelumnya dari seri, kita mengatur otentikasi HTTP dasar pada server dengan menginstal plugin yang tersedia di GitHub oleh tim WP REST API. Metode otentikasi dasar memungkinkan kita mengirim permintaan yang dikonfirmasi dengan mengirim kredensial masuk di header permintaan. Meskipun cepat dan praktis, ada kemungkinan kredensial ini jatuh ke tangan yang salah. Oleh karena itu metode ini hanya boleh digunakan pada jaringan aman untuk tujuan pengembangan dan pengujian saja.

Untuk menggunakan otentikasi pada server produksi, perlu ada cara yang lebih aman untuk mengirim permintaan yang diautentikasi tanpa berisiko mengekspos kredensial masuk. Berkat metode otentikasi OAuth, permintaan tersebut dapat dikirim tanpa memperlihatkan nama pengguna dan kata sandi dengan cara yang tidak aman.

Di bagian saat ini dari seri, kita akan belajar untuk mengatur dan menggunakan metode otentikasi OAuth untuk digunakan dengan plugin WP REST API. Untuk lebih spesifik, kita akan:

  • ambil ikhtisar tentang metode autentikasi OAuth dan cara kerjanya
  • instal plugin server OAuth
  • menghasilkan token akses OAuth untuk digunakan di aplikasi kita

Mari mulai dengan memperkenalkan diri pada metode autentikasi OAuth.

Memperkenalkan Otentikasi OAuth

Apa yang Anda lakukan ketika Anda harus masuk ke admin WordPress Anda? Anda cukup pergi ke halaman login dan masukkan kredensial login Anda, bukan? Sesederhana itu! Tetapi bagaimana jika Anda menggunakan layanan pihak ketiga yang membutuhkan akses ke sumber daya WordPress Anda (posting, halaman, media, atau apa pun)? Apakah Anda akan menyerahkan kredensial login Anda ke layanan itu, mengetahui bahwa mereka mungkin berakhir di tangan yang salah setiap kali integritas dari layanan tersebut dikompromikan? Jawabannya tentu "Tidak".

Dalam model otentikasi tradisional, ada dua peran:

  1. Klien: dapat berupa pengguna, aplikasi, atau layanan
  2. Penyedia sumber daya: server tempat sumber daya yang dilindungi berada

Jika klien ingin mengakses sumber daya yang dilindungi, ia akan mendapatkan autentikasi dengan memberikan kredensial yang sesuai ke server dan akan diberikan akses.

Masalah muncul ketika layanan pihak ketiga membutuhkan akses ke sumber daya yang dilindungi ini di server. Layanan ini tidak dapat (dan tidak boleh) diberikan kredensial oleh pengguna untuk mengakses sumber daya. Memberikan kredensial kepada pihak ketiga berarti memberikan kendali penuh atas sumber daya yang terletak di server.

Di situlah metodologi otentikasi OAuth datang untuk menyelamatkan. Ini memperkenalkan peran baru dalam proses autentikasi, dan itu adalah pemilik sumber daya. Sekarang ada tiga peran dalam proses otentikasi:

  1. Klien: bukan pengguna itu sendiri tetapi aplikasi atau layanan pihak ketiga yang bertindak atas nama pengguna dan mengakses sumber daya yang dilindungi
  2. Server: server tempat sumber daya yang dilindungi berada
  3. Pemilik sumber daya: pengguna itu sendiri

Tiga peran di atas bersama-sama membuat apa yang disebut sebagai otentikasi OAuth tiga-kaki. Jumlah kaki menentukan peran yang terlibat dalam proses otentikasi. Ketika pemilik sumber daya juga merupakan klien, alirannya dikenal sebagai otentikasi dua-kaki.

Menurut Webopedia:

OAuth adalah standar otorisasi terbuka yang digunakan untuk menyediakan akses aplikasi klien yang aman ke sumber daya server. Framework otorisasi OAuth memungkinkan aplikasi pihak ketiga untuk mendapatkan akses terbatas ke layanan HTTP, baik atas nama pemilik sumber daya atau dengan mengizinkan aplikasi pihak ketiga untuk mendapatkan akses atas namanya sendiri.
OAuth memungkinkan pemilik server memberi otorisasi akses ke sumber daya server tanpa berbagi kredensial. Ini berarti pengguna dapat memberikan akses ke sumber daya pribadi dari satu server ke sumber daya server lain tanpa membagikan identitasnya.

Karenanya dalam alur autentikasi OAuth, pengguna tidak perlu memaparkan kredensial tetapi dapat mengotorisasi klien untuk bertindak atas namanya, memutuskan sumber daya apa yang dapat diakses oleh klien. Dengan kata lain, ketika tidak memberikan kredensial login, pengguna juga dapat menentukan ruang lingkup akses yang diberikan klien.

Ini tidak hanya memungkinkan situs web tetapi juga aplikasi desktop dan seluler untuk mendapatkan akses terbatas ke sumber daya di server.

Dalam hal WordPress, OAuth menginformasikan penyedia sumber daya (instalasi WordPress) bahwa pemilik sumber daya (pengguna WordPress) telah memberikan izin untuk mengakses aplikasi pihak ketiga untuk mengakses sumber daya mereka. Sumber daya ini bisa berupa pos, halaman, taksonomi dan media, dll. Izin ini bisa untuk akses terbatas atau lengkap, seperti yang akan kita lihat nanti di tutorial ini.

Bagaimana Alur Otentikasi OAuth Bekerja

OAuth Authentication API untuk WordPress dibangun di atas spesifikasi OAuth 1.0a, maka kita akan melihat bagaimana OAuth 1.0a bekerja.

OAuth bekerja dengan menggunakan kredensial token yang dikeluarkan oleh penyedia sumber daya (server), atas permintaan pemilik sumber daya setelah mengautentikasi dirinya sendiri dengan menggunakan kredensial. Token ini—yang terkait dengan pemilik sumber daya—kemudian digunakan oleh klien (aplikasi atau layanan pihak ketiga) untuk mendapatkan akses ke sumber daya yang dilindungi.

Kredensial token ini memiliki masa hidup terbatas dan dapat dicabut oleh server atas permintaan pemilik sumber daya.

Alur OAuth berjalan sebagai berikut:

  1. Klien mengirimkan permintaan yang ditandatangani ke server untuk mendapatkan Request Token, juga dikenal sebagai Temporary Credentials. Permintaan ini dikirim ke URI titik akhir Temporary Credentials, dan berisi hal-hal berikut:
    • oauth_consumer_key: disediakan oleh server
    • oauth_timestamp
    • oauth_nonce
    • oauth_signature
    • oauth_signature_method
    • oath_callback
    • oauth_version (opsional)
  2. Server memverifikasi permintaan dan jika itu valid, memberikan Request Token yang berisi:
    • oauth_token
    • oauth_token_secret
    • oauth_callback_confirmed
  3. Klien kemudian mengirim pemilik sumber daya (pengguna) ke server untuk mengotorisasi permintaan. Ini dilakukan dengan membangun URI permintaan dengan menambahkan oauth_token yang diperoleh pada langkah sebelumnya ke URI titik akhir Resource Owner Authorization.
  4. Pemilik sumber daya (pengguna) memberi otorisasi di server dengan memberikan kredensial.
  5. Jika URI oauth_callback disediakan di langkah pertama, server akan mengarahkan klien ke URI tersebut dan menambahkan yang berikut sebagai string kueri:
    • oauth_token: diperoleh pada langkah kedua
    • oauth_verifier: digunakan untuk memastikan bahwa pemilik sumber daya yang memberikan akses yang sama dikembalikan ke klien
  6. Jika URI oauth_callback tidak diberikan pada langkah pertama, maka server menampilkan nilai oauth_verifier sehingga pemilik sumber daya dapat memberi tahu klien secara manual.
  7. Setelah menerima oauth_verfier, klien meminta server untuk kredensial token dengan mengirimkan permintaan ke URI titik akhir Token Request. Permintaan ini berisi yang berikut:
    • oauth_token: diperoleh pada langkah kedua
    • oauth_verfier: diperoleh pada langkah sebelumnya
    • oauth_consumer_key: disediakan oleh penyedia sumber daya (server), sebelum memulai jabat tangan oauth
    • oauth_signature
    • oauth_signature_method
    • oauth_nonce
    • oauth_version
  8. Server memverifikasi permintaan dan memberikan yang berikut, yang dikenal sebagai Token Credential:
    • oauth_token
    • oauth_token_secret
  9. Klien kemudian menggunakan Token Kredensial untuk mengakses sumber daya yang dilindungi di server.

Informasi di atas dapat diangkut dengan string kueri yang ditambahkan untuk meminta URI atau dengan menyertakannya di header Authorization meskipun yang terakhir disarankan karena keamanan yang lebih baik.

Ini adalah proses yang panjang dan harus diperhitungkan ketika mengembangkan klien kita sendiri untuk berinteraksi dengan API. Tujuan klien adalah untuk mengelola semua jargon ini dan memfasilitasi pengguna dalam proses otentikasi. Karena kita akan menggunakan paket yang disediakan oleh tim WP REST API, rincian di atas akan diabstraksikan dan kita akan dapat memperoleh kredensial token dalam jumlah langkah minimum.

Dalam pembahasan di atas, kami menemukan tiga URI titik akhir, yaitu:

  1. Titik akhir Temporary Credential Request
  2. Titik akhir Resource Owner Authorization
  3. Titik akhir Token Credentials Request

URI ini disediakan oleh server dengan berbagai cara. Salah satu cara ini adalah dengan memaparkannya di respons server saat memeriksa API. OAuth Authentication API untuk WordPress REST API menggunakan metode yang sama, seperti yang akan kita lihat di bagian selanjutnya.

Setelah melihat cara kerja OAuth, langkah selanjutnya adalah memasang dan mengaktifkan OAuth authentication API untuk WordPress.

Memasang OAuth Authentication API untuk WordPress

Otoritas otentikasi OAuth untuk WordPress memungkinkan server untuk menerima permintaan yang diautentikasi menggunakan penerapan OAuth. Ini dibangun di atas spesifikasi OAuth 1.0a dan memanjanginya dengan parameter tambahan —wp_scope— untuk dikirim ke titik akhir . Parameter wp_scope mendefinisikan ruang lingkup akses yang diberikan kepada klien. Anda dapat menemukan lebih banyak tentangnya di dokumentasi resmi di GitHub.

Plugin ini tersedia di Github dari tim WP REST API dan hanya mendukung versi 4.4 atau lebih baru dari WordPress.

Mari kloning plugin dengan menavigasi ke direktori /wp-content/plugins/:

Setelah pengunduhan selesai, aktifkan plugin menggunakan WP CLI:

Atau, Anda juga dapat mengaktifkannya dengan menavigasi browser Anda ke bagian plugin admin WordPress Anda jika Anda tidak ingin menggunakan WP CLI.

Ini semua yang diperlukan agar server dapat menerima OAuth sebagai metode otorisasi. Hal berikutnya yang perlu kita lakukan adalah mengirim permintaan ke server untuk memeriksa apakah OAuth API siap digunakan.

Menilai Ketersediaan API OAuth

Sebelum kita memulai inisiasi OAuth, pertama-tama kita harus memeriksa apakah API diaktifkan di server. Ini dilakukan dengan mengirimkan permintaan GET sederhana ke /wp-json/ endpoint dan kemudian menganalisis respon yang dikirim oleh server.

Jalankan klien HTTP Anda dan kirim permintaan ke /wp-json/ endpoint sebagai berikut:

Ini akan mengembalikan respons JSON sebagai berikut:

Server responseServer responseServer response

Fokus kita di sini adalah nilai oauth1 dalam nilai properti . Objek ini memiliki properti berikut yang ditentukan:

  • request: Temporary Credential Request endpoint
  • authorize: Resource Owner Authorization endpoint
  • access: Token Request endpoint
  • version: versi OAuth yang digunakan

Tiga pertama dari mereka adalah URL absolut yang kita temui ketika belajar tentang mekanisme OAuth di bagian sebelumnya.

Objek oauth1 yang didefinisikan dalam nilai properti authentication menunjukkan bahwa OAuth API telah berhasil diaktifkan untuk situs WordPress kita dan kita dapat mulai menggunakannya.

Jika OAuth API tidak diaktifkan untuk situs, respons server akan berisi nilai properti authorization kosong sebagai berikut:

Server responseServer responseServer response

Sekarang setelah kita menginstal plugin OAuth1.0a, mari kita lihat bagaimana kita dapat membuat dan mengelola konsumen untuk aplikasi kita.

Membuat dan Mengelola Aplikasi

Setelah plugin OAuth1.0 berhasil diinstal, kita dapat membuat dan mengelola konsumen untuk aplikasi kita dengan membuka admin WordPress dan kemudian ke halaman Users > Applications.

ApplicationsApplicationsApplications

Pada halaman Registered Applications ini, kita dapat mendaftarkan aplikasi baru dengan mengklik tombol Add New dan kemudian mengisi tiga bidang berikut pada halaman yang dihasilkan:

  1. Consumer name: nama dari konsumen. Nama ini ditampilkan kepada pengguna selama proses otorisasi dan setelah itu, pada halaman profil mereka di bawah bagian Authorized Applications.
  2. Description: Deskripsi opsional untuk aplikasi konsumen.
  3. Callback URL: callback URL. URL callback ini digunakan saat membuat kredensial sementara seperti yang akan kita lihat di langkah berikutnya.

Setelah dibuat dengan mengklik tombol Save Consumer, Client Key dan parameter Client Secret akan muncul di bagian bawah halaman untuk konsumen tertentu ini.

OAuth CredentialsOAuth CredentialsOAuth Credentials

Parameter Client Key dan Client Secret ini bertindak sebagai parameter oauth_consumer_key dan oauth_consumer_secret masing-masing.

Client Secret baru dapat dibuat dengan mengklik tombol Regenerate Secret di bagian bawah halaman.

Plugin OAuth juga mengekspos fungsionalitas untuk membuat konsumen di konsol melalui plugin WP CLI. Jadi, konsumen baru juga dapat dibuat dengan perintah berikut di terminal:

Konsumen yang baru dibuat ini kemudian akan muncul di halaman Registered Applications di mana Anda dapat mengeditnya.

Setelah mendaftarkan aplikasi kita, kita sekarang siap untuk memulai proses otorisasi OAuth di bagian berikut.

Memasang Paket CLI Klien

Harap perhatikan bahwa pada saat menulis tutorial ini, plugin OAuth1.0a tidak mendukung paket CLI Klien lagi. Paket CLI Klien mungkin akan diperbarui dalam waktu dekat untuk bekerja dengan versi terbaru plugin OAuth, tetapi untuk saat ini, silakan lihat bagian selanjutnya tentang menghasilkan kredensial OAuth menggunakan klien HTTP.

Paket Klien-CLI oleh tim WP REST API memungkinkan interaksi jarak jauh dengan situs WordPress menggunakan WP-CLI dan WP REST API. Sumbernya dapat ditemukan di GitHub.

Untuk menggunakan paket ini, Anda harus menginstal dan mengaktifkan berikut ini di server tempat instalasi WordPress Anda berada:

  1. WP CLI
  2. Plugin WP REST API
  3. Plugin server OAuth 1.0a

Pada mesin (atau klien), dari mana Anda ingin menghasilkan permintaan, berikut ini harus diinstal:

  1. WP CLI
  2. Composer
  3. Repositori CLI Klien itu sendiri

Anda dapat menemukan petunjuk untuk menginstal paket-paket di atas di situs masing-masing.

Dengan itu, mari kita mengkloning repositori pada klien dengan menjalankan perintah berikut:

Sekarang masuk ke direktori yang dikloning dan instal dependensi paket menggunakan Composer:

Jika semua berjalan dengan baik, baris perintah harus menunjukkan sesuatu yang mirip dengan yang berikut:

OAuth10a installedOAuth10a installedOAuth10a installed

Sekarang setelah kita menginstal paket, kita siap untuk menghasilkan kredensial token dan berinteraksi dari jarak jauh ke WordPress REST API menggunakan OAuth.

Menggunakan CLI Klien untuk Menghasilkan Kredensial OAuth

Untuk memulai proses otorisasi OAuth, pertama-tama kita dapatkan yang berikut dari server:

  • oauth_consumer_key
  • oauth_consumer_secret

Ini dapat dihasilkan dengan mengarahkan terminal ke direktori instalasi WordPress Anda di server dan menjalankan perintah WP CLI berikut:

Ini akan menghasilkan output seperti berikut:

Generating consumer keyGenerating consumer keyGenerating consumer key

Key dan Secret yang diperoleh disini adalah oauth_consumer_key dan oauth_consumer_secret.

Sekarang kita perlu menghubungkan klien ke situs WordPress Anda. Pada klien, arahkan ke direktori client-cli Anda kloning di bagian sebelumnya dan jalankan perintah berikut:

Ganti URL dan juga key dan secret yang Anda peroleh pada langkah sebelumnya dalam perintah di atas. Outputnya harus seperti berikut:

Arahkan ke URL yang diberikan oleh server dan autentikasi sendiri dengan mengklik tombol Authorize:

User authorizationUser authorizationUser authorization

Anda akan disajikan dengan token verifikasi (atau oauth_verifier) di layar berikutnya:

Verification tokenVerification tokenVerification token

Salin verifier dan tempelkan ke terminal Anda. Anda akan diberikan Key dan Secret, yang pada dasarnya adalah oauth_token dan oauth_token_secret Anda masing-masing:

Token credentialsToken credentialsToken credentials

Anda dapat menggunakan kredensial token ini di klien HTTP Anda atau aplikasi lain yang mendukung pengiriman permintaan yang diautentikasi menggunakan OAuth API.

Menggunakan Klien HTTP untuk Menghasilkan Kredensial OAuth

Karena plugin server OAuth 1.0a mengikuti alur tiga kaki, menghasilkan kredensial OAuth melibatkan tiga langkah:

  1. Akuisisi kredensial sementara
  2. Otorisasi pengguna
  3. Pertukaran Token

Mari mulai menerapkan masing-masing langkah di atas menggunakan klien HTTP, yaitu Postman.

1. Mendapatkan Kredensial Sementara

Untuk memperoleh kredensial sementara, kita mengirim permintaan POST ke titik akhir permintaan /oauth1/request. Titik akhir permintaan kredensial sementara ini harus otomatis ditemukan karena server mungkin mengganti rute ini dengan miliknya sendiri. Kita melihat fitur penemuan otomatis saat menilai ketersediaan API OAuth di bagian sebelumnya.

Permintaan POST harus menyertakan parameter oauth_consumer_key dan oauth_consumer_secret seperti yang diperoleh saat mendaftarkan konsumen untuk aplikasi. Permintaan mungkin juga menyertakan parameter oauth_callback dan URL callback ini harus sesuai dengan skema, host, port, dan jalur dari callback URL yang diberikan saat mendaftarkan aplikasi.

Terlepas dari parameter oauth_consumer_key dan oauth_consumer_secret, permintaan juga harus menyertakan parameter oauth_signature dan oauth_signature_method. Saat menggunakan Postman, oauth_signature dihasilkan secara otomatis dan kita hanya perlu menentukan parameter oauth_signature_method. Saat ini, hanya metode signature HMAC-SHA1 yang didukung oleh plugin server OAuth.

Parameter di atas dapat diteruskan dengan salah satu dari tiga cara berikut:

  1. Melalui header Authorization
  2. Melalui parameter permintaan (GET) di URL
  3. Melalui permintaan parameter tubuh (POST). Jenis konten dalam hal ini harus aplikasi application/x-www-form-urlencoded.

Terserah Anda untuk menggunakan salah satu dari metode di atas untuk mengirim parameter ini ke server.

Mari sekarang mulai proses dengan Postman dan mengirim permintaan POST ke titik akhir permintaan kredensial sementara. Tetapi sebelum itu, salin Consumer Key dan Consumer Secret yang disediakan oleh aplikasi yang baru terdaftar karena mereka akan dibutuhkan dalam langkah ini.

Konfigurasikan Postman untuk mengirim permintaan POST ke titik akhir kredensial sementara Anda. Kemudian di tab Authorization pilih opsi OAuth 1.0 dari dropdown. Isi bidang Consumer Key dan Consumer Secret dengan nilai yang diberikan oleh konsumen. Pastikan untuk memeriksa bahwa opsi Signature Method diatur ke HMAC-SHA1.

PostmanPostmanPostman

Kita tidak perlu memasukkan nilai selain dari ini. Klik tombol Update Request dan akhirnya kirim permintaan dengan mengklik tombol Send.

Jika tidak ada kesalahan, server akan mengembalikan kode status 200 - OK bersama dengan badan tanggapan yang memiliki tipe konten application/x-www-form-urlencoded. Badan permintaan ini terlihat seperti string teks berikut:

Tubuh respons ini berisi tiga parameter untuk langkah selanjutnya dari aliran tiga kaki. Ketiga parameter ini adalah:

  1. oauth_token: Token OAuth sementara untuk langkah otorisasi.
  2. oauth_token_secret: Secret sementara untuk digunakan bersama oauth_token.
  3. oauth_callback_confirmed: Parameter ini selalu dikembalikan apakah Anda memberikan parameter oauth_callback pada langkah pertama.

Dengan kredensial sementara ini siap, kita siap untuk langkah otorisasi pengguna.

2. Otorisasi Pengguna

Untuk langkah otorisasi pengguna, kita membuka endpoint otorisasi pemilik sumber daya di browser dan meneruskan oauth_token dan oauth_token_secret seperti yang diperoleh pada langkah sebelumnya sebagai parameter kueri seperti berikut:

Browser akan meminta Anda untuk masuk ke WordPress (jika Anda belum masuk) dan kemudian akan meminta Anda untuk mengotorisasi aplikasi:

User authorizationUser authorizationUser authorization

Di sini Awesome Application adalah nama aplikasi yang terdaftar.

Otorisasi aplikasi dengan mengklik tombol Authorize dan Anda akan disajikan dengan token verifikasi di layar berikutnya:

Verification tokenVerification tokenVerification token

Token ini bertindak sebagai token oauth_verifier di langkah berikutnya.

Setelah pengguna mengesahkan klien, aplikasi akan muncul di bawah bagian Authorized Applications pada laman Users > Your Profile.

3. Pertukaran Token

Langkah selanjutnya dan langkah terakhir dalam aliran tiga kaki adalah pertukaran token. Pada langkah ini, token sementara yang diperoleh pada langkah pertama ditukarkan dengan token yang berumur panjang yang dapat digunakan oleh klien.

Untuk memulai proses pertukaran token, kembali ke Postman dan konfigurasikan untuk mengirim permintaan POST ke titik akhir permintaan token.

Dengan menggunakan opsi OAuth 1.0 lagi di tab Authorization isi bidang untuk Consumer Key dan Consumer Secret dengan nilai yang disediakan oleh konsumen. Untuk bidang Token dan Token Secret, gunakan nilai parameter oauth_token dan oauth_token_secret (kredensial sementara) yang diperoleh pada langkah pertama.

Karena kita juga dapat melewatkan parameter dalam URL sebagai parameter kueri, tambahkan parameter oauth_verifier ke URL sebagai berikut:

Dengan semua parameter di tempat, kirim permintaan dengan mengklik tombol Send. Jika semua berjalan dengan baik, server akan mengembalikan kode status 200 - OK bersama dengan tubuh respons yang berisi parameter oauth_token dan oauth_token_secret.

Pada titik ini, token sementara yang diperoleh pada langkah pertama dibuang dan tidak dapat digunakan lagi.

Parameter baru oauth_token dan oauth_token_secret ini adalah kredensial OAuth Anda yang dapat Anda gunakan di klien Anda untuk menghasilkan permintaan yang diautentikasi.

Mengirim Tes Permintaan Terautentikasi

Sekarang setelah kita memperoleh kredensial token kita, kita dapat mengirim permintaan pengujian ke server menggunakan Postman untuk melihat apakah mereka berfungsi (tentu saja mereka akan!).

Kita akan mengirim permintaan DELETE ke server untuk menghapus posting dengan ID 50. ID ini dapat berbeda dalam kasus Anda.

Anda harus memiliki yang berikut sebelum memulai:

  • oauth_consumer_key: diperoleh pada langkah pertama
  • oauth_consumer_secret: diperoleh pada langkah pertama
  • oauth_token: diperoleh pada langkah terakhir
  • oauth_token_secret: diperoleh pada langkah terakhir

Pilih OAuth 1.0 dari drop-down di bawah tab Authorization di Postman, dan isi empat bidang pertama seperti yang disebutkan di atas. Di bawah ini terlihat seperti berikut:

Using OAuth1Using OAuth1Using OAuth1

Klik tombol Update Request setelah mengisi kolom. Memeriksa opsi Add params to header mengirimkan parameter di header permintaan dan bukannya menambahkannya dalam string kueri.

Kirim permintaan dan Anda harus mendapatkan kode status 200 - OK dari server, menunjukkan bahwa posting telah berhasil dihapus.

Kesimpulan

Dalam tutorial yang panjang ini kita mengambil ikhtisar tentang metode autentikasi OAuth dan bagaimana cara kerjanya untuk memberikan akses yang didelegasikan secara aman ke aplikasi dan layanan pihak ketiga. Kita juga menyiapkan OAuth Authentication API untuk WordPress di server dan menggunakannya bersama dengan klien HTTP untuk mendapatkan kredensial token.

Di bagian selanjutnya dari seri ini, kami akan mencari konten melalui WP REST API. Jadi nantikanlah...

Advertisement
Did you find this post useful?
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.