Web Locks API પાંચ ખુલ્લી ટેબ્સને એકસાથે refresh-token કોલ્સ દ્વારા auth સર્વર પર હુમલો કરતા અટકાવી શકે છે, જેનાથી વપરાશકર્તાઓને અચાનક લોગઆઉટ થવાથી બચાવી શકાય છે. ટેબ્સ વચ્ચે રિફ્રેશને સંકલિત કરીને, એક જ વિનંતી તે પૂર (flood) ને બદલે કામ કરે છે જે સામાન્ય રીતે Refresh Token Rotation નો ઉપયોગ કરતી વખતે સેશન-કિલ (session-kill) ટ્રિગર કરે છે.
મલ્ટી-ટેબ સેશનમાં છુપાયેલ ઓવરલોડ
એક સામાન્ય સિંગલ-પેજ એપમાં Axios interceptor ઉમેરવામાં આવે છે જે 401 પ્રતિસાદ (response) પર નજર રાખે છે, isRefreshing બુલિયન ફ્લેગ બદલે છે, અને નવો JWT આવે ત્યાં સુધી કોઈપણ બહાર જતી વિનંતીઓને ક્યુ (queue) માં રાખે છે. એક ટેબમાં ટેસ્ટ કરવામાં આવે તો, આ પ્રક્રિયા સચોટ રીતે કામ કરે છે.
એ જ એપને પાંચ ટેબમાં ખોલો, access token ને એક્સપાયર થવા દો, અને પાંચેય ટેબ્સ એક જ મિલિસેકન્ડમાં 401 નો અનુભવ કરશે. દરેક ટેબ વિચારે છે કે તેણે રિફ્રેશ કરવું જ પડશે, તેથી પાંચ સમાન refresh-token વિનંતીઓ auth સર્વર તરફ દોડે છે. Refresh Token Rotation સાથે—જે એક સુરક્ષા પગલું છે જે નવું ટોકન ઇશ્યૂ થતાની સાથે જ જૂના refresh token ને અમાન્ય ઠેરવે છે—સર્વર બીજી વિનંતીને replay attack તરીકે જુએ છે, સેશનને જોખમમાં (compromised) હોવાનું માને છે, અને તેને રદ કરે છે. વપરાશકર્તા તરત જ દરેક ટેબમાંથી લોગઆઉટ થઈ જાય છે.
આનું મૂળ કારણ JavaScript નું isolation model છે. isRefreshing જેવું વેરિએબલ ફક્ત તે ટેબમાં જ રહે છે જેણે તેને સેટ કર્યું છે; અન્ય ટેબ્સ પાસે એ જાણવાનો કોઈ રસ્તો નથી કે રિફ્રેશ પ્રક્રિયા પહેલેથી જ ચાલુ છે. પરિણામ એક ક્લાસિક concurrency સમસ્યા છે, પરંતુ અહીં "processes" થ્રેડ્સને બદલે બ્રાઉઝર ટેબ્સ છે.
ક્રોસ-ટેબ લોક (cross-tab lock) શા માટે યોગ્ય સાધન છે
આપણને એવી રીતની જરૂર છે જેનાથી ટેબ્સ એકબીજા સાથે શેર કરેલા રિસોર્સ વિશે વાત કરી શકે—આ કિસ્સામાં, નવો JWT. Web Locks API, જે navigator.locks તરીકે ઉપલબ્ધ છે, તે બરાબર તે જ કામ આપે છે. તે સ્ક્રિપ્ટ્સને એક નામવાળું લોક (lock) વિનંતી કરવા દે છે જેને બ્રાઉઝર સમાન ઓરિજિન (origin) ધરાવતા તમામ સંદર્ભોમાં લાગુ કરે છે. જો લોક પહેલેથી જ પકડાયેલું હોય, તો અન્ય કોલર્સને ત્યાં સુધી ક્યુમાં રાખવામાં આવે છે જ્યાં સુધી ધારક તેને મુક્ત ન કરે અથવા બ્રાઉઝર તેને રદ ન કરે (દા.ત., જ્યારે ટેબ ક્રેશ થાય ત્યારે). કોઈ બાહ્ય સર્વર નહીં, કોઈ polling નહીં, ફક્ત નેટિવ બ્રાઉઝર સંકલન.
લોક-આધારિત રિફ્રેશ ફ્લોનું અમલીકરણ
- 401 શોધો – Axios interceptor અગાઉની જેમ જ અનધિકૃત (unauthorized) પ્રતિસાદને પકડે છે.
- એક્સક્લુઝિવ લોક માટે વિનંતી કરો – ટેબ
navigator.locks.request('auth_token_refresh_lock', async lock => { … })કોલ કરે છે. એક સમયે માત્ર એક જ ટેબ callback માં પ્રવેશી શકે છે. - નેટવર્કનો ઉપયોગ કરતા પહેલા ફરીથી તપાસો – લોકની અંદર,
localStorageમાંથી ટાઈમસ્ટેમ્પ (અથવા ટોકન પોતે) વાંચો. જો ટાઈમસ્ટેમ્પ થોડી સેકન્ડોથી જૂનો હોય, તો અન્ય ટેબ પહેલેથી જ ટોકન રિફ્રેશ કરી ચૂક્યું છે; વર્તમાન ટેબ નેટવર્ક કોલ સ્કીપ કરે છે અને ફક્ત સ્ટોરેજમાંથી નવો JWT વાંચે છે. - જો જરૂર હોય તો રિફ્રેશ કરો – જો સંગ્રહિત ટાઈમસ્ટેમ્પ જૂનો હોય, તો રિફ્રેશ વિનંતી મોકલો, નવું ટોકન અને વર્તમાન સમય
localStorageમાં સ્ટોર કરો, અને પછી callback માંથી return કરીને લોક મુક્ત કરો. - ક્યુમાં રહેલી વિનંતીઓ ફરી શરૂ કરો – અન્ય તમામ ટેબ્સ જે રાહ જોઈ રહી હતી તે એક પછી એક લોક મેળવે છે, નવો ટાઈમસ્ટેમ્પ જુએ છે, અને બીજી કોઈ વિનંતી કર્યા વિના પ્રક્રિયા પૂર્ણ કરે છે.
async function refreshIfNeeded() {
await navigator.locks.request('auth_token_refresh_lock', async lock => {
const lastRefresh = Number(localStorage.getItem('token_refreshed_at') || 0);
const now = Date.now();
if (now - lastRefresh < 5_000) return; // another tab already refreshed
const newToken = await callRefreshEndpoint(); // actual network call
localStorage.setItem('jwt', newToken);
localStorage.setItem('token_refreshed_at', now.toString());
});
}
આ પેટર્ન ખાતરી આપે છે કે, ગમે તેટલી ટેબ્સ ખુલ્લી હોય, સર્વર પર માત્ર એક જ રિફ્રેશ વિનંતી પહોંચે છે.
તમે માપી શકો તેવા ફાયદાઓ
- નેટવર્ક કાર્યક્ષમતા – એક વિનંતી પાંચનું સ્થાન લે છે, જેનાથી બેન્ડવિડ્થ અને સર્વર લોડમાં મોટો ઘટાડો થાય છે.
- સેશન સુરક્ષા – Refresh Token Rotation સાથે, સર્વર જૂના refresh token નો માત્ર એક જ ઉપયોગ જુએ છે, તેથી તે ક્યારેય સેશનને જોખમમાં (compromised) હોવાનું ફ્લેગ કરતું નથી.
- સ્થિતિસ્થાપકતા (Resilience) – જો લોક પકડી રાખતી ટેબ ક્રેશ થાય છે, તો બ્રાઉઝર આપમેળે લોક મુક્ત કરે છે, જે ડેડલોક (deadlock) ને અટકાવે છે જે અન્યથા તમામ ટેબ્સને અટકાવી શકે છે.
- સ્કેલેબિલિટી – વપરાશકર્તાઓ કેસ્કેડ લોગઆઉટનું જોખમ લીધા વિના ડઝનબંધ ટેબ્સ ખોલી શકે છે, કારણ કે સંકલન બ્રાઉઝરની અંદર જ રહે છે.
બીજી બાજુ: બ્રાઉઝર સપોર્ટ અને ફોલબેક્સ (fallbacks)
Web Locks API એક પ્રમાણમાં નવું ફીચર છે. આધુનિક Chromium-આધારિત બ્રાઉઝર્સ અને Firefox ના તાજેતરના વર્ઝન તેને લાગુ કરે છે, પરંતુ જૂના બ્રાઉઝર્સ અને Safari માં નેટિવ સપોર્ટનો અભાવ છે. જે વાતાવરણમાં API ઉપલબ્ધ નથી, ત્યાં ડેવલપર્સે ક્રોસ-ટેબ સિગ્નલિંગ મેળવવા માટે ઓછી વિશ્વસનીય તકનીકનો ઉપયોગ કરવો પડે છે—જેમ કે localStorage દ્વારા કસ્ટમ ઇવેન્ટ બ્રોડકાસ્ટ કરવી અથવા shared worker નો ઉપયોગ કરવો. આ ઉપાયોમાં navigator.locks જેવી આપમેળે ડેડ-લોક સુરક્ષા હોતી નથી, તેથી તેનો ઉપયોગ સાવચેતીપૂર્વક કરવો જોઈએ.
આગળ શું જોવું
- Standardisation progress – Keep an eye on the API’s adoption curve; broader support will make the lock-based approach the default for any cross-tab coordination.
- Library wrappers – A few open-source utilities are already abstracting the lock request pattern, making it easier to plug into existing Axios interceptors.
- Security audits – While the lock solves the concurrency issue, the refresh endpoint must still enforce proper token rotation and rate limiting, as a single malicious tab could still flood the server with requests if the lock is bypassed.
The takeaway is simple: treat a set of open tabs as a distributed system and give them a native synchronization primitive. By wiring the Web Locks API into the token-refresh flow, developers eliminate the “browser tab token trap” and keep users logged in, no matter how many tabs they juggle.