ওয়েবহুকস ব্যাখ্যা: সাইনড পেলোড এবং রিট্রাই
কেন ওয়েবহুকসে সিগনেচার এবং রিট্রাই প্রয়োজন
আপনি একটি পেমেন্ট প্রোভাইডার বা SaaS প্ল্যাটফর্ম থেকে ওয়েবহুকস গ্রহণ করার জন্য একটি এন্ডপয়েন্ট তৈরি করেছেন। পরীক্ষায় সবকিছু কাজ করে, কিন্তু প্রোডাকশনে আপনি দুটি সমস্যার সম্মুখীন হন: কীভাবে জানবেন যে অনুরোধটি সত্যিই প্রোভাইডার থেকে এসেছে, এবং আপনার সার্ভার ডাউন বা ধীর হলে কী হবে? সাইনড পেলোড ছাড়া যে কেউ একটি অনুরোধ জাল করতে পারে। রিট্রাই ছাড়া একটি নেটওয়ার্ক হোঁচট একটি ইভেন্ট চিরতরে হারিয়ে দিতে পারে।
এই গাইডে ব্যাখ্যা করা হয়েছে কীভাবে উভয়ই সঠিকভাবে প্রয়োগ করবেন। আমরা HMAC সাইনিং, ভেরিফিকেশন ধাপ, রিট্রাই স্ট্র্যাটেজি এবং আইডেম্পোটেন্সি নিয়ে আলোচনা করব—নির্ভরযোগ্য ওয়েবহুক হ্যান্ডলিংয়ের তিনটি স্তম্ভ।
ওয়েবহুক সিগনেচার কীভাবে কাজ করে
একটি ওয়েবহুক সিগনেচার হল একটি ক্রিপ্টোগ্রাফিক হ্যাশ যা প্রমাণ করে যে পেলোডটি এমন কেউ তৈরি করেছে যে একটি শেয়ার্ড সিক্রেট জানে। বেশিরভাগ প্রোভাইডার HMAC-SHA256 ব্যবহার করে। প্রেরক কাঁচা অনুরোধ বডির (কখনও কখনও টাইমস্ট্যাম্প সহ) উপর সিগনেচার গণনা করে এবং এটি একটি হেডারে অন্তর্ভুক্ত করে। প্রাপক এটি পুনরায় গণনা করে এবং তুলনা করে।
এখানে একটি সাধারণ প্রবাহ:
- প্রোভাইডার এবং কনজিউমার একটি সিক্রেট কী শেয়ার করে (প্রোভাইডারের ড্যাশবোর্ডে কনফিগার করা)।
- প্রোভাইডার পেলোড তৈরি করে,
HMAC-SHA256(secret, payload)গণনা করে এবং এটিX-Signature-এর মতো একটি হেডারে পাঠায়। - কনজিউমার অনুরোধ গ্রহণ করে, কাঁচা বডি পড়ে, HMAC পুনরায় গণনা করে এবং একটি কনস্ট্যান্ট-টাইম ফাংশন ব্যবহার করে তুলনা করে।
- যদি তারা মিলে যায়, ইভেন্ট প্রসেস করে; অন্যথায়, 401 দিয়ে প্রত্যাখ্যান করে।
গুরুত্বপূর্ণ: সর্বদা কাঁচা অনুরোধ বডি ব্যবহার করুন যেমনটি গ্রহণ করা হয়েছে, পার্স-এন্ড-রিস্টিংগিফাই করা সংস্করণ নয়। JSON সিরিয়ালাইজেশন হোয়াইটস্পেস এবং কী অর্ডার পরিবর্তন করতে পারে, সিগনেচার ভেঙে দেয়।
রিপ্লে অ্যাটাক প্রতিরোধে টাইমস্ট্যাম্প যোগ করা
শুধুমাত্র একটি সাইনড পেলোড একজন আক্রমণকারী দ্বারা রিপ্লে করা যেতে পারে যে একটি বৈধ অনুরোধ ক্যাপচার করে। এটি প্রশমিত করতে, সাইনড ডেটাতে একটি টাইমস্ট্যাম্প অন্তর্ভুক্ত করুন এবং কয়েক মিনিটের চেয়ে পুরোনো অনুরোধ প্রত্যাখ্যান করুন। উদাহরণস্বরূপ:
signed_payload = timestamp + "." + raw_body
signature = HMAC-SHA256(secret, signed_payload)কনজিউমার পরীক্ষা করে যে টাইমস্ট্যাম্প একটি গ্রহণযোগ্য উইন্ডোর মধ্যে (যেমন, 5 মিনিট) এবং সিগনেচার মিলে যায়।
সিগনেচার ভেরিফিকেশন প্রয়োগ করা
Flask ব্যবহার করে পাইথনে একটি নির্দিষ্ট উদাহরণ দেখি। আমরা X-Signature হেডারে পাঠানো একটি সিগনেচার যাচাই করব।
import hmac
import hashlib
from flask import Flask, request, abort
app = Flask(__name__)
SECRET = b'your_shared_secret'
@app.route('/webhook', methods=['POST'])
def webhook():
signature = request.headers.get('X-Signature')
if not signature:
abort(401)
raw_body = request.get_data()
expected = hmac.new(SECRET, raw_body, hashlib.sha256).hexdigest()
if not hmac.compare_digest(expected, signature):
abort(401)
# Process the event
event = request.json
# ... handle event ...
return '', 200মূল পয়েন্ট:
- টাইমিং অ্যাটাক এড়াতে কনস্ট্যান্ট-টাইম তুলনার জন্য
hmac.compare_digest(বা সমতুল্য) ব্যবহার করুন। - কোনও পার্সিংয়ের আগে
request.get_data()-এর মাধ্যমে কাঁচা বডি অ্যাক্সেস করুন। - দ্রুত 200 ফেরত দিন; ভারী প্রসেসিং অ্যাসিনক্রোনাসভাবে করুন।
রিট্রাই স্ট্র্যাটেজি ডিজাইন করা
সিগনেচার থাকা সত্ত্বেও, ওয়েবহুক ব্যর্থ হতে পারে: আপনার সার্ভার ডাউন থাকতে পারে, 500 ফেরত দিতে পারে বা টাইম আউট হতে পারে। প্রোভাইডাররা সাধারণত এক্সপোনেনশিয়াল ব্যাকঅফের সাথে রিট্রাই করে। কনজিউমার হিসাবে, আপনারও রিট্রাইগুলো সুন্দরভাবে পরিচালনা করা উচিত।
এখানে বিবেচনা করার বিষয়গুলো:
- আইডেম্পোটেন্সি: প্রতিটি ইভেন্টের একটি অনন্য আইডি থাকা উচিত। রিট্রাই ঘটলে ডুপ্লিকেট প্রসেসিং এড়াতে প্রসেস করা আইডিগুলো সংরক্ষণ করুন।
- দ্রুত প্রতিক্রিয়া: কয়েক সেকেন্ডের মধ্যে 2xx স্ট্যাটাস দিয়ে প্রাপ্তি স্বীকার করুন। ব্যাকগ্রাউন্ড প্রসেসিংয়ের জন্য ইভেন্টটি সারিবদ্ধ করুন।
- আপনার দিকে রিট্রাই লজিক: যদি আপনি ডাউনস্ট্রিম সার্ভিসগুলো কল করেন, ব্যাকঅফ এবং সার্কিট ব্রেকার সহ রিট্রাই প্রয়োগ করুন।
বেশিরভাগ প্রোভাইডার নন-2xx প্রতিক্রিয়া বা টাইমআউটে রিট্রাই করে, প্রায়শই 24 ঘন্টা পর্যন্ত ক্রমবর্ধমান বিরতিতে। নির্দিষ্ট বিবরণের জন্য আপনার প্রোভাইডারের ডকুমেন্টেশন দেখুন।
উদাহরণ: আইডেম্পোটেন্ট ইভেন্ট হ্যান্ডলার
প্রসেস করা ইভেন্ট আইডি ট্র্যাক করতে একটি ডেটাবেস টেবিল ব্যবহার করুন। এখানে একটি সরলীকৃত প্যাটার্ন:
def handle_event(event_id, payload):
if db.exists('processed_events', event_id):
return # already handled
# process payload
db.insert('processed_events', event_id)
# ... actual work ...উচ্চ থ্রুপুটের জন্য, ইভেন্ট আইডিতে একটি অনন্য সীমাবদ্ধতা ব্যবহার করুন এবং ডুপ্লিকেট কী ত্রুটি ধরুন।
তুলনা: সাইনড বনাম আনসাইনড ওয়েবহুকস
| দিক | সাইনড পেলোড | আনসাইনড পেলোড |
|---|---|---|
| নিরাপত্তা | প্রেরকের সত্যতা যাচাই করে | যে কেউ অনুরোধ জাল করতে পারে |
| রিপ্লে সুরক্ষা | টাইমস্ট্যাম্পের সাথে সম্ভব | কোনওটি নেই |
| বাস্তবায়ন প্রচেষ্টা | মাঝারি (HMAC + টাইমস্ট্যাম্প চেক) | কম |
| যার জন্য সুপারিশ করা হয় | সমস্ত প্রোডাকশন ওয়েবহুকস | শুধুমাত্র অভ্যন্তরীণ পরীক্ষার জন্য |
সাধারণ ভুল এবং সেরা অনুশীলন
- যাচাইয়ের আগে পার্স করবেন না: সর্বদা প্রথমে কাঁচা বডিতে সিগনেচার যাচাই করুন।
- HTTPS ব্যবহার করুন: সিগনেচার অখণ্ডতা রক্ষা করে, কিন্তু HTTPS গোপনীয়তা রক্ষা করে।
- সিক্রেট রোটেট করুন: ডাউনটাইম এড়াতে রোটেশনের সময় একাধিক সক্রিয় সিক্রেট সমর্থন করুন।
- ব্যর্থতা লগ করুন: ডিবাগিংয়ের জন্য সিগনেচার মিসম্যাচ এবং রিট্রাই রেকর্ড করুন।
- প্রকৃত পেলোড দিয়ে পরীক্ষা করুন: ইভেন্ট অনুকরণ করতে webhook.site বা আপনার প্রোভাইডারের CLI-এর মতো সরঞ্জাম ব্যবহার করুন।
সাধারণ প্রশ্ন
সাইনড ওয়েবহুক পেলোড কী?
একটি সাইনড পেলোডে একটি ক্রিপ্টোগ্রাফিক সিগনেচার (সাধারণত HMAC) থাকে যা প্রাপককে যাচাই করতে দেয় যে অনুরোধটি একটি বিশ্বস্ত উৎস থেকে এসেছে এবং টেম্পার করা হয়নি।
কর্মের পুনরাবৃত্তি না করে ওয়েবহুক রিট্রাই কীভাবে পরিচালনা করব?
ইভেন্ট আইডি ট্র্যাক করে আপনার হ্যান্ডলারকে আইডেম্পোটেন্ট করুন। প্রসেস করার আগে, আইডি আগে থেকেই হ্যান্ডল করা হয়েছে কিনা তা পরীক্ষা করুন; যদি তাই হয়, কাজ পুনরাবৃত্তি না করে সফলতা ফেরত দিন।
সিগনেচার ছাড়া ওয়েবহুক ব্যবহার করা যাবে?
প্রোডাকশনের জন্য এটি সুপারিশ করা হয় না। সিগনেচার ছাড়া, আপনি বৈধ অনুরোধ এবং জাল অনুরোধের মধ্যে পার্থক্য করতে পারবেন না। যখন উপলব্ধ, সর্বদা সিগনেচার যাচাই করুন।
ওয়েবহুক পেলোড ডিবাগ করার সময় বা সার্ভার লগ বিশ্লেষণ করার সময়, JSON ফরম্যাটার আপনাকে দ্রুত JSON কাঠামো পরিদর্শন এবং যাচাই করতে সহায়তা করতে পারে।