તમારી એપમાં લોગિન કેવી રીતે ઉમેરવું: પાસવર્ડ, મેજિક લિંક, Google અને રોલ

એપમાં લોગિન ઉમેરવા માટે, એક પદ્ધતિ પસંદ કરો — ઈમેલ અને પાસવર્ડ, મેજિક લિંક (ઈમેલથી મોકલાતી એક વખતની સાઇન-ઇન લિંક), અથવા "Google સાથે સાઇન ઇન" — અને તેને શરૂઆતથી લખવાને બદલે સાબિત થયેલી ઓથ લાઇબ્રેરી કે હોસ્ટેડ પ્રોવાઇડર વડે અમલમાં મૂકો. પછી નક્કી કરો કે દરેક પ્રકારનો વપરાશકર્તા શું કરી શકે (રોલ), અને દરેક પેજ તથા API રિક્વેસ્ટ પર તે સર્વર પર લાગુ કરો. સેશન સુરક્ષિત કુકીઝ વાપરે, સમાપ્ત થાય, અને લોગઆઉટ પર યોગ્ય રીતે બંધ થાય.

આ ગાઇડ દરેક પસંદગી અને કામ કરતા લોગિન અને સુરક્ષિત લોગિન વચ્ચે તફાવત પાડતી વિગતોમાંથી પસાર થાય છે. તેની પાછળના ખ્યાલો માટે, ઓથેન્ટિકેશન શું છે જુઓ.

પહેલા નક્કી કરો: શું તમને લોગિનની જરૂર છે?

લોગિન અડચણ અને જવાબદારી ઉમેરે છે. તમને તેની જરૂર ત્યારે પડે છે જ્યારે:

• વપરાશકર્તાઓનો ખાનગી ડેટા હોય (તેમના બુકિંગ, ડોક્યુમેન્ટ, ઇન્વૉઇસ)
• વપરાશકર્તાઓ એવી વસ્તુ બદલી શકે જે બીજા જોશે
• તમે ઍક્સેસ માટે ચાર્જ કરો
• અલગ લોકોને અલગ પરવાનગી જોઈએ (માલિક વિરુદ્ધ સ્ટાફ વિરુદ્ધ ગ્રાહક)

માર્કેટિંગ સાઇટ, જાહેર ડિરેક્ટરી, કે ફક્ત તમને ઈમેલ મોકલતા ફોર્મ માટે તમને કદાચ જરૂર નથી. વેઇટલિસ્ટને એકાઉન્ટની જરૂર નથી; ઈમેલ ફીલ્ડ પૂરતું છે.

ચાર સામાન્ય લોગિન પદ્ધતિઓ

ઘણી એપ બે ભેગી કરે છે: Google સાઇન-ઇન અને ઈમેલ મેજિક લિંક એક લોકપ્રિય જોડી છે, જે કોઈ પાસવર્ડ સંગ્રહ્યા વગર મોટાભાગના લોકોને આવરી લે છે.

ઈમેલ અને પાસવર્ડ

જો તમે પાસવર્ડ આપો, તો આ બિન-વાટાઘાટ યોગ્ય છે:

• ધીમા પાસવર્ડ-હેશિંગ અલ્ગોરિધમ વડે પાસવર્ડ હેશ કરો. OWASP ની પાસવર્ડ સંગ્રહ માર્ગદર્શિકા Argon2id ની ભલામણ કરે છે, વૈકલ્પિક તરીકે scrypt, bcrypt અથવા PBKDF2. ક્યારેય સાદા લખાણમાં કે ઝડપી સામાન્ય હેશમાં પાસવર્ડ સંગ્રહો નહીં.
• પાસવર્ડ રીસેટ એક રેન્ડમ, એક વખત વપરાતી, એક્સપાયર થતી લિંક વાપરે, ચકાસાયેલા ઈમેલ પર મોકલાય.
• કયા ઈમેલનું એકાઉન્ટ છે તે જાહેર ન કરો. "જો એ ઈમેલ નોંધાયેલો હોય, તો અમે રીસેટ લિંક મોકલી છે" એ "કોઈ એકાઉન્ટ મળ્યું નથી" કરતાં સારું છે.
• લોગિન અને રીસેટ પ્રયાસો પર રેટ-લિમિટ લગાવો, જેથી પાસવર્ડ અનુમાન ધીમું પડે.
• લાંબા પાસવર્ડ અને પાસવર્ડ મેનેજરને મંજૂરી આપો; વિચિત્ર અક્ષર મિશ્રણ ફરજિયાત કરતા નિયમો છોડી દો.

મેજિક લિંક અને એક વખતના કોડ

મેજિક લિંક એ વપરાશકર્તાને ઈમેલ કરાયેલી સાઇન-ઇન લિંક છે. તેના પર ક્લિક કરતા તેઓ લોગ ઇન થાય છે. એક વખતનો કોડ એ જ વિચાર છે, ક્લિકને બદલે ટાઇપ કરીને.

• લિંક અને કોડ ઝડપથી એક્સપાયર થાય અને ફક્ત એક જ વાર કામ કરે.
• લિંક જે ઉપકરણ પર ક્લિક થઈ ત્યાં વપરાશકર્તાને લોગ ઇન કરે, અને ટોકન લૉગ્સ કે એનાલિટિક્સ ટૂલમાં ન રહે.
• તમારે વિશ્વસનીય ઈમેલ મોકલવાની જરૂર છે — તમારી એપમાંથી ઈમેલ કેવી રીતે મોકલવા જુઓ. Gmail અને Outlook પર પરીક્ષણ કરો, અને સ્પેમ ફોલ્ડર તપાસો.

Google સાથે સાઇન ઇન (અને બીજા OAuth પ્રોવાઇડર)

"Google સાથે સાઇન ઇન" OAuth અને OpenID Connect વાપરે છે: Google પુષ્ટિ કરે છે કે વપરાશકર્તા કોણ છે અને તમારી એપને તેમનો ઈમેલ અને નામ જણાવે છે. સપ્ટેમ્બર 2026 મુજબ સેટઅપ Google Cloud Console ના Google Auth Platform વિભાગમાં થાય છે:

1. પ્રોજેક્ટ બનાવો કે પસંદ કરો, અને Branding પેજ ભરો — કન્સેન્ટ સ્ક્રીન પર વપરાશકર્તાઓ શું જુએ (એપનું નામ, સપોર્ટ ઈમેલ, લોગો).
2. Clients પેજ પર, "Web application" પ્રકારનો ક્લાયન્ટ બનાવો.
3. તમારા authorized JavaScript origins અને redirect URIs ઉમેરો — ચોક્કસ સરનામાં જ્યાં તમારી એપ ચાલે છે અને જ્યાં સાઇન-ઇન પછી Google વપરાશકર્તાઓને પાછા મોકલે છે.
4. ક્લાયન્ટ ID અને ક્લાયન્ટ સિક્રેટ તમારી એપના સિક્રેટમાં સંગ્રહો.

Google ના OAuth દસ્તાવેજ મુજબ સામાન્ય રીતે ખોટું થાય તેવી બાબતો:

• redirect_uri_mismatch: redirect સરનામું બરાબર મેળ ખાવું જોઈએ, જેમાં http વિરુદ્ધ https, મોટા-નાના અક્ષરો અને અંતે સ્લેશ શામેલ છે. તમારા પ્રીવ્યૂ સરનામા માટે એક અને લાઇવ ડોમેન માટે એક ઉમેરો.
• HTTPS જરૂરી: redirect URIs HTTPS વાપરવા જોઈએ, ડેવલપમેન્ટ દરમિયાન localhost સિવાય.
• state પેરામીટર પાછા આવતા ચકાસવું જોઈએ, જેથી ક્રોસ-સાઇટ રિક્વેસ્ટ ફોર્જરી સામે રક્ષણ મળે. સારી લાઇબ્રેરીઓ આ તમારા માટે કરે છે.

જો તમે ફક્ત મૂળભૂત સાઇન-ઇન માહિતી (નામ, ઈમેલ, પ્રોફાઇલ) માગો, તો Google કહે છે કે એપ વેરિફિકેશન ફરજિયાત નથી. વપરાશકર્તાઓના Gmail, Drive કે Calendar નો ઍક્સેસ માગવો અલગ છે અને તેના માટે વેરિફિકેશન જોઈએ.

જાતે બનાવવું કે પ્રોવાઇડર વાપરવો?

પહેલા બે બંને વાજબી છે. હોસ્ટેડ પ્રોવાઇડર તમારા માટે વધુ સંભાળે છે પણ એક નિર્ભરતા ઉમેરે છે અને ક્યારેક સક્રિય વપરાશકર્તા દીઠ ખર્ચ લાગે છે; વર્તમાન કિંમત તેમની સાઇટ પર તપાસો. લાઇબ્રેરીઓ બધું તમારા ડેટાબેઝમાં રાખે છે પણ સાચી રીતે ગોઠવવાનું વધુ તમારા પર છોડે છે. તમે જે પસંદ કરો, AI ને પાસવર્ડ કે સેશન લોજિક જાતે લખવાને બદલે તેનો ઉપયોગ કરવાનું કહો.

રોલ અને પરવાનગીઓ

લોગિન કહે છે કે કોઈ કોણ છે. પરવાનગીઓ નક્કી કરે છે કે તે શું કરી શકે. શરૂઆતમાં સરળ રાખો:

રોલના નામ કરતાં વધુ મહત્ત્વના નિયમો:

• દર વખતે સર્વર પર તપાસો. પેજમાં બટન છુપાવવાથી કોઈ સીધું API કૉલ કરતા રોકાતું નથી.
• માલિક દ્વારા સ્કોપ કરો. "બુકિંગ 123" મેળવતો સભ્ય તે ફક્ત ત્યારે મેળવે જો તે તેનું હોય.
• વપરાશકર્તાઓ પોતાને પ્રમોટ ન કરી શકે. પ્રોફાઇલ અપડેટ પર બ્રાઉઝરમાંથી મોકલાયેલા રોલ ફીલ્ડ અવગણો.
• ડિફોલ્ટ રીતે કોઈ ઍક્સેસ નહીં. નવા રૂટ માટે, તમે અન્યથા નક્કી ન કરો ત્યાં સુધી લોગિન જરૂરી હોવું જોઈએ.

બે એકાઉન્ટ વડે પરીક્ષણ કરો: એક તરીકે લોગ ઇન કરો, રેકોર્ડનો ID નોંધો, પછી બીજા તરીકે લોગ ઇન કરીને તેને ખોલવાનો પ્રયાસ કરો. પૂરું પરીક્ષણ અમારી સુરક્ષા ચેકલિસ્ટ માં છે.

સેશન સુરક્ષા

લોગિન પછી, એપ સેશન વડે વપરાશકર્તાને યાદ રાખે છે — સામાન્ય રીતે કુકી. OWASP ની સેશન મેનેજમેન્ટ માર્ગદર્શિકા ભલામણ કરે છે:

• સેશન કુકીઝ Secure (ફક્ત HTTPS), HttpOnly (પેજ સ્ક્રિપ્ટ વાંચી ન શકે) અને SameSite સાથે સેટ
• લોગિન પર નવો સેશન ID જારી, અને પરવાનગીઓ બદલાય ત્યારે ફરી
• નિષ્ક્રિયતા ટાઇમઆઉટ અને મહત્તમ આયુષ્ય, સર્વર પર લાગુ
• લોગઆઉટ સર્વર પર સેશન સમાપ્ત કરે, માત્ર કુકી ડિલીટ નહીં
• વપરાશકર્તા પાસવર્ડ બદલે ત્યારે સેશન રદ

ટ્યુટોરિયલમાં બ્રાઉઝરના લોકલ સ્ટોરેજમાં લોગિન ટોકન સંગ્રહવું સામાન્ય છે, પણ તે પેજ પર ચાલતી કોઈ પણ સ્ક્રિપ્ટને તેમને ખુલ્લા પાડે છે; વેબ એપ માટે સુરક્ષિત કુકીઝ સામાન્ય રીતે વધુ સારો ડિફોલ્ટ છે.

આવશ્યક બાબતો આવરી લેતો પ્રોમ્પ્ટ

આ એપમાં વપરાશકર્તા એકાઉન્ટ ઉમેરો. વપરાશકર્તાઓ ઈમેલ અને પાસવર્ડ અથવા Google વડે સાઇન અપ કરી લોગ ઇન કરી શકે. કસ્ટમ ઓથ કોડને બદલે [લાઇબ્રેરી કે પ્રોવાઇડર] વાપરો. પાસવર્ડ Argon2id અથવા bcrypt વડે હેશ કરો. ઈમેલ દ્વારા પાસવર્ડ રીસેટ ઉમેરો, એક કલાકમાં એક્સપાયર થતી એક વખતની લિંક સાથે. સેશન સુરક્ષિત, HttpOnly કુકીઝમાં રાખો. /dashboard અને દરેક /api રૂટ એવી રીતે સુરક્ષિત કરો કે ફક્ત લોગ ઇન વપરાશકર્તાઓ વાપરી શકે, અને ખાતરી કરો કે વપરાશકર્તાઓ ફક્ત પોતાના પ્રોજેક્ટ જોઈ શકે. "admin" રોલ ઉમેરો જે બધા વપરાશકર્તાઓ જોઈ શકે; ફક્ત એડમિન /admin સુધી પહોંચી શકે, જે સર્વર પર તપાસાય.

પછી પરીક્ષણ કરો: સાઇન અપ કરો, લોગઆઉટ કરો, લોગ ઇન કરો, પાસવર્ડ રીસેટ કરો, લોગ આઉટ હોય ત્યારે ખાનગી URL અજમાવો, અને બીજા વપરાશકર્તાનો રેકોર્ડ અજમાવો.

AI વડે બનેલા લોગિનમાં સામાન્ય ભૂલો

• સુરક્ષા ફક્ત પેજમાં. પેજ લોગ ન થયેલા વપરાશકર્તાઓને રીડાયરેક્ટ કરે, પણ API કોઈને પણ ડેટા આપી દે.
• બ્રાઉઝરમાં સિક્રેટ. OAuth ક્લાયન્ટ સિક્રેટ અને ઓથ પ્રોવાઇડર એડમિન કી સર્વર પર હોવા જોઈએ.
• પ્રીવ્યૂ અને લાઇવ URL ભેળસેળ. Google નું redirect URI કે રીસેટ ઈમેલની લિંક પ્રીવ્યૂ તરફ દોરે, એટલે પબ્લિશ પછી લોગિન તૂટે.
• ઈમેલ ચકાસણી નહીં. કોઈ પણ anyone@company.com તરીકે સાઇન અપ કરી શકે. તે સરનામા સાથે જોડાયેલું કંઈ પણ આપતા પહેલા ઈમેલ ચકાસો.
• ફક્ત સાચા માર્ગનું પરીક્ષણ. ખોટા પાસવર્ડ, એક્સપાયર થયેલી લિંક અને બીજા એકાઉન્ટ અજમાવો.

Mythex માં લોગિન ઉમેરવું

Mythex પર, તમારી એપના વપરાશકર્તાઓ માટે લોગિન એ તમે તમારી એપમાં ઉમેરો છો — તે તમારા પોતાના Mythex એકાઉન્ટથી અલગ છે. Mythex બિલ્ટ-ઇન ઓથ પ્રોડક્ટ આપતું નથી, એટલે તમે ઓથ લાઇબ્રેરી કે પ્રોવાઇડર અને તેની કી લાવો છો:

1. એક અભિગમ પસંદ કરો — ઉદાહરણ તરીકે તમારા પોતાના ડેટાબેઝમાં સંગ્રહાયેલા ઈમેલ અને પાસવર્ડ, અથવા હોસ્ટેડ પ્રોવાઇડરનો SDK.
2. જો તમે વપરાશકર્તાઓ જાતે સંગ્રહો, તો એપને ડેટાબેઝ જોઈએ; ચેટમાં માગો અથવા /database વાપરો.
3. પ્રોવાઇડર કી પ્રોજેક્ટ સિક્રેટમાં (/secrets અથવા પ્રોજેક્ટ સેટિંગ્સ) મૂકો.
4. ઉપરના જેવો પ્રોમ્પ્ટ વાપરો, પછી Preview માં પરીક્ષણ કરો. Google સાઇન-ઇન માટે, તમારા પ્રીવ્યૂ અને પબ્લિશ થયેલા સરનામાં બંને માટે redirect URIs ઉમેરો.

docs માં તમારી એપમાં લોગિન ઉમેરો જુઓ. જો તમે ચૂકવણીવાળી પ્રોડક્ટ બનાવો, તો SaaS MVP કેવી રીતે બનાવવો એકાઉન્ટ અને બિલિંગ બંને આવરી લે છે.

પ્રશ્નો