ওয়েবহুকস ব্যাখ্যা: স্বাক্ষরিত পেলোড এবং পুনঃপ্রচেষ্টা
ওয়েবহুক কেন জটিল
ওয়েবহুক একটি সহজ ধারণা: পরিবর্তনের জন্য API পোলিং করার পরিবর্তে, প্রোভাইডার HTTP POST এর মাধ্যমে আপনার এন্ডপয়েন্টে ইভেন্ট পুশ করে। কিন্তু বাস্তবে, ওয়েবহুক অনেক ডেভেলপারের জন্য চ্যালেঞ্জ তৈরি করে: অনুরোধটি সত্যিই প্রোভাইডার থেকে এসেছে কিনা তা যাচাই করা, ডুপ্লিকেট ডেলিভারি হ্যান্ডল করা এবং নেটওয়ার্ক ব্যর্থতা মোকাবেলা করা। আপনি যদি এগুলো উপেক্ষা করেন, তাহলে নিরাপত্তা লঙ্ঘন, ডেটা করাপশন এবং বিরক্ত ব্যবহারকারীর ঝুঁকি নেন।
এই নিবন্ধে প্রোডাকশন-গ্রেড ওয়েবহুকের দুটি সবচেয়ে গুরুত্বপূর্ণ দিক নিয়ে আলোচনা করা হয়েছে: স্বাক্ষরিত পেলোড এবং পুনঃপ্রচেষ্টা। আমরা স্বাক্ষর যাচাই, সূচকীয় ব্যাকঅফ সহ পুনঃপ্রচেষ্টা এবং আপনার প্রসেসিং আইডেম্পোটেন্ট করার বিষয়ে আলোচনা করব।
স্বাক্ষরিত পেলোড: সত্যতা প্রমাণ
যে কেউ আপনার এন্ডপয়েন্টে HTTP POST পাঠাতে পারে। অনুরোধটি আপনার প্রোভাইডার থেকে এসেছে তা নিশ্চিত করতে, প্রোভাইডার একটি সিক্রেট কী দিয়ে পেলোড স্বাক্ষর করে এবং হেডারে স্বাক্ষর পাঠায়। আপনার কাজ হল স্বাক্ষর পুনরায় গণনা করে তুলনা করা।
বেশিরভাগ প্রোভাইডার HMAC-SHA256 ব্যবহার করে। স্বাক্ষর সাধারণত কাঁচা রিকোয়েস্ট বডির উপর (কখনও টাইমস্ট্যাম্প সহ) গণনা করা হয় এবং হেক্স-এনকোড করা হয়। উদাহরণস্বরূপ, Stripe Stripe-Signature এর মতো একটি হেডার ব্যবহার করে যাতে টাইমস্ট্যাম্প এবং স্বাক্ষর থাকে।
HMAC কীভাবে কাজ করে
HMAC (হ্যাশ-ভিত্তিক মেসেজ অথেন্টিকেশন কোড) একটি সিক্রেট কী এবং একটি হ্যাশ ফাংশন একত্রিত করে। একই কী এবং মেসেজের জন্য আউটপুট নির্ধারক। কী ছাড়া, আক্রমণকারী একটি বৈধ স্বাক্ষর জাল করতে পারে না।
Node.js-এ একটি ন্যূনতম উদাহরণ:
const crypto = require('crypto');
function verifySignature(payload, signature, secret) {
const expected = crypto
.createHmac('sha256', secret)
.update(payload)
.digest('hex');
return crypto.timingSafeEqual(
Buffer.from(signature),
Buffer.from(expected)
);
}
Python-এ, এটি সমানভাবে সহজ:
import hmac
import hashlib
def verify_signature(payload: bytes, signature: str, secret: str) -> bool:
expected = hmac.new(
secret.encode(),
payload,
hashlib.sha256
).hexdigest()
return hmac.compare_digest(expected, signature)
স্বাক্ষর যাচাইয়ের সেরা অনুশীলন
- টাইমিং আক্রমণ প্রতিরোধ করতে ধ্রুবক-সময়ের তুলনা ব্যবহার করুন।
crypto.timingSafeEqualএবংhmac.compare_digestউভয়ই নিরাপদ। - কাঁচা বডি যাচাই করুন, পার্স করা JSON অবজেক্ট নয়। পার্সিং এবং পুনরায় সিরিয়ালাইজিং হোয়াইটস্পেস পরিবর্তন করতে পারে এবং স্বাক্ষর ভাঙতে পারে।
- রিপ্লে আক্রমণ প্রতিরোধ করতে স্বাক্ষরিত ডেটাতে একটি টাইমস্ট্যাম্প অন্তর্ভুক্ত করুন। কয়েক মিনিটের পুরনো অনুরোধ প্রত্যাখ্যান করুন।
- সিক্রেট নিরাপদে সংরক্ষণ করুন—পরিবেশ ভেরিয়েবল বা সিক্রেট ম্যানেজার ব্যবহার করুন, কখনও হার্ডকোড করবেন না।
টাইমস্ট্যাম্প এবং রিপ্লে আক্রমণ হ্যান্ডলিং
অনেক প্রোভাইডার স্বাক্ষর হেডারে একটি টাইমস্ট্যাম্প অন্তর্ভুক্ত করে। উদাহরণস্বরূপ, হেডারটি হতে পারে t=1614556800,v1=abc123...। আপনার উচিত:
- টাইমস্ট্যাম্প এবং স্বাক্ষর বের করুন।
- টাইমস্ট্যাম্প একটি গ্রহণযোগ্য উইন্ডোর মধ্যে (যেমন, 5 মিনিট) আছে কিনা পরীক্ষা করুন।
- টাইমস্ট্যাম্প এবং পেলোড ব্যবহার করে স্বাক্ষর পুনরায় গণনা করুন।
- নিরাপদে স্বাক্ষর তুলনা করুন।
এটি একজন আক্রমণকারীকে পুরনো বৈধ অনুরোধ রিপ্লে করা থেকে বিরত রাখে।
পুনঃপ্রচেষ্টা: ব্যর্থতা সুন্দরভাবে হ্যান্ডল করা
ওয়েবহুক পাবলিক ইন্টারনেটে ডেলিভার করা হয়, তাই ব্যর্থতা অনিবার্য। আপনার এন্ডপয়েন্ট ডাউন, ধীর বা 500 ত্রুটি ফেরত দিতে পারে। একটি শক্তিশালী প্রোভাইডার ব্যর্থ ডেলিভারি পুনঃপ্রচেষ্টা করবে, কিন্তু আপনি যদি প্রোভাইডার হন তবে আপনাকে আপনার দিকেও পুনঃপ্রচেষ্টা হ্যান্ডল করতে হবে।
জিটার সহ সূচকীয় ব্যাকঅফ
পুনঃপ্রচেষ্টা করার সময়, তাৎক্ষণিক পুনঃপ্রচেষ্টা দিয়ে এন্ডপয়েন্টে হাতুড়ি মারা এড়িয়ে চলুন। সূচকীয় ব্যাকঅফ ব্যবহার করুন: প্রতিটি ব্যর্থতার পরে আরও অপেক্ষা করুন। জিটার (র্যান্ডমনেস) যোগ করুন যাতে অনেক ওয়েবহুক একসাথে ব্যর্থ হলে থান্ডারিং হার্ড সমস্যা এড়ানো যায়।
একটি সাধারণ পুনঃপ্রচেষ্টা সময়সূচি দেখতে হতে পারে:
| প্রচেষ্টা | বিলম্ব (আনুমানিক) |
|---|---|
| 1 | তাৎক্ষণিক |
| 2 | 30 সেকেন্ড |
| 3 | 5 মিনিট |
| 4 | 30 মিনিট |
| 5 | 2 ঘন্টা |
সর্বাধিক সংখ্যক প্রচেষ্টার পরে, ডেলিভারি ব্যর্থ হিসেবে চিহ্নিত করুন এবং সতর্ক করুন।
আইডেম্পোটেন্সি: নিরাপদ পুনঃপ্রচেষ্টার চাবিকাঠি
যেহেতু পুনঃপ্রচেষ্টা ডুপ্লিকেট ডেলিভারি ঘটাতে পারে, আপনার ওয়েবহুক হ্যান্ডলার অবশ্যই আইডেম্পোটেন্ট হতে হবে। এর মানে হল একই ইভেন্ট একবার প্রসেস করার মতো একাধিকবার প্রসেস করলে একই প্রভাব থাকা উচিত।
আইডেম্পোটেন্সি অর্জনের উপায়:
- পেলোডে প্রদত্ত একটি অনন্য ইভেন্ট ID ব্যবহার করুন (যেমন,
idফিল্ড)। প্রসেস করা ID গুলি একটি অনন্য সীমাবদ্ধতা সহ ডেটাবেসে সংরক্ষণ করুন। - অপারেশনগুলিকে আইডেম্পোটেন্ট ডিজাইন করুন—উদাহরণস্বরূপ, ইনসার্টের পরিবর্তে আপসার্ট ব্যবহার করুন, অথবা একটি রিসোর্স তৈরি করার আগে সেটি ইতিমধ্যে বিদ্যমান কিনা পরীক্ষা করুন।
- দ্রুত 2xx ফেরত দিন এবং কাজ ভারী হলে অ্যাসিঙ্ক্রোনাসভাবে প্রসেস করুন। এটি টাইমআউটের সম্ভাবনা হ্রাস করে যা পুনঃপ্রচেষ্টা ট্রিগার করে।
প্রোভাইডার সাইডে পুনঃপ্রচেষ্টা প্রয়োগ করা
যদি আপনি একটি ওয়েবহুক সিস্টেম তৈরি করেন, তাহলে আপনার একটি নির্ভরযোগ্য ডেলিভারি ব্যবস্থা প্রয়োজন। এখানে একটি সরলীকৃত পদ্ধতি:
- যখন একটি ইভেন্ট ঘটে, পেলোড এবং টার্গেট URL সহ একটি ডেলিভারি জব এনকিউ করুন।
- একটি ওয়ার্কার জবটি তুলে নেয় এবং একটি টাইমআউট (যেমন, 10 সেকেন্ড) সহ HTTP POST পাঠায়।
- যদি প্রতিক্রিয়া স্ট্যাটাস 2xx না হয়, সূচকীয় ব্যাকঅফ সহ একটি পুনঃপ্রচেষ্টা শিডিউল করুন।
- প্রচেষ্টাগুলি ট্র্যাক করুন এবং সর্বাধিকের পরে (যেমন, 5 প্রচেষ্টা) ছেড়ে দিন।
- ব্যর্থতা লগ করুন এবং ব্যবহারকারীদের ম্যানুয়ালি রিপ্লে করার একটি উপায় প্রদান করুন।
একটি স্থায়ী কিউ (যেমন, Redis, RabbitMQ, বা একটি ডেটাবেস টেবিল) ব্যবহার করুন যাতে পুনঃপ্রচেষ্টা পুনরায় চালু হওয়ার পরেও বেঁচে থাকে।
সবকিছু একসাথে করা: একটি ওয়েবহুক রিসিভার চেকলিস্ট
একটি ওয়েবহুক রিসিভার তৈরি করার সময়, এই চেকলিস্ট অনুসরণ করুন:
- প্রোভাইডারের সিক্রেট এবং ধ্রুবক-সময়ের তুলনা ব্যবহার করে স্বাক্ষর যাচাই করুন।
- রিপ্লে আক্রমণ প্রতিরোধ করতে টাইমস্ট্যাম্প পরীক্ষা করুন।
- দ্রুত 2xx দিয়ে সাড়া দিন—ভারী প্রসেসিং করার আগে প্রাপ্তি স্বীকার করুন।
- প্রয়োজনে একটি কিউ ব্যবহার করে অ্যাসিঙ্ক্রোনাসভাবে প্রসেস করুন।
- ইভেন্ট ID ট্র্যাক করে আইডেম্পোটেন্সি নিশ্চিত করুন।
- ডিবাগিং এবং অডিটিংয়ের জন্য সবকিছু লগ করুন।
- ব্যর্থতা মনিটর করুন এবং বারবার পুনঃপ্রচেষ্টার জন্য সতর্কতা সেট আপ করুন।
FAQ
স্বাক্ষরিত ওয়েবহুক পেলোড কী?
একটি স্বাক্ষরিত পেলোডে একটি শেয়ার্ড সিক্রেট দিয়ে তৈরি একটি ক্রিপ্টোগ্রাফিক স্বাক্ষর (সাধারণত HMAC-SHA256) থাকে। রিসিভার স্বাক্ষর পুনরায় গণনা করে যাচাই করে যে অনুরোধটি প্রত্যাশিত প্রেরকের কাছ থেকে এসেছে এবং টেম্পার করা হয়নি।
ওয়েবহুকের পুনঃপ্রচেষ্টা কেন প্রয়োজন?
নেটওয়ার্ক সমস্যা, সার্ভার ডাউনটাইম, বা সাময়িক ত্রুটির কারণে ওয়েবহুক ডেলিভারি ব্যর্থ হতে পারে। সূচকীয় ব্যাকঅফ সহ পুনঃপ্রচেষ্টা নিশ্চিত করে যে ইভেন্টটি শেষ পর্যন্ত ডেলিভার করা হয় রিসিভারকে অভিভূত না করে।
কীভাবে ডুপ্লিকেট ওয়েবহুক প্রসেসিং প্রতিরোধ করব?
আইডেম্পোটেন্সি ব্যবহার করুন: পেলোডে একটি অনন্য ইভেন্ট ID অন্তর্ভুক্ত করুন, প্রসেস করা ID গুলি সংরক্ষণ করুন এবং আপনার অপারেশনগুলিকে আইডেম্পোটেন্ট ডিজাইন করুন (যেমন, আপসার্ট)। এইভাবে, এমনকি যদি একটি ওয়েবহুক একাধিকবার ডেলিভার করা হয়, প্রভাব একই থাকে।
আপনার যদি ওয়েবহুক পেলোড পরিদর্শন বা ডিবাগ করার প্রয়োজন হয়, JSON Formatter আপনাকে দ্রুত JSON ডেটা সুন্দরভাবে প্রিন্ট এবং যাচাই করতে সাহায্য করতে পারে।