உங்கள் ஆப்பில் login சேர்ப்பது எப்படி: கடவுச்சொற்கள், magic links, Google மற்றும் roles

ஆப்பில் login சேர்க்க, ஒரு முறையைத் தேர்ந்தெடுங்கள் — email மற்றும் கடவுச்சொல், magic links (மின்னஞ்சலில் அனுப்பப்படும் ஒருமுறை sign-in இணைப்பு), அல்லது "Sign in with Google" — அதை முன்பே சோதிக்கப்பட்ட auth நூலகம் அல்லது hosted provider மூலம் செயல்படுத்துங்கள், பூஜ்யத்திலிருந்து எழுத வேண்டாம். பிறகு ஒவ்வொரு வகைப் பயனரும் என்ன செய்யலாம் என்று முடிவு செய்யுங்கள் (roles), அதை ஒவ்வொரு பக்கத்துக்கும் API request-க்கும் server-இல் அமல்படுத்துங்கள். Sessions பாதுகாப்பான cookies-ஐப் பயன்படுத்த வேண்டும், காலாவதியாக வேண்டும், logout-இல் சரியாக முடிய வேண்டும்.

இந்த வழிகாட்டி ஒவ்வொரு தேர்வையும், வேலை செய்யும் login-ஐ பாதுகாப்பானதிலிருந்து பிரிக்கும் விவரங்களையும் விளக்குகிறது. இதன் பின்னணிக் கருத்துகளுக்கு, authentication என்றால் என்ன பாருங்கள்.

முதலில் முடிவு செய்யுங்கள்: உங்களுக்கு login தேவையா?

Login தடையையும் பொறுப்பையும் கூட்டுகிறது. உங்களுக்கு அது தேவைப்படும்போது:

• பயனர்களுக்கு தனிப்பட்ட தரவு உள்ளது (அவர்களின் முன்பதிவுகள், ஆவணங்கள், விலைப்பட்டியல்கள்)
• பயனர்கள் மற்றவர்கள் பார்ப்பதை மாற்றலாம்
• அணுகலுக்கு கட்டணம் வசூலிக்கிறீர்கள்
• வெவ்வேறு நபர்களுக்கு வெவ்வேறு அனுமதிகள் தேவை (உரிமையாளர், ஊழியர், வாடிக்கையாளர்)

சந்தைப்படுத்தல் தளம், பொது அடைவு, அல்லது வெறுமனே உங்களுக்கு email அனுப்பும் படிவத்துக்கு நீங்கள் தேவைப்படாமல் இருக்கலாம். Waitlist-க்கு கணக்குகள் தேவையில்லை; email புலம் போதும்.

பொதுவான நான்கு login முறைகள்

பல ஆப்கள் இரண்டை இணைக்கின்றன: Google sign-in மற்றும் email magic links ஒரு பிரபலமான இணை, இது கடவுச்சொற்களை எதுவும் சேமிக்காமல் பெரும்பாலான மக்களை உள்ளடக்குகிறது.

Email மற்றும் கடவுச்சொல்

கடவுச்சொற்களை வழங்கினால், இவை தவிர்க்க முடியாதவை:

• கடவுச்சொற்களை மெதுவான கடவுச்சொல்-hash அல்காரிதம் மூலம் hash செய்யுங்கள். OWASP-இன் கடவுச்சொல் சேமிப்பு வழிகாட்டுதல் Argon2id-ஐப் பரிந்துரைக்கிறது, scrypt, bcrypt அல்லது PBKDF2 மாற்றுகளாக. கடவுச்சொற்களை ஒருபோதும் வெற்று உரையிலோ வேகமான பொது hash-இலோ சேமிக்காதீர்கள்.
• கடவுச்சொல் மீட்டமைப்பு ஒரு சீரற்ற, ஒருமுறை மட்டும் பயன்படும், காலாவதியாகும் இணைப்பைப் பயன்படுத்த வேண்டும், சரிபார்க்கப்பட்ட email-க்கு அனுப்பப்பட வேண்டும்.
• எந்த email-களுக்கு கணக்குகள் உள்ளன என்று வெளிப்படுத்தாதீர்கள். "இந்த email பதிவாகியிருந்தால், மீட்டமைப்பு இணைப்பு அனுப்பியுள்ளோம்" என்பது "கணக்கு கிடைக்கவில்லை" என்பதைவிடச் சிறந்தது.
• Login மற்றும் மீட்டமைப்பு முயற்சிகளுக்கு rate-limit வையுங்கள், கடவுச்சொல் ஊகிப்பதை மெதுவாக்க.
• நீண்ட கடவுச்சொற்களையும் கடவுச்சொல் நிர்வாகிகளையும் அனுமதியுங்கள்; விசித்திரமான எழுத்துக் கலவைகளைக் கட்டாயப்படுத்தும் விதிகளைத் தவிர்க்கவும்.

Magic links மற்றும் ஒருமுறைக் குறியீடுகள்

Magic link என்பது பயனருக்கு மின்னஞ்சலில் அனுப்பப்படும் sign-in இணைப்பு. அதைக் கிளிக் செய்தால் பயனர் உள்நுழைவார். ஒருமுறைக் குறியீடு அதே யோசனை; கிளிக் செய்வதற்குப் பதிலாக தட்டச்சு செய்யப்படுவது.

• இணைப்புகளும் குறியீடுகளும் விரைவில் காலாவதியாகி ஒருமுறை மட்டுமே வேலை செய்ய வேண்டும்.
• இணைப்பு கிளிக் செய்யப்பட்ட சாதனத்தில் பயனரை உள்நுழைவிக்க வேண்டும், மேலும் token பதிவுகளிலோ analytics கருவிகளிலோ இருக்கக்கூடாது.
• நம்பகமான email அனுப்புதல் தேவை — உங்கள் ஆப்பிலிருந்து மின்னஞ்சல் அனுப்புவது எப்படி பாருங்கள். Gmail மற்றும் Outlook-இல் சோதியுங்கள், spam கோப்புறையையும் பாருங்கள்.

Google உடன் Sign in (மற்றும் பிற OAuth providers)

"Sign in with Google" OAuth மற்றும் OpenID Connect-ஐப் பயன்படுத்துகிறது: பயனர் யார் என்று Google உறுதிப்படுத்தி, அவர்களின் email மற்றும் பெயரை உங்கள் ஆப்புக்குச் சொல்கிறது. செப்டம்பர் 2026 நிலவரப்படி அமைப்பு Google Cloud Console-இல் Google Auth Platform பகுதியில் நடக்கிறது:

1. ஒரு project-ஐ உருவாக்கவும் அல்லது தேர்ந்தெடுக்கவும், Branding பக்கத்தை நிரப்பவும் — consent screen-இல் பயனர்கள் பார்ப்பது (ஆப் பெயர், ஆதரவு email, logo).
2. Clients பக்கத்தில், "Web application" வகையில் ஒரு client உருவாக்கவும்.
3. உங்கள் authorized JavaScript origins மற்றும் redirect URIs சேர்க்கவும் — உங்கள் ஆப் இயங்கும் சரியான முகவரிகள், sign-in-க்குப் பிறகு Google பயனர்களை திருப்பி அனுப்பும் முகவரிகள்.
4. Client ID மற்றும் client secret-ஐ உங்கள் ஆப்பின் secrets-இல் சேமியுங்கள்.

Google-இன் OAuth ஆவணங்களின்படி பொதுவாகத் தவறும் விஷயங்கள்:

• redirect_uri_mismatch: redirect முகவரி சரியாகப் பொருந்த வேண்டும், http மற்றும் https, பெரிய-சிறிய எழுத்துகள் மற்றும் இறுதி slash உட்பட. உங்கள் preview முகவரிக்கு ஒன்றும், நேரடி domain-க்கு ஒன்றும் சேர்க்கவும்.
• HTTPS தேவை: redirect URIs HTTPS-ஐப் பயன்படுத்த வேண்டும், மேம்பாட்டின்போது localhost தவிர.
• state அளவுருவை திரும்பும்போது சரிபார்க்க வேண்டும், cross-site request forgery-இலிருந்து பாதுகாக்க. நல்ல நூலகங்கள் இதை உங்களுக்காகச் செய்கின்றன.

அடிப்படை sign-in தகவல் (பெயர், email, சுயவிவரம்) மட்டுமே கேட்டால், ஆப் சரிபார்ப்பு கட்டாயமில்லை என்று Google சொல்கிறது. பயனர்களின் Gmail, Drive அல்லது Calendar-க்கான அணுகலைக் கேட்பது வேறு; அதற்கு சரிபார்ப்பு தேவை.

நீங்களே உருவாக்குவதா அல்லது provider-ஐப் பயன்படுத்துவதா?

முதல் இரண்டும் நியாயமானவை. Hosted providers உங்களுக்கு அதிகம் கையாளுவார்கள், ஆனால் ஒரு சார்பை சேர்க்கிறார்கள், சில நேரங்களில் செயலில் உள்ள பயனர் ஒருவருக்கு கட்டணமும் உண்டு; தற்போதைய விலைகளை அவர்களின் தளங்களில் சரிபாருங்கள். நூலகங்கள் எல்லாவற்றையும் உங்கள் டேட்டாபேஸில் வைக்கின்றன, ஆனால் சரியாக அமைக்க அதிக பொறுப்பு உங்களுக்கு. எதைத் தேர்ந்தெடுத்தாலும், கடவுச்சொல் அல்லது session தர்க்கத்தை கையால் எழுதுவதற்குப் பதிலாக அதைப் பயன்படுத்தும்படி AI-இடம் கேளுங்கள்.

Roles மற்றும் அனுமதிகள்

Login ஒருவர் யார் என்று சொல்கிறது. அனுமதிகள் அவர்கள் என்ன செய்யலாம் என்று தீர்மானிக்கின்றன. ஆரம்பத்தில் எளிமையாக வையுங்கள்:

Role பெயர்களைவிட முக்கியமான விதிகள்:

• ஒவ்வொரு முறையும் server-இல் சரிபாருங்கள். பக்கத்தில் ஒரு பொத்தானை மறைப்பது, யாரும் நேரடியாக API-ஐ அழைப்பதைத் தடுக்காது.
• உரிமையாளரின் அடிப்படையில் வரம்பிடுங்கள். "முன்பதிவு 123"-ஐ ஒரு உறுப்பினர் கேட்டால், அது அவருடையதாக இருந்தால் மட்டுமே கொடுக்க வேண்டும்.
• பயனர்கள் தங்களைத் தாங்களே பதவி உயர்த்த முடியாது. சுயவிவர புதுப்பிப்புகளில் உலாவியிலிருந்து வரும் role புலங்களைப் புறக்கணியுங்கள்.
• இயல்பாக அணுகல் இல்லை. புதிய routes உங்கள் முடிவு வேறாக இல்லாதவரை login தேவைப்பட வேண்டும்.

இரண்டு accounts-உடன் சோதியுங்கள்: ஒருவராக உள்நுழைந்து, ஒரு பதிவின் ID-ஐக் கவனியுங்கள், பின்னர் மற்றவராக உள்நுழைந்து அதைத் திறக்க முயலுங்கள். முழு சோதனைக்கு எங்கள் பாதுகாப்புப் பட்டியல் பாருங்கள்.

Session பாதுகாப்பு

உள்நுழைந்த பிறகு, ஆப் பயனரை ஒரு session மூலம் நினைவில் வைத்திருக்கும் — பொதுவாக ஒரு cookie. OWASP-இன் session மேலாண்மை வழிகாட்டுதல் பரிந்துரைப்பது:

• Session cookies Secure (HTTPS மட்டும்), HttpOnly (பக்க scripts படிக்க முடியாதது) மற்றும் SameSite உடன் அமைக்கப்பட்டுள்ளன
• Login-இல் ஒரு புதிய session ID வழங்கப்படுகிறது, உரிமைகள் மாறும்போதும் மீண்டும்
• செயலற்ற நேர முடிவும், அதிகபட்ச ஆயுட்காலமும் உள்ளன, server-இல் அமல்படுத்தப்படுகின்றன
• Logout session-ஐ server-இல் முடிக்கிறது, வெறுமனே cookie-ஐ நீக்குவது மட்டும் அல்ல
• பயனர் கடவுச்சொல்லை மாற்றும்போது sessions செல்லாததாக்கப்படுகின்றன

Login tokens-ஐ உலாவியின் local storage-இல் சேமிப்பது tutorials-இல் பொதுவானது, ஆனால் பக்கத்தில் இயங்கும் எந்த script-க்கும் அவற்றை வெளிப்படுத்துகிறது; வலை ஆப்களுக்கு பாதுகாப்பான cookies பொதுவாக சிறந்த இயல்புநிலை.

எல்லாவற்றையும் உள்ளடக்கும் ஒரு prompt

இந்த ஆப்புக்கு பயனர் கணக்குகளைச் சேர்க்கவும். பயனர்கள் email மற்றும் கடவுச்சொல் மூலம் அல்லது Google மூலம் பதிவு செய்து உள்நுழையலாம். Custom auth code-க்குப் பதிலாக [நூலகம் அல்லது provider] பயன்படுத்தவும். கடவுச்சொற்களை Argon2id அல்லது bcrypt மூலம் hash செய்யவும். ஒரு மணி நேரத்தில் காலாவதியாகும், ஒருமுறை மட்டும் பயன்படும் இணைப்புடன் email மூலம் கடவுச்சொல் மீட்டமைப்பைச் சேர்க்கவும். Sessions-ஐ பாதுகாப்பான, HttpOnly cookies-இல் வையுங்கள். /dashboard மற்றும் ஒவ்வொரு /api route-ஐயும் உள்நுழைந்த பயனர்கள் மட்டுமே பயன்படுத்தும்படி பாதுகாக்கவும், மேலும் பயனர்கள் தங்கள் சொந்த projects-ஐ மட்டுமே பார்க்க முடியும் என்று உறுதி செய்யவும். எல்லாப் பயனர்களையும் பார்க்கக்கூடிய "admin" role சேர்க்கவும்; /admin-ஐ admins மட்டுமே அணுக வேண்டும், அதை server-இல் சரிபார்க்கவும்.

பிறகு சோதியுங்கள்: பதிவு செய்யுங்கள், logout செய்யுங்கள், login செய்யுங்கள், கடவுச்சொல்லை மீட்டமையுங்கள், logged out நிலையில் ஒரு தனிப்பட்ட URL-ஐ முயலுங்கள், மற்றொரு பயனரின் பதிவை முயலுங்கள்.

AI-உருவாக்கிய login-இல் பொதுவான தவறுகள்

• பக்கத்தில் மட்டும் பாதுகாப்பு. பக்கம் logged-out பயனர்களை redirect செய்கிறது, ஆனால் API எவருக்கும் தரவைத் திருப்பித் தருகிறது.
• ரகசியங்கள் browser-இல். OAuth client secrets மற்றும் auth provider admin keys server-இல் இருக்க வேண்டும்.
• Preview மற்றும் நேரடி URLs குழம்புவது. Google-இன் redirect URI அல்லது மீட்டமைப்பு email இணைப்பு preview-ஐ சுட்டுகிறது, அதனால் வெளியிட்ட பிறகு login உடைகிறது.
• Email சரிபார்ப்பு இல்லாமை. யார் வேண்டுமானாலும் anyone@company.com ஆக பதிவு செய்யலாம். அந்த முகவரியுடன் இணைக்கப்பட்ட எதையும் வழங்கும் முன் email-ஐச் சரிபாருங்கள்.
• சரியான பாதையை மட்டும் சோதிப்பது. தவறான கடவுச்சொற்கள், காலாவதியான இணைப்புகள், இரண்டாவது account ஆகியவற்றை முயலுங்கள்.

Mythex-இல் login சேர்ப்பது

Mythex-இல், உங்கள் ஆப்பின் பயனர்களுக்கான login என்பது நீங்கள் உங்கள் ஆப்பில் சேர்ப்பது — அது உங்கள் சொந்த Mythex கணக்கிலிருந்து தனியானது. Mythex ஒரு உள்ளமைந்த auth தயாரிப்பை வழங்குவதில்லை; அதனால் auth நூலகம் அல்லது provider-ஐயும் அதன் keys-ஐயும் நீங்களே கொண்டு வருகிறீர்கள்:

1. ஒரு அணுகுமுறையைத் தேர்ந்தெடுங்கள் — எடுத்துக்காட்டாக உங்கள் சொந்த டேட்டாபேஸில் சேமிக்கப்படும் email மற்றும் கடவுச்சொல், அல்லது hosted provider-இன் SDK.
2. பயனர்களை நீங்களே சேமித்தால், ஆப்புக்கு டேட்டாபேஸ் தேவை; chat-இல் கேளுங்கள் அல்லது /database பயன்படுத்துங்கள்.
3. Provider keys-ஐ project secrets-இல் (/secrets அல்லது project settings) வையுங்கள்.
4. மேலே உள்ள போன்ற prompt-ஐப் பயன்படுத்துங்கள், பிறகு Preview-இல் சோதியுங்கள். Google sign-in-க்கு, உங்கள் preview மற்றும் வெளியிட்ட முகவரி இரண்டுக்கும் redirect URIs சேர்க்கவும்.

ஆவணங்களில் ஆப்பில் login சேர்ப்பது பாருங்கள். பணம் பெறும் தயாரிப்பை உருவாக்குகிறீர்கள் என்றால், SaaS MVP எப்படி உருவாக்குவது கணக்குகளையும் கட்டணத்தையும் ஒன்றாக விளக்குகிறது.

கேள்விகள்