Server Action — form, mutation আর নিরাপত্তা

১ · Server Action কী — form থেকে সরাসরি server-এর function

একটি রেস্তোরাঁর কথা ভাবুন। আগে ওয়েটার আপনার অর্ডার শুনে একটি স্লিপ লিখতেন, রান্নাঘরের জানালায় দিতেন, রাঁধুনি রান্না করে প্লেট ফেরত পাঠাতেন। এখন ভাবুন টেবিলে একটি বোতাম আছে, যাতে লেখা “এক প্লেট খিচুড়ি”। চাপলেই অর্ডার রান্নাঘরে চলে যায়। স্লিপ লেখা, জানালা খোঁজা, কোন রাঁধুনি এই খাবার বানান তা মনে রাখা, এই কাজগুলো এখন রেস্তোরাঁর ব্যবস্থার দায়িত্ব।

Express-এ এতদিন আপনি নিজে স্লিপ লিখেছেন: একটি route (POST /api/cart), body parse, তারপর React-এ fetch. Next.js-এর Server Action সেই স্লিপের কাজটি framework-কে দেয়। আপনি server-এ একটি async function লেখেন, ওপরে "use server" লেখেন, তারপর সেটি সরাসরি <form action={…}>-এ বা একটি click handler-এ দেন। Route-এর নাম, URL আর body-র format Next.js নিজে ঠিক করে।

'use server'                     // every export of this file becomes a Server Action
import { revalidatePath } from 'next/cache'
import { db } from '@/lib/db'
import { currentUser, rateLimit } from '@/lib/auth'

export async function addToCart(productId: string) {
  const user = await currentUser()            // who is calling? read from the cookie
  if (!user) return { ok: false, message: 'আগে লগইন করুন' }
  if (!rateLimit('cart:' + user.id)) return { ok: false, message: 'একটু পরে চেষ্টা করুন' }
  const p = db.products.find((x) => x.id === String(productId))
  if (!p || p.stock < 1) return { ok: false, message: 'স্টক নেই' }
  p.stock -= 1
  db.carts.set(user.id, [...(db.carts.get(user.id) ?? []), p.id])
  revalidatePath('/')                          // re-render the shop page in the same response
  return { ok: true, message: 'ঝুড়িতে যোগ হলো' }
}

পুরো ফাইলের মাথায় 'use server' লিখলে প্রতিটি export একটি action. আরেক পথ হলো একটি Server Component-এর ভেতরে inline function লিখে তার প্রথম লাইনে 'use server' দেওয়া। Client Component-এর ভেতরে action বানানো যায় না, শুধু আলাদা ফাইল থেকে import করে ডাকা যায়। কোন component কোথায় চলে, তা পর্ব ৫২-এ (Server Component আর Client Component) আছে। এখানে শুধু মনে রাখুন: 'use client' একটি সীমানা, যার ওপারে কোড browser-এ যায়। 'use server' উল্টো দিকের সীমানা, যার ওপারের কোড কখনো browser-এ যায় না, যায় শুধু একটি ঠিকানা।

এই পর্বের সব Next.js আচরণ একটি ছোট সত্যিকারের project থেকে, যার নাম ~/bazarghar. ডেটা একটি in-memory module-এ, login একটি নকল cookie (sid-rahim-example, sid-admin-example), server বসেছে শুধু 127.0.0.1-এ। next build-এর সত্যিকারের ফল:

~/bazarghar$ npx next build
▲ Next.js 16.4.4 (Turbopack)
✓ Compiled successfully in 158ms
  Finished TypeScript in 1163ms ...
✓ Generating static pages using 7 workers (6/6) in 435ms

Route (app)
┌ ƒ /
├ ○ /_not-found
├ ƒ /admin
├ ○ /checkout
└ ○ /checkout/done

○  (Static)   prerendered as static content
ƒ  (Dynamic)  server-rendered on demand

/ আর /admin cookie পড়ে, তাই ƒ (প্রতি request-এ render). /checkout পাতাটি static (○), অথচ তার form একটি server function ডাকে। অর্থাৎ পাতা static হলেও action সব সময় request-এর সময় server-এ চলে। Rendering-এর চিহ্নগুলোর পূর্ণ মানে পর্ব ৫৫-এ আসবে, আর মানচিত্রটি দেখেছেন পর্ব ৩-এ (Rendering-এর মানচিত্র).

২ · Network tab-এ একটি action — POST, action ID আর উত্তর

“Function ডাকলাম” কথাটি সুন্দর, কিন্তু পরীক্ষা ছাড়া বিশ্বাস করবেন না। বাজারঘরের দোকানের পাতায় একটি “ঝুড়িতে দিন” বোতাম আছে, যা addToCart('p1') ডাকে। Edge-এ Playwright দিয়ে বোতামটি চেপে request-এর header ধরা হলো। DevTools-এর Network tab খুললে আপনিও ঠিক এই সারিটি দেখবেন (cookie আর কিছু browser header বাদ দেওয়া):

# সত্যিকারের run: Edge, next start, ক্লিক “ঝুড়িতে দিন”
POST http://127.0.0.1:3547/
  accept: text/x-component
  content-type: text/plain;charset=UTF-8
  next-action: 40998758fd943d2d9695574c1db2516544439ca2ca
  next-router-state-tree: %5B%22%22%2C%7B%22children%22%3A…
  origin: http://127.0.0.1:3547
  sec-fetch-site: same-origin
  BODY: ["p1"]
  STATUS 200 text/x-component

চারটি জিনিস খেয়াল করুন। URL হলো পাতারই URL (/), আলাদা কোনো /api নেই। কোন function চলবে, তা বলে next-action header-এর লম্বা hex মান, যাকে বলে action ID. Argument গেছে একটি JSON array হিসেবে: ["p1"]. আর উত্তরের ধরন text/x-component, যা React-এর নিজস্ব stream format.

এই ID কোথা থেকে এলো? Build-এর সময় compiler action-এর আসল কোড server-এ রাখে, আর client bundle-এ বসায় একটি ছোট প্রতিনিধি। নিজের build-এর ফাইলেই দেখা যায়:

~/bazarghar$ cat .next/server/server-reference-manifest.json   # অংশ
"40998758fd943d2d9695574c1db2516544439ca2ca": {
  "workers": { "app/admin/page": {…}, "app/page": {…} },
  "filename": "app/actions.ts",
  "exportedName": "addToCart"
}

~/bazarghar$ grep -o "createServerReference(\"4099[^)]*)" .next/static/chunks/*.js
createServerReference("40998758fd943d2d9695574c1db2516544439ca2ca",n.callServer,void 0,n.findSourceMapURL,"addToCart")

Browser-এর chunk-এ আছে ID, একটি dispatcher (callServer) আর function-এর নাম, কিন্তু currentUser, db বা rateLimit-এর একটি অক্ষরও নেই। Manifest server-কে বলে কোন ID কোন ফাইলের কোন export. Next.js-এর docs অনুযায়ী এই ID build-এর সময় তৈরি encrypted, অনুমান-অযোগ্য মান, নতুন build-এ বদলায় (build cache থাকলেও বড়জোর ১৪ দিনে)। তাই পুরোনো ট্যাব খোলা রেখে নতুন deploy হলে “Failed to find Server Action” error আসতে পারে।

৩ · JavaScript ছাড়াও চলে — progressive enhancement

ধরুন রাজশাহীর একজন ক্রেতা দুর্বল নেটওয়ার্কে বাজারঘরের checkout খুলেছেন। HTML এসে গেছে, কিন্তু JavaScript এখনো নামছে। পুরোনো SPA-তে এই কয়েক সেকেন্ড form মৃত, কারণ submit চালায় JavaScript. Server Action-এর form হলো একটি আসল HTML <form method="POST">, তাই browser নিজেই পাঠাতে পারে। আগে সাধারণ HTML কাজ করে, JavaScript এলে অভিজ্ঞতা আরও মসৃণ হয়। এই নকশার নাম progressive enhancement.

বাজারঘরের ঠিকানা form একটি Client Component, যেখানে useActionState(saveAddress, {}). Edge-এ দুবার চালানো হলো: একবার JavaScript চালু, একবার পুরো বন্ধ (javaScriptEnabled: false). প্রথমবার ভুল ডেটা, দ্বিতীয়বার ঠিক ডেটা।

# সত্যিকারের run ১: JavaScript বন্ধ (Edge)
REQ POST /checkout | next-action: None | content-type: multipart/form-data
   body: … name="$ACTION_REF_1" … name="$ACTION_1:0" {"id":"602092a114bef5…","bound":"$@1"} …
RES 200 /checkout | content-type: text/html; charset=utf-8
ERRORS {'name': 'নাম অন্তত ২ অক্ষর', 'phone': 'ফোন নম্বর ঠিক নয়', 'district': 'জেলা বাছুন', 'line': 'ঠিকানা আরও লিখুন'}
phone value kept: 0171
REQ POST /checkout | next-action: None | content-type: multipart/form-data
RES 303 /checkout | location: /checkout/done
URL /checkout/done | h1: ঠিকানা জমা হয়েছে

# সত্যিকারের run ২: JavaScript চালু (Edge)
REQ POST /checkout | next-action: 602092a114bef57827ec08672542a0850c312b4531 | content-type: multipart/form-data
RES 200 /checkout | content-type: text/x-component
ERRORS {… একই চারটি বার্তা …}
REQ POST /checkout | next-action: 602092a114bef57827ec08672542a0850c312b4531
RES 200 /checkout | content-type: text/x-component
URL /checkout/done | h1: ঠিকানা জমা হয়েছে

Next.js-এর docs আরও একটি সূক্ষ্ম কথা বলে: Client Component-এর form-এ JavaScript লোড হওয়ার আগে submit হলে React সেই submit সারিতে রাখে আর hydration-এ সেই অংশকে আগে নেয়। Server Component-এর form-এ JavaScript না এলেও সরাসরি পাঠানো যায়। Hydration-এর খুঁটিনাটি পর্ব ৫৬-এ। আর useActionState-এর তৃতীয় argument permalink লাগে তখন, যখন JavaScript আসার আগে জমা দেওয়া form-কে অন্য URL-এর পাতায় পৌঁছাতে হয়; এক পাতার form-এ সাধারণত লাগে না।

৪ · useActionState আর Zod — server থেকে field error ফেরানো

পর্ব ১২-এ (React-এর form) React 19-এর useActionState আর useFormStatus শিখেছেন: function পায় (prevState, formData), ফেরত মান হয় নতুন state, আর form-এর ভেতরের বোতাম pending জানে। Server Action-এ নতুন কিছু শিখতে হয় না, শুধু function-টি এখন server-এ। তাই একটি প্রশ্নের উত্তর জরুরি: ভুল হলে action কী ফেরত দেবে?

নিয়মটি পর্ব ২৮-এর (Error handling) মতোই। প্রত্যাশিত ভুল, যেমন ভুল ফোন নম্বর, হলো ফল, তাই ফেরত দিন। অপ্রত্যাশিত ভুল, যেমন database বন্ধ, হলো exception, তাই ছুড়ুন, যা error.js ধরবে (অংশ ৯)। প্রথমে নিচের লাইভ বাক্সটি দেখুন। এখানে একটি সাধারণ async function server-এর ভূমিকায় অভিনয় করছে, Next.js নেই, এটি একটি শিক্ষণ মডেল। বাক্সটি শুরুতে ভুল মান নিয়ে খোলে। “জমা দিন” চাপুন, তারপর ঠিক নাম আর নম্বর লিখে আবার চাপুন।

<div id="root"></div>
<script src="../course-kit/vendor/react-lab.js"></script>
<script type="text/jsx">
const wait = ms => new Promise(r => setTimeout(r, ms));
// teaching model: this async function plays the Server Action
async function saveAddress(prev, formData) {
  await wait(300);
  const v = Object.fromEntries(formData), errors = {};
  if (v.name.trim().length < 2) errors.name = 'নাম অন্তত ২ অক্ষর';
  if (!/^01[3-9]\d{8}$/.test(v.phone.trim())) errors.phone = 'ফোন নম্বর ঠিক নয়';
  console.log('server got', JSON.stringify(v), Object.keys(errors).length ? 'errors' : 'ok');
  return Object.keys(errors).length ? { errors, values: v } : { done: true, values: {} };
}
function Field({ name, label, state }) {
  return <p><label>{label} <input name={name} defaultValue={state.values?.[name]} /></label>
    <small style={{ color: 'crimson' }}> {state.errors?.[name]}</small></p>;
}
function Checkout() {
  const [state, action, pending] = useActionState(saveAddress, { values: { name: 'R', phone: '0171' } });
  console.log('render pending =', pending, 'errors =', JSON.stringify(state.errors ?? null));
  return <form action={action}>
    <Field name="name" label="নাম" state={state} />
    <Field name="phone" label="ফোন" state={state} />
    <button disabled={pending}>{pending ? 'জমা হচ্ছে…' : 'জমা দিন'}</button>
    {state.done && <p role="status">ঠিকানা জমা হয়েছে</p>}
  </form>;
}
createRoot(document.getElementById('root')).render(<Checkout />);
</script>

Server-এ আসল যাচাই: Zod-এর safeParse

নিয়মগুলো হাতে if দিয়ে না লিখে একটি schema-তে রাখুন। পর্ব ২১-এ একই Zod schema browser আর server দুই জায়গায় চালিয়েছেন, আর পর্ব ২৭-এ Express-এ schema দিয়ে request যাচাই করেছেন। Server Action-এ পদ্ধতি একই: FormData থেকে মান তুলুন, safeParse চালান, ব্যর্থ হলে z.flattenError দিয়ে field error-এর একটি object বানান।

const Address = z.object({
  name: z.string().trim().min(2, 'নাম অন্তত ২ অক্ষর'),
  phone: z.string().trim().regex(/^01[3-9]\d{8}$/, 'ফোন নম্বর ঠিক নয়'),
  district: z.enum(['Dhaka', 'Rajshahi', 'Khulna'], { error: 'জেলা বাছুন' }),
  line: z.string().trim().min(5, 'ঠিকানা আরও লিখুন').max(200),
})

export async function saveAddress(prev: AddressState, formData: FormData): Promise<AddressState> {
  const user = await currentUser()
  if (!user) return { errors: { form: ['আগে লগইন করুন'] } }
  const raw = Object.fromEntries(['name', 'phone', 'district', 'line']
    .map((k) => [k, String(formData.get(k) ?? '')]))
  const parsed = Address.safeParse(raw)
  if (!parsed.success) return { errors: z.flattenError(parsed.error).fieldErrors, values: raw }
  db.addresses.push({ userId: user.id, ...parsed.data })   // userId from the session, never the form
  redirect('/checkout/done')
}

Zod-এর ভেতরে আসলে কী ঘটে? নিচের ছোট শিক্ষণ মডেলটি একই আকারের ফল দেয়। প্রতিটি field-এর একটি নিয়ম, নিয়ম ভাঙলে বার্তা, আর schema-তে নেই এমন key বাদ।

// A tiny Zod-like teaching model: each rule returns an error message or null.
const rules = {
  name: (v) => (v.length >= 2 ? null : 'নাম অন্তত ২ অক্ষর'),
  phone: (v) => (/^01[3-9]\d{8}$/.test(v) ? null : 'ফোন নম্বর ঠিক নয়'),
  district: (v) => (['Dhaka', 'Rajshahi', 'Khulna'].includes(v) ? null : 'জেলা বাছুন'),
  line: (v) => (v.length >= 5 && v.length <= 200 ? null : 'ঠিকানা আরও লিখুন'),
};

function safeParse(input) {
  const fieldErrors = {};
  const data = {};
  for (const [key, check] of Object.entries(rules)) {
    const value = typeof input[key] === 'string' ? input[key].trim() : '';
    const error = check(value);
    if (error) fieldErrors[key] = [error];
    else data[key] = value;
  }
  // keys without a rule (a forged "price", say) never reach data
  return Object.keys(fieldErrors).length
    ? { success: false, fieldErrors }
    : { success: true, data };
}

const tries = [
  { name: 'R', phone: '0171', line: 'abc' },
  { name: ' Rahim ', phone: '01712345678', district: 'Rajshahi', line: 'House 12, Road 3', price: '1' },
];
for (const t of tries) console.log(JSON.stringify(safeParse(t)));

৫ · Mutation-এর পরে — revalidate, redirect আর একটি roundtrip

ডেটা বদলানোর পরে পর্দা পুরোনো থাকলে ব্যবহারকারী ভাবেন কাজ হয়নি, আবার চাপেন। তাই action-এর শেষে বলে দিতে হয় কোন cache পুরোনো হলো। পর্ব ১৯-এ TanStack Query-তে এ কাজ ছিল invalidateQueries. Next.js-এ server-এর cache আর client router দুটোই আছে, আর cache-এর পুরো গল্প পর্ব ৫৩-এ (Data fetching আর cache). এখানে শুধু action থেকে কোন ডাক কখন:

Next.js 16-এ updateTag আর refresh নতুন, আর revalidateTag এখন একটি দ্বিতীয় argument (cache-life profile) চায়। পুরোনো টিউটোরিয়ালে এক argument-এর revalidateTag('x') দেখলে সেটি আগের যুগের। এই নামগুলো আপনার version-এর docs-এ মিলিয়ে নিন।

সবচেয়ে সুন্দর অংশ হলো roundtrip-এর সংখ্যা। revalidatePath ডাকলে Next.js action চালায়, তারপর একই request-এর ভেতরে পাতাটি আবার render করে, আর উত্তরে দুটিই পাঠায়। ল্যাবে মাপা হলো: লগইন ছাড়া addToCart-এর উত্তর (কোনো revalidate নেই) ছিল 2 লাইন, ১২২ byte. রহিমের সফল ডাকে (revalidatePath('/') সহ) উত্তর 22 লাইন, যার ভেতরে ফেরত মান আর নতুন পাতার গাছ দুটোই। ধাপে ধাপে দেখুন:

POST /
next-action: 40998758fd94…
origin: http://127.0.0.1:3547
cookie: sid=sid-rahim-example
body: ["p1"]

origin host  127.0.0.1:3547
host         127.0.0.1:3547   মিলেছে
body         6 byte ≤ 1 MB    ঠিক আছে
action ID    manifest-এ আছে → addToCart

[addToCart] p1 user = u1
p1.stock     3 → 2
cart(u1)     [] → ["p1"]
return       { ok: true, message: 'ঝুড়িতে যোগ হলো' }

Home() আবার চলে
  count = carts.get('u1').length = 1
  p1 stock = 2
নতুন RSC payload তৈরি

0:{"a":"$@1","q":"","i":false,"t":{…নতুন গাছ…}}
1:{"ok":true,"message":"ঝুড়িতে যোগ হলো"}
9:[…"p",null,{"id":"cart","children":["ঝুড়িতে: ",1]}…
   …"Miniket Rice 5kg"," — ৳",450," — stock ",2…]

Redirect: try/catch-এর বাইরে, revalidate-এর পরে

redirect() আসলে একটি বিশেষ error ছোড়ে, যা Next.js ধরে route বদলায়। তাই এর পরের কোনো লাইন চলে না। দুটি নিয়ম এখান থেকে আসে। এক, গন্তব্য পাতায় নতুন ডেটা লাগলে revalidatePath আগে ডাকুন। দুই, redirect-কে নিজের try { … } catch-এর ভেতরে রাখবেন না, নইলে আপনার catch সেই বিশেষ error গিলে ফেলবে আর redirect হবে না। saveAddress-এ তাই redirect একেবারে শেষ লাইনে, কোনো try-র বাইরে।

৬ · useOptimistic — আগে দেখান, ব্যর্থ হলে ফেরান

বিকাশে টাকা পাঠালে অ্যাপ সঙ্গে সঙ্গে “প্রক্রিয়াধীন” দেখায়, নিশ্চিত হলে সবুজ টিক, ব্যর্থ হলে টাকা ফেরত। Optimistic update-এর ভাবনা একই: server-এর উত্তরের অপেক্ষা না করে পর্দা আগেই বদলান, তারপর সত্যি মিলিয়ে নিন। পর্ব ১৯-এ TanStack Query দিয়ে এটি হাতে করেছেন। React 19-এ এর জন্য একটি hook আছে: useOptimistic(state, update). এটি একটি অস্থায়ী মান দেয়, যা চলমান action-এর সময় টিকে থাকে; action শেষ হলে React আবার আসল state দেখায়।

নিচের বাক্সে server-এ stock মাত্র ১টি। প্রথম ক্লিক সফল, দ্বিতীয়টি ব্যর্থ হবে। এটিও শিক্ষণ মডেল; addToCart এখানে একটি স্থানীয় async function.

<div id="root"></div>
<script src="../course-kit/vendor/react-lab.js"></script>
<script type="text/jsx">
const wait = ms => new Promise(r => setTimeout(r, ms));
let stock = 1;                       // teaching model of the server's stock
async function addToCart() {
  await wait(400);
  if (stock < 1) throw new Error('স্টক নেই');
  stock -= 1;
}
function Cart() {
  const [count, setCount] = useState(0);              // what the server confirmed
  const [shown, addShown] = useOptimistic(count, (c, n) => c + n);
  const [msg, setMsg] = useState('');
  console.log('render count =', count, 'shown =', shown, 'msg =', msg || '-');
  async function add() {
    addShown(1);                                      // show it at once
    try {
      await addToCart();
      startTransition(() => { setCount(c => c + 1); setMsg('যোগ হলো'); });
    } catch (e) {
      startTransition(() => setMsg(e.message));       // shown falls back to count
    }
  }
  return <form action={add}>
    <button>ঝুড়িতে দিন</button> <b>ঝুড়িতে: {shown}</b> <span role="status">{msg}</span>
  </form>;
}
createRoot(document.getElementById('root')).render(<Cart />);
</script>

আসল Next.js-এ এই কাজ আরও সরল, কারণ নিশ্চিত মান আসে server থেকে, Server Component-এর prop হয়ে। বাজারঘরের CartButton:

'use client'
import { useOptimistic, useState } from 'react'
import { addToCart } from './actions'

export default function CartButton({ productId, count }: { productId: string; count: number }) {
  const [shown, addShown] = useOptimistic(count, (c: number, n: number) => c + n)
  const [msg, setMsg] = useState('')
  async function add() {
    addShown(1)                          // optimistic +1 while the action runs
    const r = await addToCart(productId) // revalidatePath sends the new count as a prop
    setMsg(r.message)
  }
  return (
    <form action={add} style={{ display: 'inline' }}>
      <button>ঝুড়িতে দিন ({shown})</button> <span role="status">{msg}</span>
    </form>
  )
}

সত্যিকারের run-এ (Edge, next start) Mustard Oil-এর stock ছিল ১। বোতামটি দুবার চাপা হলো, প্রতিবার ৮০০ ms অপেক্ষা। পর্দার প্রতিটি বদল একটি MutationObserver দিয়ে ধরা হয়েছে:

1addShown(1)2const r = await addToCart(id)3setMsg(r.message)4// server: revalidatePath('/')5// server: { ok: false } → no revalidate

৭ · প্রতিটি action একটি public endpoint — যাচাই action-এর ভেতরে

এই পর্বের সবচেয়ে জরুরি কথা এটি। অংশ ২-এ দেখেছেন, একটি action মানে একটি POST, যাতে একটি ID. যে কেউ সেই POST পাঠাতে পারেন: curl, একটি স্ক্রিপ্ট, বা ব্রাউজারের console. Next.js-এর docs-এর ভাষায়, প্রতিটি action-কে একটি অবিশ্বস্ত entry point ধরুন। পাতায় login যাচাই থাকলেও সেটি শুধু ঠিক করে কোন UI দেখানো হবে; action একটি আলাদা দরজা।

বাজারঘরের /admin পাতা শুরুতেই if (user?.role !== 'admin') redirect('/') করে। ল্যাবে দুটি delete action আছে: deleteProduct, যার ভেতরে role যাচাই, আর শুধু ল্যাবের জন্য deleteProductUnsafe, যেখানে কোনো যাচাই নেই। প্রথমে ধারণাটি একটি শিক্ষণ মডেলে দেখুন। নিচের node:http server Next.js নয়, কিন্তু একই আকার মেনে চলে: header-এ action ID, body-তে argument-এর JSON array, আর একটি ID থেকে function-এর তালিকা।

const http = require('node:http');
// Teaching model of an action endpoint. Fake local data only.
const products = ['p1', 'p2', 'p3'];
const sessions = { 'sid-rahim-example': { id: 'u1', role: 'customer' } };
const remove = (id) => products.splice(products.indexOf(id), 1);
const actions = {                       // action id -> function (like a manifest)
  a1: async (user, id) => { remove(id); return 'deleted ' + id; },          // no check
  a2: async (user, id) => {
    if (user?.role !== 'admin') throw new Error('Forbidden');              // check inside
    remove(id); return 'deleted ' + id;
  },
};
const server = http.createServer(async (req, res) => {
  let body = '';
  for await (const chunk of req) body += chunk;
  if (new URL(req.headers.origin).host !== req.headers.host) return res.end('403 origin mismatch');
  const user = sessions[(req.headers.cookie ?? '').replace('sid=', '')];
  try { res.end('200 ' + await actions[req.headers['next-action']](user, ...JSON.parse(body))); }
  catch (e) { res.end('500 ' + e.message); }
});
server.listen(0, '127.0.0.1', async () => {
  const base = 'http://127.0.0.1:' + server.address().port;
  const call = async (label, id, args, extra = {}) => {
    const headers = { 'next-action': id, origin: base, ...extra };
    const r = await fetch(base, { method: 'POST', headers, body: JSON.stringify(args) });
    console.log(label.padEnd(24), await r.text(), '| left:', products.join(','));
  };
  await call('a1, no login', 'a1', ['p3']);
  await call('a2, rahim (customer)', 'a2', ['p2'], { cookie: 'sid=sid-rahim-example' });
  await call('a2, other origin', 'a2', ['p2'], { origin: 'http://evil.example' });
  server.close();
});

এবার আসল Next.js. নিজের ল্যাবের server-এ (127.0.0.1:3547), নিজের build-এর manifest থেকে নেওয়া ID দিয়ে, একটি ছোট node স্ক্রিপ্ট UI ছাড়া চারটি POST পাঠাল। প্রতিটির header ছিল Next-Action: <ID>, Content-Type: text/plain আর ঠিক origin. সত্যিকারের run:

~/bazarghar$ node direct.mjs auth
1 no cookie    { status: 200, text: '0:{"a":"$@1",…}\n1:{"ok":false,"message":"আগে লগইন করুন"}\n' }
2 rahim        { status: 200, text: '2:"$Sreact.fragment"\n3:"/_next/static/chunks/…' }   # নতুন পাতাসহ
3 delete rahim { status: 200, text: '0:{"a":"$@1",…}\n1:E{"digest":"3545386112"}\n' }
4 unsafe none  { status: 200, text: '0:{"a":"$@1",…}\n1:"$undefined"\n' }

# একই সময়ে server-এর log
[addToCart] p1 user = none
[addToCart] p1 user = u1
[deleteProduct] p2 role = customer
⨯ Error: Forbidden
    at …  { digest: '3545386112' }
[deleteProductUnsafe] p2

1// Next.js: Origin, size, ID → OK2export async function deleteProduct(id) {3  const user = await currentUser()4  if (user?.role !== 'admin')5    throw new Error('Forbidden')6  db.products = db.products.filter(…)7  revalidatePath('/')8}

Role যাচাই যথেষ্ট নয়, ownership-ও লাগে। “রহিম কি customer” প্রশ্নের পরে “এই ঠিকানা কি রহিমের” প্রশ্ন। পর্ব ৪৮-এ (Permission) নিজের ল্যাবে IDOR ঘটিয়ে বন্ধ করেছেন; Server Action-এ ঠিক একই বাগ হয়, যখন action client থেকে পুরো object নেয় আর তার id-তে ভরসা করে। Next.js docs-এর পরামর্শ: client থেকে শুধু ID আর পরিবর্তনটি নিন, বাকি সব session আর database থেকে নিজে পড়ুন, আর query-তে ownerId: user.id শর্ত দিন। এই যাচাইগুলো এক জায়গায় রাখতে একটি Data Access Layer বানান, যা server-only আর যার প্রতিটি function নিজে authorization করে।

৮ · Framework-এর পাহারা — closure encryption, Origin, body আর rate limit

আপনার যাচাই প্রধান, তবে Next.js-ও কয়েকটি দেয়াল তোলে। প্রতিটি দেয়াল নিজের ল্যাবে ধাক্কা দিয়ে দেখা হয়েছে।

Closure-এর মান: encrypt হয়ে browser ঘুরে আসে

Server Component-এর ভেতরে লেখা inline action বাইরের ভ্যারিয়েবল মনে রাখতে পারে; JavaScript-এর এই ক্ষমতার নাম closure (JavaScript-এর closure পর্ব)। বাজারঘরের admin পাতায় প্রতিটি পণ্যের পাশে একটি “margin” বোতাম, যার action কেনা দাম cost মনে রাখে। কেনা দাম ক্রেতার দেখার কথা নয়।

{db.products.map((p) => {
  const cost = p.cost                    // captured by the inline action below
  async function checkMargin() {
    'use server'
    console.log('[checkMargin]', p.id, 'cost =', cost)
  }
  return <form key={p.id} action={checkMargin}><button>margin</button></form>
})}

কিন্তু action তো পরে, আলাদা request-এ চলবে। তখন cost-এর মান কোথা থেকে আসবে? Server মনে রাখে না; মানটি পাতার সাথে browser-এ যায় আর ক্লিকে ফিরে আসে। Admin-এর HTML-এ সত্যিকারের run:

HIDDEN $ACTION_3:0 = {"id":"4087a8854458e7f285a027efecd633b444ccde0dae" …
HIDDEN $ACTION_3:1 = ["$@2"]
HIDDEN $ACTION_3:2 = "3tnI/Q7nYbtCzFvlmWoijUP4RQjQy4G4rz2a2jUiAQUyrngYz9c4cmIaHNDb2I45…
HIDDEN $ACTION_4:2 = "pgyAxkJSL2glIF/Dq5s1OXfCXgqQqQqk3V9LVVGwHYz6QIvbb6HyUp72r9GRT/cR…
"410" in HTML: False | "cost" in HTML: False

দুই পণ্যের জন্য দুটি লম্বা base64 মান, যা encrypt করা bound মান। কেনা দাম 410 HTML-এ কোথাও নেই। Docs অনুযায়ী প্রতিটি build-এ নতুন key তৈরি হয়, তাই এক build-এর action অন্য build-এ চলে না, আর একাধিক server-এ চালালে সবার জন্য একই key দিতে NEXT_SERVER_ACTIONS_ENCRYPTION_KEY (base64, ১৬/২৪/৩২ byte) environment-এ রাখতে হয়। একই docs স্পষ্ট বলে, শুধু encryption-এর ওপর ভরসা করে গোপন মান পাঠাবেন না। ভালো অভ্যাস হলো closure-এ শুধু ID রাখা, আর গোপন মান action-এর ভেতরে database থেকে পড়া।

CSRF: Origin বনাম Host

CSRF-এর তত্ত্ব CSRF আর cookie পর্বে আর পর্ব ৫০-এ (অ্যাপের নিরাপত্তা তালিকা). Action শুধু POST মেনে নেয়, আর আধুনিক browser-এ cookie ডিফল্টে SameSite=Lax-এর মতো আচরণ করে, যা বেশিরভাগ cross-site POST-এ cookie পাঠায় না। এর ওপরে Next.js request-এর Origin header-এর host নিজের host (বা x-forwarded-host)-এর সাথে মেলায়। নিজের ল্যাবে Origin: http://evil.example দিয়ে পাঠানো হলো:

evil origin { status: 500, text: '0:{"a":"$@1",…}\n1:E{"digest":"3473614277"}\n' }

# server log (সত্যিকারের)
`x-forwarded-host` header with value `127.0.0.1:3547` does not match `origin` header
with value `evil.example` from a forwarded Server Actions request. Aborting the action.
⨯ Error: Invalid Server Actions request.

Action-এর ভেতরের console.log এবার ছাপা হয়নি, অর্থাৎ কোড চলেইনি। Proxy বা CDN-এর পেছনে ভিন্ন domain থেকে action আসলে experimental.serverActions.allowedOrigins-এ সেই host যোগ করতে হয়। একটি ফাঁকও জেনে রাখুন: docs অনুযায়ী যে request-এ Origin header-ই নেই, সেটি সতর্কবার্তা দিয়ে পার হয়। ল্যাবে Origin ছাড়া পাঠানো ডাকটি সত্যিই action পর্যন্ত গেছে ([addToCart] p1 user = none). আধুনিক browser POST-এ Origin পাঠায়, তাই এটি মূলত স্ক্রিপ্টের পথ, আর স্ক্রিপ্টের হাতে আপনার ব্যবহারকারীর cookie থাকে না। কিন্তু এই কারণেই action-এর ভেতরের login যাচাই বাদ দেওয়া যায় না।

Body সীমা: ১ MB

Action-এর request body ডিফল্টে ১ MB, অর্থাৎ 1,048,576 byte পর্যন্ত। ল্যাবে 1,048,590 byte-এর একটি body পাঠানো হলো, সীমার চেয়ে মাত্র ১৪ byte বেশি:

bytes 1048590 { status: 500, text: '0:{"a":"$@1",…}\n1:E{"digest":"2494380138"}\n' }
⨯ Error: Body exceeded 1 MB limit.
To configure the body size limit for Server Actions, see: https://nextjs.org/docs/app/api-reference/next-config-js/serverActions#bodysizelimit
  statusCode: 413,

Error object-এ statusCode: 413 থাকলেও HTTP উত্তর ছিল 500. সীমা বাড়াতে experimental.serverActions.bodySizeLimit: '2mb'. Docs মনে করিয়ে দেয়, সীমা কাঁচা body-র ওপর, তাই multipart-এর boundary আর header-এর জন্য ১০ থেকে ২০ KB বাড়তি জায়গা রাখুন। বড় ফাইল action দিয়ে না পাঠিয়ে পর্ব ৩০-এর stream বা পর্ব ৬৪-এর presigned URL ভালো পথ। এটি পর্ব ২৭-এর Express body limit-এরই আরেক রূপ।

Rate limit: আপনার কাজ

Framework কতবার ডাকা যাবে তা গোনে না। পর্ব ৪৯-এ login-এর rate limit দেখেছেন; action-এও একই দরকার, বিশেষ করে যেগুলো email পাঠায় বা stock কমায়। বাজারঘরের rateLimit একটি সহজ fixed window: প্রতি ব্যবহারকারী ৬০ সেকেন্ডে ৫ বার। Admin-এর cookie দিয়ে সাতবার ডাকা হলো (p1-এর stock ৩):

~/bazarghar$ node direct.mjs rate
1 "message":"ঝুড়িতে যোগ হলো"
2 "message":"ঝুড়িতে যোগ হলো"
3 "message":"ঝুড়িতে যোগ হলো"
4 "message":"স্টক নেই"
5 "message":"স্টক নেই"
6 "message":"একটু পরে চেষ্টা করুন"
7 "message":"একটু পরে চেষ্টা করুন"

৫ পর্যন্ত গোনা হয়েছে, তাই ষষ্ঠ ডাক থেকে থামানো। এই limiter একটি process-এর memory-তে থাকে, তাই কয়েকটি server বা serverless-এ এটি ভাঙে; সেখানে Redis-এর মতো ভাগ করা store লাগে (পর্ব ৪৪, আর তত্ত্ব rate limiting পর্বে)। Fixed window-এর একটি দুর্বলতাও আছে: জানালার শেষ সেকেন্ডে ৫ আর পরের জানালার প্রথম সেকেন্ডে ৫, অর্থাৎ ২ সেকেন্ডে ১০টি ডাক।

৯ · Error, error.js আর কোন পথ কখন — action, route handler, tRPC

অপ্রত্যাশিত ভুলে action error ছুড়লে নিকটতম error.js (বা error.tsx) ধরে, যা একটি Client Component আর React-এর error boundary. বাজারঘরের ল্যাবে brokenAction ইচ্ছা করে এমন একটি বার্তা ছোড়ে, যাতে একটি নকল host আর password=example-secret. Production build-এ admin হিসেবে বোতাম চাপার পরে সত্যিকারের ফল:

# পর্দায় (app/error.tsx)
কিছু একটা ভুল হয়েছে | Minified React error #441; visit https://react.dev/errors/441 … | digest: 3490098926

# server log
⨯ Error: db connection lost: host=10.0.0.5 password=example-secret
  digest: '3490098926'

React-এর error code তালিকায় ৪৪১ মানে: “An error occurred in the Server Components render. The specific message is omitted in production builds to avoid leaking sensitive details.” অর্থাৎ production-এ আসল বার্তা browser-এ যায় না, যায় শুধু একটি digest, যা দিয়ে আপনি server log-এ আসল লাইন খুঁজে পান। এটিই error masking. তবু গোপন তথ্য error বার্তায় না রাখাই ভালো, কারণ log-ও অনেকে দেখেন। next dev-এ আসল বার্তা দেখা যায়, তাই dev-এ সব ঠিক দেখে production-এ অবাক হবেন না। এ জন্যই প্রত্যাশিত ভুল (ভুল ফোন, stock নেই) ফেরত দেওয়া হয়, ছোড়া নয়: ছুড়লে ব্যবহারকারী পান শুধু “কিছু একটা ভুল হয়েছে”।

Client Component থেকে ডাকা, আর একটির পর একটি

Action form ছাড়াও ডাকা যায়: onClick-এ, বা useEffect-এ, সাধারণত startTransition-এর ভেতরে, যাতে pending জানা যায়। বাজারঘরের admin বোতাম ঠিক তাই করে: onClick={() => start(() => deleteProduct(id))}. Server Component থেকে action prop হিসেবে Client Component-এ পাঠানোও চলে। একটি আচরণ মনে রাখুন: docs অনুযায়ী Next.js একটি client থেকে action একটির পর একটি পাঠায়। তিনটি ক্লিক দ্রুত দিলে দ্বিতীয়টি প্রথমটির শেষের অপেক্ষা করে। তাই action দিয়ে সমান্তরালে ডেটা আনার চেষ্টা (Promise.all) কাজ করে না; পড়ার কাজ Server Component-এ করুন। এর মানে এ-ও নয় যে server-এ action-গুলো সারিতে থাকে; অন্য ট্যাব বা স্ক্রিপ্টের ডাক একসাথে আসতে পারে, তাই stock কমানোর মতো কাজে পর্ব ৪৩-এর transaction এখনো লাগে।

তিন পথের তুলনা

পর্ব ৩৭-এ (Type-safe API) tRPC দেখেছেন; Server Action সেই “server-এর function, type-সহ” ধারণার একটি অংশ framework-এর ভেতরে এনেছে, তবে শুধু Next.js-এর নিজের UI-র জন্য। মোবাইল অ্যাপ বা অন্য কোনো client যদি একই কাজ করতে চায়, তার জন্য পর্ব ৫৭-এর route handler, কারণ action-এর ID বদলায় আর format React-এর নিজস্ব। আর payment gateway-র webhook কখনো action নয়; তার নিজের signature যাচাই লাগে (পর্ব ৬৫)। সম্প্রদায়ে মতভেদ আছে: কেউ পড়া-লেখা সব action-এ নিতে চান, কেউ action শুধু form-এ রাখেন আর বাকি API আলাদা রাখেন। ছোট দলের ছোট অ্যাপে action সময় বাঁচায়; অনেক client থাকলে স্পষ্ট API-ই টেকে।

১০ · AI-এর যুগে Server Action

AI খুব সহজে Server Action লেখে, আর কোডটি প্রায়ই চলে। বিপদ হলো, “চলে” আর “নিরাপদ” আলাদা জিনিস। UI দিয়ে পরীক্ষা করলে যাচাইহীন action আর যাচাইসহ action একই রকম দেখায়; পার্থক্য ধরা পড়ে শুধু UI ছাড়া ডাকলে।

AI-এর লেখা action হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি 'use server' function-এর শুরুতে login, তারপর role বা ownership যাচাই আছে
• নিজের ল্যাবে UI ছাড়া, cookie ছাড়া action ডেকে দেখেছি: ডেটা বদলায়নি
• সব input server-এ schema দিয়ে যাচাই; দাম, মালিক, অবস্থা client থেকে নেওয়া হয়নি
• Network tab-এ উত্তর পড়েছি: অপ্রয়োজনীয় field বা গোপন তথ্য নেই
• JavaScript বন্ধ করে form জমা দিয়েছি, আর next build ও next start-এ error বার্তা দেখেছি
• Diff-এ কোনো অজানা package নেই, secret কোনো client ফাইলে বা NEXT_PUBLIC_ নামে নেই