AI-ஆல் கட்டப்பட்ட ஆப்களுக்கான பாதுகாப்புச் சரிபார்ப்புப் பட்டியல்: வெளியிடுவதற்கு முன் என்ன பரிசோதிக்க வேண்டும்

உண்மையான மக்கள் AI-ஆல் நீங்கள் கட்டிய ஆப்பைப் பயன்படுத்தும் முன், ஏழு விஷயங்களைச் சரிபாருங்கள்: ஒவ்வொரு பக்கமும் API-உம் பயனர் யார், அவர் என்ன செய்யலாம் என்பதைச் சரிபார்க்கின்றனவா; ரகசிய keys சர்வரில் மட்டும் இருக்கின்றனவா, உலாவியிலோ அரட்டையிலோ அல்ல; எல்லா உள்ளீடுகளும் சர்வரில் சரிபார்க்கப்படுகின்றனவா; ஒவ்வொரு பயனரும் தனது சொந்தப் பதிவுகளை மட்டுமே அணுக முடிகிறதா; உள்நுழைவு மற்றும் செலவு பிடிக்கும் endpoints-க்கு rate limits உள்ளனவா; dependencies புதுப்பிக்கப்பட்டுள்ளனவா; ஏதாவது தவறினால் உங்கள் தரவை மீட்டெடுக்க முடியுமா. கீழே உள்ள பட்டியல் ஒவ்வொன்றையும் குறியீட்டைப் படிக்காமலே செய்யக்கூடிய குறிப்பிட்ட சோதனைகளாக மாற்றுகிறது.

AI ஆப் உருவாக்கிகள் விஷயங்களை வேலை செய்ய வைப்பதில் சிறந்தவை. அவை தானாகவே கவனமானவை அல்ல, ஏனென்றால் “கவனம்” என்பது அரிதாகவே prompt-இல் இருக்கும். கீழே உள்ள பெரும்பாலான சிக்கல்கள் யாரும் கேட்காத விஷயங்களிலிருந்து வருகின்றன, எனவே பொதுவாக தீர்வு கேட்பதுதான்.

இந்தப் பட்டியலை எப்படிப் பயன்படுத்துவது

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

• Must — யாரும் ஆப்பைப் பயன்படுத்துவதற்கு முன் இதைச் செய்யுங்கள்.
• Should — உண்மையான பயனர்களோ உண்மையான தரவோ வருவதற்கு முன் இதைச் செய்யுங்கள்.
• Later — ஆப் வளரும்போது செய்வது மதிப்புள்ளது.

உங்களுக்கு ஒரு மணி நேரம் மட்டுமே இருந்தால், எல்லா Must உருப்படிகளையும் செய்யுங்கள்.

1. அங்கீகாரம்: இது யார்?

அங்கீகாரம் ஒருவர் யார் என்பதை உறுதிப்படுத்துவது — பொதுவாக உள்நுழைவு. அடிப்படைகளுக்கு அங்கீகாரம் என்றால் என்ன பாருங்கள், விருப்பங்களுக்கு உங்கள் ஆப்புக்கு உள்நுழைவை எப்படிச் சேர்ப்பது பாருங்கள்.

• Must: தனிப்பட்ட தரவைக் காட்டும் ஒவ்வொரு பக்கத்துக்கும் உள்நுழைவு தேவை. சோதனை: வெளியேறிவிட்டு, தனிப்பட்ட பக்கத்தின் URL-ஐ நேரடியாக உலாவியில் ஒட்டுங்கள்.
• Must: அந்தப் பக்கங்களுக்குப் பின்னால் உள்ள ஒவ்வொரு API endpoint-க்கும் உள்நுழைவு தேவை — பக்கத்துக்கு மட்டும் அல்ல. சோதனை: வெளியேறிவிட்டு, உலாவியின் network tab-ஐத் திறந்து, நீங்கள் உள்நுழைந்திருந்தபோது ஆப் செய்த ஒரு கோரிக்கையை மீண்டும் முயலுங்கள்.
• Must: கடவுச்சொற்கள் மெதுவான password-hashing algorithm மூலம் hash செய்யப்பட்டு சேமிக்கப்படுகின்றன, எளிய உரையில் ஒருபோதும் இல்லை. OWASP-இன் கடவுச்சொல் சேமிப்பு வழிகாட்டுதல் முதலில் Argon2id-ஐ பரிந்துரைக்கிறது, மாற்றுகளாக scrypt, bcrypt அல்லது PBKDF2. கேளுங்கள்: “கடவுச்சொற்கள் எப்படிச் சேமிக்கப்படுகின்றன?”
• Should: கடவுச்சொல் மீட்டமைப்பு இணைப்புகள் காலாவதியாகின்றன, ஒருமுறை மட்டுமே வேலை செய்கின்றன.
• Should: Session cookies Secure, HttpOnly மற்றும் SameSite எனக் குறிக்கப்பட்டுள்ளன, வெளியேறுவது சர்வரில் session-ஐ முடிக்கிறது.
• Later: இரண்டு-காரணி அங்கீகாரத்தை வழங்குங்கள், அல்லது அதை வைத்திருக்கும் வழங்குநர் மூலம் உள்நுழைவை அனுமதியுங்கள்.

பயனர் தரவைத் திருப்பித் தரும் ஒவ்வொரு API route மற்றும் பக்கத்தையும் சரிபாருங்கள். ஒவ்வொன்றும் உள்நுழையாத பயனர்களின் கோரிக்கைகளை நிராகரிக்க வேண்டும், பக்கத்தின் கோடில் மட்டும் அல்ல, சர்வரில். நீங்கள் சரிபார்த்த routes-ஐப் பட்டியலிடுங்கள்.

2. அங்கீகாரம் (authorization): அவர்கள் என்ன செய்ய அனுமதிக்கப்பட்டவர்கள்?

Authorization என்பது உள்நுழைவுக்குப் பின் வரும் படி: இந்தக் குறிப்பிட்ட பயனர் எதைப் பார்க்கலாம், எதை மாற்றலாம் என்று முடிவெடுப்பது. AI-ஆல் கட்டப்பட்ட ஆப்களில் பெரும்பாலும் கடுமையான ஓட்டைகள் இங்குதான் இருக்கின்றன, ஏனென்றால் ஆப் சரியாகத் தோன்றும் — ஒவ்வொரு பயனரின் dashboard-உம் அவரது தரவை மட்டுமே காட்டும் — ஆனால் நேரடியாகக் கேட்டால் சர்வர் எவருடைய தரவையும் மகிழ்ச்சியாகக் கொடுத்துவிடும்.

• Must: ஒவ்வொரு படிப்பும், புதுப்பிப்பும், நீக்கலும் அந்தப் பதிவு தற்போதைய பயனருக்கு (அல்லது அவரது குழுவுக்கு) சொந்தமானதா என்று சர்வரில் சரிபார்க்கிறது.
• Must: சோதியுங்கள்: இரண்டு கணக்குகளை உருவாக்குங்கள், A மற்றும் B. A-ஆக, A-இன் பதிவு ஒன்றைத் திறந்து URL-இலோ network கோரிக்கையிலோ உள்ள ID-ஐக் குறித்துக்கொள்ளுங்கள். B-ஆக உள்நுழைந்து அதே ID-ஐக் கேளுங்கள். B-க்கு A-இன் தரவு அல்ல, ஒரு பிழை கிடைக்க வேண்டும்.
• Must: நிர்வாகப் பக்கங்களும் நிர்வாக API endpoints-உம் பயனரின் பங்கை சர்வரில் சரிபார்க்கின்றன. நிர்வாக இணைப்பை மறைப்பது பாதுகாப்பு அல்ல.
• Must: பயனர்கள் கோரிக்கையைத் திருத்துவதன் மூலம் தங்கள் சொந்த role, விலை, இருப்பு அல்லது owner புலங்களை மாற்ற முடியாது. சோதனை: network tab-இல், சுயவிவர புதுப்பிப்பு என்ன அனுப்புகிறது என்று பாருங்கள். அதில் role அல்லது isAdmin போன்ற புலங்கள் இருந்தால், கிளையண்டிலிருந்து அவற்றைப் புறக்கணிக்குமாறு AI-இடம் கேளுங்கள்.
• Should: URL-களில் உள்ள IDs யூகிக்க கடினமாக இருக்கின்றன (1, 2, 3 அல்ல, சீரற்ற IDs). இது அனுமதிச் சோதனைகளுக்கு மாற்று அல்ல, ஆனால் ஒன்று விடுபடும்போது சேதத்தை வரம்புக்குள் வைக்கிறது.

பதிவைப் படிக்கும் அல்லது மாற்றும் ஒவ்வொரு endpoint-க்கும், உள்நுழைந்த பயனர் அதற்குச் சொந்தக்காரரா அல்லது அணுக அனுமதிக்கப்பட்டவரா என்பதை சர்வரில் சரிபாருங்கள். இல்லையெனில் 404 திருப்புங்கள். பின்னர் இரண்டு கணக்குகளுடன் இதை எப்படிச் சோதிப்பீர்கள் என்று எனக்குக் காட்டுங்கள்.

3. டேட்டாபேஸில் வரிசை-நிலை அணுகல்

“வரிசை-நிலை அணுகல்” என்றால் அட்டவணையின் ஒவ்வொரு வரியும் (ஒரு முன்பதிவு, ஒரு விலைப்பட்டியல்) அதைச் சேர்ந்த பயனர்களுக்கு மட்டுமே தெரியும். இதை நடைமுறைப்படுத்த இரண்டு பொதுவான வழிகள் உள்ளன:

இரண்டையும் நன்றாகச் செய்யலாம். முக்கியமானவை:

• Must: உலாவி நேரடியாக டேட்டாபேஸுடன் பேசினால் (சில hosted டேட்டாபேஸ் தயாரிப்புகள் இதை அனுமதிக்கின்றன), ஒவ்வொரு அட்டவணைக்கும் row-level விதிகள் இயக்கப்பட்டிருக்க வேண்டும். இல்லையெனில் பொது key உள்ள எவரும் முழு அட்டவணையையும் படிக்கலாம்.
• Must: வினவல்கள் உலாவி அனுப்பும் ID-ஆல் அல்ல, தற்போதைய பயனர் அல்லது குழுவால் வடிகட்டப்படுகின்றன.
• Should: பகிரப்பட்ட தரவுக்கு (ஒரு குழுவின் திட்டங்கள்) யார் குழுவில் இருக்கிறார்கள் என்பதற்கு ஒரே இடத்தில் நடைமுறைப்படுத்தப்படும் தெளிவான விதி உள்ளது.

4. ரகசியங்களும் API keys-உம்

API key என்பது ஒரு சேவைக்கான கடவுச்சொல். Stripe, மின்னஞ்சல் மற்றும் AI வழங்குநர்கள் அனைவரும் இவற்றைப் பயன்படுத்துகிறார்கள். பின்னணிக்கு, சூழல் மாறிகள் மற்றும் secrets என்றால் என்ன பாருங்கள்.

• Must: Keys திட்டத்தின் சூழல் மாறிகள் அல்லது secrets-இல் சேமிக்கப்படுகின்றன, கோடில் ஒருபோதும் எழுதப்படுவதில்லை.
• Must: பணம் செலவழிக்கக்கூடிய அல்லது தனிப்பட்ட தரவைப் படிக்கக்கூடிய keys சர்வரில் மட்டுமே பயன்படுத்தப்படுகின்றன. சோதனை: உங்கள் நேரடி தளத்தின் மூலத்தைப் பாருங்கள், devtools-இல் JavaScript கோப்புகளைப் பாருங்கள், உங்கள் key-இன் ஆரம்பத்தை (எ.கா. sk_) தேடுங்கள். அது இருக்கக்கூடாது.
• Must: Keys ஒருபோதும் அரட்டையிலோ, பொது repository-யிலோ, screenshot-இலோ ஒட்டப்படவில்லை. ஒட்டப்பட்டிருந்தால், வழங்குநரிடம் அதைச் சுழற்றுங்கள் (புதியது உருவாக்குங்கள், பழையதை நீக்குங்கள்).
• Should: வழங்குநர் அனுமதித்தால் கட்டுப்படுத்தப்பட்ட அல்லது scoped keys-ஐப் பயன்படுத்துங்கள். எடுத்துக்காட்டாக, Stripe உங்கள் integration-க்குத் தேவையான அனுமதிகள் மட்டும் கொண்ட restricted keys-ஐப் பரிந்துரைக்கிறது.
• Should: சோதனை மற்றும் நேரடி keys தனித்தனியானவை, நீங்கள் தயாராகும் வரை நேரடி ஆப் நேரடி keys-ஐப் பயன்படுத்துவதில்லை.

சில keys பொதுவில் பயன்படுத்தும் வகையில் வடிவமைக்கப்பட்டவை — Stripe-இன் publishable key (pk_…) அல்லது உங்கள் டொமைனுக்கு மட்டும் கட்டுப்படுத்தப்பட்ட maps key. விதி அதிகாரம் தரும் keys பற்றியது, key போலத் தோன்றும் ஒவ்வொரு சரத்தைப் பற்றியதல்ல.

5. உள்ளீடு சரிபார்ப்பு

பயனர் அனுப்பும் எதுவும் — படிவப் புலங்கள், கோப்பு பதிவேற்றங்கள், URL அளவுருக்கள் — உங்கள் படிவம் அனுமதிப்பதற்கு மட்டும் அல்லாமல் எதுவாகவும் இருக்கலாம்.

• Must: சரிபார்ப்பு உலாவியில் மட்டும் அல்ல, சர்வரில் நடக்கிறது. உலாவிச் சரிபார்ப்புகள் வசதிக்காக; எவரும் அவற்றைத் தவிர்க்கலாம்.
• Must: டேட்டாபேஸ் வினவல்கள் parameters-ஐப் பயன்படுத்துகின்றன, பயனர் உள்ளீட்டிலிருந்து ஒட்டப்பட்ட உரையை அல்ல (இது SQL injection-ஐத் தடுக்கிறது). AI-இடம் இதை உறுதிப்படுத்தக் கேளுங்கள்.
• Must: பயனர்கள் உள்ளிடும் உரை உரையாகக் காட்டப்படுகிறது, HTML ஆக இயக்கப்படுவதில்லை. சோதனை: உங்கள் பெயராக <b>hello</b> உள்ளிடுங்கள். நீங்கள் குறிச்சொற்களைப் பார்க்க வேண்டும், தடிமனான உரையை அல்ல.
• Should: கோப்பு பதிவேற்றங்கள் வகை மற்றும் அளவைச் சரிபார்க்கின்றன, பதிவேற்றப்பட்ட கோப்புகள் உங்கள் ஆப்பின் முதன்மை டொமைனிலிருந்து இயக்கக்கூடிய பக்கங்களாக வழங்கப்படுவதில்லை.
• Should: பயனர்களுக்குக் காட்டப்படும் பிழைகள் எளிமையானவை (“ஏதோ தவறு நடந்தது”); விரிவான பிழைகள் சர்வர் logs-க்கு மட்டும் செல்கின்றன.
• Should: Stripe போன்ற சேவைகளிலிருந்து வரும் webhooks, செயல்படுவதற்கு முன் வழங்குநரின் கையொப்பத்தைச் சரிபார்க்கின்றன. webhook என்றால் என்ன பாருங்கள்.

ஒவ்வொரு படிவத்துக்கும் API endpoint-க்கும் சர்வர் பக்க சரிபார்ப்பைச் சேர்க்கவும்: தேவையான புலங்கள், நீளங்கள், வடிவங்கள் மற்றும் அனுமதிக்கப்பட்ட மதிப்புகள். மற்றவற்றைத் தெளிவான செய்தியுடன் நிராகரிக்கவும். உள் பிழை விவரங்களைப் பயனர்களுக்குக் காட்ட வேண்டாம்.

6. Rate limits மற்றும் துஷ்பிரயோகம்

Rate limit ஒரு காலகட்டத்தில் ஒருவர் எத்தனை கோரிக்கைகள் செய்யலாம் என்பதை வரம்பிடுகிறது. அது இல்லையெனில், எவரும் நாள் முழுவதும் கடவுச்சொற்களை யூகிக்கலாம், உங்கள் பதிவு படிவத்தை நிரப்பலாம், அல்லது கட்டண API-இல் உங்கள் பில்லை உயர்த்தலாம்.

• Must: உள்நுழைவு, பதிவு மற்றும் கடவுச்சொல் மீட்டமைப்பு ஒவ்வொரு IP முகவரிக்கும் மற்றும் ஒவ்வொரு கணக்குக்கும் rate-limit செய்யப்பட்டுள்ளன.
• Must: ஒவ்வொரு அழைப்புக்கும் உங்களுக்குச் செலவாகும் எதுவும் — AI மாதிரி கோரிக்கைகள், SMS, மின்னஞ்சல் — ஒரு பயனருக்கு ஒரு வரம்பு கொண்டுள்ளது மற்றும் உள்நுழைவு தேவை.
• Should: பொது படிவங்கள் (தொடர்பு, காத்திருப்புப் பட்டியல்) spam பாதுகாப்பு கொண்டுள்ளன: rate limit, மறைந்த honeypot புலம், அல்லது CAPTCHA.
• Should: பணம் பெறும் வழங்குநர்களில் செலவு வரம்புகள் அல்லது எச்சரிக்கைகளை அமைக்கவும், ஒரு பிழை அல்லது தாக்குபவர் வரம்பற்ற பில்லை உருவாக்க முடியாதபடி.

7. Dependencies

ஆப்கள் திறந்த மூல packages-இலிருந்து கட்டப்படுகின்றன, packages சில நேரங்களில் அறியப்பட்ட பாதிப்புகளைக் கொண்டிருக்கும்.

• Should: அறியப்பட்ட பாதிப்புகளைச் சரிபார்க்க AI-இடம் கேளுங்கள் (JavaScript திட்டங்களுக்கு, npm audit அல்லது உங்கள் package manager-இன் சமமானது) மற்றும் பாதிக்கப்பட்டவற்றைப் புதுப்பியுங்கள்.
• Should: ஆப் இனி பயன்படுத்தாத packages-ஐ நீக்குங்கள்.
• Should: மிகக் குறைந்த பயனர்கள் உள்ள packages, அல்லது பிரபலமானவற்றின் எழுத்துப்பிழைகள் போலத் தோன்றும் பெயர்கள் பற்றி கவனமாக இருங்கள்.
• Later: ஒன்றிரண்டு மாதங்களுக்கு ஒருமுறை மீண்டும் சரிபாருங்கள், அல்லது உங்கள் கோடு GitHub-இல் இருந்தால் தானியங்கி எச்சரிக்கைகளை இயக்குங்கள்.

8. Backups மற்றும் மீட்பு

பாதுகாப்பு என்பது உங்கள் தவறுகள், AI-இன் தவறுகள், அல்லது தாக்குபவரின் தவறுகளிலிருந்து மீளும் திறனையும் உள்ளடக்கும்.

• Must: உங்கள் தரவு எங்கே இருக்கிறது, அது backup செய்யப்படுகிறதா என்பது தெரிந்திருக்க வேண்டும். யூகிக்காதீர்கள்; உங்கள் hosting-இன் ஆவணங்களைப் பாருங்கள்.
• Should: முக்கியமான தரவின் உங்கள் சொந்த கால இடைவெளி ஏற்றுமதியை வைத்திருங்கள் (எ.கா. CSV ஏற்றுமதி அம்சம் அல்லது டேட்டாபேஸ் dump), தனியாக ஒரு இடத்தில் சேமித்து.
• Should: உங்கள் கோடை version control-இல் வைத்திருங்கள், எந்தப் பதிப்பையும் மீட்டெடுக்க முடியும்.
• Should: அழிக்கும் செயல்கள் (கணக்கை நீக்குதல், திட்டத்தை நீக்குதல்) உறுதிப்படுத்தலைக் கேட்கின்றன, சில காலம் திரும்பப் பெறக்கூடிய “soft delete” பற்றி பரிசீலிக்கவும்.
• Later: மீட்டெடுப்பை ஒருமுறை உண்மையாகச் சோதியுங்கள். ஒருபோதும் மீட்டெடுக்கப்படாத backup ஒரு நம்பிக்கை, திட்டம் அல்ல.

9. வெளியிடுவதற்கு முன்

• Must: நேரடி தளம் எல்லா இடங்களிலும் HTTPS பயன்படுத்துகிறது.
• Must: மேம்பாட்டிலிருந்து மாதிரி தரவு, சோதனைக் கணக்குகள் மற்றும் debug பக்கங்கள் நீக்கப்பட்டுள்ளன.
• Should: தனிப்பட்ட தரவைச் சேகரித்தால் எந்தத் தரவை ஏன் சேகரிக்கிறீர்கள் என்று தனியுரிமைக் கொள்கை சொல்கிறது — பல இடங்களில் இது தேவை. உங்களிடம் இல்லாத சான்றிதழ்களை (SOC 2, HIPAA) கூற வேண்டாம்.
• Should: பாதுகாப்புச் சிக்கல்கள் பற்றித் தொடர்பு கொள்ள ஒரு வழி உங்களுக்கு உள்ளது, ஒவ்வொரு key-யையும் விரைவாகச் சுழற்றுவது எப்படி என்று உங்களுக்குத் தெரியும்.

பாதுகாப்புக்கு அப்பாற்பட்ட பரந்த வெளியீட்டுக்கு முந்தைய சோதனைக்கு, AI முன்மாதிரியை உற்பத்திக்கு எப்படிக் கொண்டுசெல்வது பாருங்கள்.

தொழில்முறை மதிப்பாய்வு எப்போது தேவை

ஒரு சரிபார்ப்புப் பட்டியல் பொதுவான தவறுகளைப் பிடிக்கும்; அது ஒரு நிபுணருக்கு மாற்று அல்ல. நீங்கள் அட்டை எண்களை ஹோஸ்ட் செய்யப்பட்ட checkout வழியாக அல்லாமல் நேரடியாகக் கையாண்டால், மருத்துவம், நிதி அல்லது குழந்தைகளின் தரவை சேமித்தால், பாதுகாப்புக் கேள்விப்பட்டியல்களைக் கேட்கும் நிறுவனங்களுக்கு விற்றால், அல்லது கசிவால் கடுமையாகப் பாதிக்கப்படுவீர்கள் என்றால், மதிப்பாய்வுக்குப் பணம் செலவழிக்கப் பரிசீலிக்கவும். உங்கள் கோடை ஏற்றுமதி செய்யக்கூடியதாக வைத்திருப்பது அந்த மதிப்பாய்வை மிகவும் எளிதாக்குகிறது.

Mythex-இல் உருவாக்கும்போது பாதுகாப்பு

Mythex-இல் பாதுகாப்பு ஸ்கேன் பலகம் இல்லை, எனவே மேலே உள்ள பட்டியலே பின்பற்ற வேண்டிய நடைமுறை. உதவக்கூடிய சில விஷயங்கள்:

• திட்ட secrets. திட்ட அமைப்புகள் → Secrets-இன் கீழ், அல்லது ஏஜென்ட் அரட்டையில் காட்டும் secrets அட்டை மூலம் keys-ஐச் சேமியுங்கள், அவை உங்கள் கோடிலும் செய்திகளிலும் வராமல் இருக்கும். நேரடி ஆப்புக்கான secret-ஐ மாற்றிய பின் மீண்டும் வெளியிடுங்கள்.
• Plan மற்றும் Ask modes. திருத்தாமல் அனுமதிகளை மதிப்பாய்வு செய்யுமாறு ஏஜென்ட்டிடம் கேளுங்கள்: “Ask mode-இல், ஒவ்வொரு API route-ஐயும் அது என்ன அனுமதிச் சோதனை செய்கிறது என்று பட்டியலிடு.”
• /test ஏஜென்ட் உங்கள் முன்னோட்டத்தில் ஒரு பயனராகக் கிளிக் செய்து சோதிக்கும் — பிரிவு 2-இல் உள்ள இரண்டு-கணக்குச் சோதனைக்கு பயனுள்ளது.
• Checkpoints எதையாவது உடைத்த மாற்றத்தை திரும்பப் பெற அனுமதிக்கின்றன.

உருவாக்கிய ஆப்புகளுக்கான பாதுகாப்பு மற்றும் ஆவணங்களில் சூழல் மாறிகள் மற்றும் secrets பாருங்கள். அடுத்து பயனர் கணக்குகளைச் சேர்க்கிறீர்கள் என்றால், உங்கள் ஆப்புக்கு உள்நுழைவை எப்படிச் சேர்ப்பது படியுங்கள்.

கேள்விகள்