CMNexa

CMNexa CMNexa | Billing Systems • Websites • Social Media Management
Fast, modern & reliable solutions for growing businesses. DM for a free consultation.

26/08/2026

⏳ Button එක Click කළා… ඒත් App එක නිහඬයි. වැඩ කරනවද, කැඩිලාද User දන්නේ කොහොමද?

User Form එක fill කරලා Save click කරනවා.
තත්පරයක් යනවා…
Spinner එකක් නැහැ.
Message එකක් නැහැ.
Button එකේ වෙනසක් නැහැ.

User හිතනවා:
“මම Button එක click කළාද?”
ඊට පස්සේ ආයෙත් click කරනවා.
Result?

Duplicate Records.
Emails කිහිපයක්.
Order එක දෙවරක්.
Payment Request එකත් repeat වෙන්න පුළුවන්.
Problem එක Userගේ අතේ නෙවෙයි.
App එක communicate කළේ නැති එකේ.
Loading State කියන්නේ Decoration එකක් නෙවෙයි.
ඒ Userට කියන Message එකක්:
“ඔයාගේ Action එක ලැබුණා. මම වැඩ කරනවා. ටිකක් ඉන්න.”
Professional Save Button එක:
Save → Saving…
Spinner එකක් පෙන්වනවා.
Button එක temporarily disable කරනවා.
Success නම්:
✅ Saved Successfully
Fail නම්:
❌ Could not save. Please try again.
මේ small detail එකෙන් Duplicate Clicks, User Confusion සහ Data Problems අඩු වෙනවා.
Dashboard එකේ Blank Screen එකක් වෙනුවට Loading/Skeleton State එකක් දෙන්න.
File Upload එකක් නම් Progress එක පෙන්වන්න.
Invisible Work එක Visible කරන්න.
Professional Feature එකකට:
Default → Loading → Success → Error → Empty → Disabled
වගේ States ගැන හිතන්න ඕනේ.
Beginner කෙනෙක් කියනවා:
“Button එක වැඩ.”

Professional Developer කෙනෙක් අහනවා:
“Button එක වැඩ කරන අතර Userට මොනවද පේන්නේ?”
User click කරනකොට silent question එකක් අහනවා:
“දැන් මොකක්ද වෙන්නේ?”

Loading State එක ඒකට උත්තර දෙනවා.
අන්න ඒක Communication.
අන්න ඒක Trust.
අන්න ඒක Professional Software.
CMNexa - Learn. Debug. Build.

24/08/2026

🚨 App එක වැඩ කරනවා කියලා Feature එක Complete ද? ඇත්තම Quality එක පේන්නේ Error එකක් ආවමයි!

Form එක submit වෙනවා.
Login success.
Dashboard load වෙනවා.
Database එකට Record save වෙනවා.
Happy Path එකේ හැමදේම perfect.
Beginner Developer කෙනෙක් කියනවා:
“Feature එක complete!”
හැබැයි Real Software එක test වෙන්නේ හැමදේම හරියට යනකොට විතරක් නෙවෙයි.
Internet disconnect වුණොත්?
Token expire වුණොත්?
Wrong Data submit කළොත්?
API fail වුණොත්?
Save Button එක දෙවරක් click කළොත්?
Professional App එක Errors නැහැ කියලා pretend කරන්නේ නැහැ. Errors එනවා කියලා දැනගෙන කලින්ම සූදානම් වෙනවා.
Long Form එකක් fill කරලා Save කළාම:
“Email already exists.”
කියලා Error එකක් ආවා කියලා හිතන්න.
Weak App එක Form එක clear කරනවා.
Better App එක Userගේ Data preserve කරලා, Email field එක highlight කරලා clear message එකක් දෙනවා.
Good Error Handling කියන්නේ Error එක නැති කරන එක නෙවෙයි. Userව Recover කරන්න උදව් කරන එක.
Loading එකත් එහෙමයි.
Blank Screen එකක් වෙනුවට:
Loading feedback දෙන්න.
Button එක disable කරන්න.
Fail වුණොත් Retry option එකක් දෙන්න.
Raw TypeError, Stack Trace හෝ Database Error Userට පෙන්වන්න එපා.
Userට Clarity. Developerට Details.

400 → Validation
401 → Login / Token
403 → Permission
404 → Not Found
500 → Server Error

Professional Frontend එක Status Code එක Number එකක් විදිහට විතරක් බලන්නේ නැහැ.
UX Decision එකක් විදිහට use කරනවා.
Duplicate clicks prevent කරන්න.
User input preserve කරන්න.
Safe Error Messages දෙන්න.
Technical Details Logs වල තියාගන්න.
Sensitive Data expose කරන්න එපා.
Happy Path එකේ වැඩ කරන එක Functionality.
Failure Path එකේ හොඳින් හැසිරෙන එක Quality.
Professional App එක Error එකක් ආවම Userව, Data එක සහ System එක protect කරනවා.
Good Apps Errors hide කරන්නේ නැහැ. ඒවා handle කරනවා.
ඔයාගේ App එක Error එකක් ආවම තවමත් “Something went wrong” විතරද පේන්නේ? 😅👇
CMNexa - Learn. Debug. Build.

23/08/2026

🧭 App එක Fail වුණාම Screen එක කියන්නේ “Something Went Wrong” විතරයි… හැබැයි Logs කියන්නේ Full Story එක!

User Save Button එක click කරනවා.
Loading…

ඊට පස්සේ:
“Failed to save record.”
Userට කතාව එතනින් ඉවරයි.
හැබැයි Developer කෙනෙක්ට ප්‍රශ්න ගොඩක්:

Request එක Backend එකට ගියාද?
Validation fail ද?
Permission නැද්ද?
Database Error එකක්ද?
Screen එක පෙන්වන්නේ Final Result එක විතරයි.
Logs පෙන්වන්නේ ඒ Error එකට කලින් සිද්ධ වුණු Journey එක.
හොඳ Logs තිබුණොත්:

Student creation request received
Validation completed
Database save started
Database connection failed

දැන් clear.
Problem එක Button එකේ නෙවෙයි.
Form එකේත් නෙවෙයි.
Database Connection එකේ.
Logs නැත්නම් Guessing.
Logs තිබුණොත් Direction.
හැබැයි test, here, error වගේ Random Logs වැඩක් නැහැ.
Good Logs කියන්නේ Application එකේ Story එක:
Request → Validation → Permission → Database → Response
Production Bug එකකදී මේක තවත් වැදගත්.
User රෑ 11ට “App එක fail” කිව්වම ඔයා එතන හිටියේ නැහැ.
හැබැයි Logs වලින් Request Time, Route, Error Type සහ Failure Point හොයාගන්න පුළුවන්.
තවත් වැදගත් දෙයක්:

❌ Passwords
❌ JWT Tokens
❌ API Keys
❌ Database Secrets

Logs වලට දාන්න එපා.
Stack Trace එක Crash Location එක පෙන්වනවා.
Logs ඒ Crash එකට ගිය Journey එක පෙන්වනවා.
ඊළඟ වතාවේ App එක Fail වුණාම:

Network Tab බලන්න.
Status Code බලන්න.
Backend Logs follow කරන්න.
Stack Trace බලන්න.
Root Cause එක fix කරන්න.

Beginner කෙනෙක් Guess කරනවා.
Developer කෙනෙක් Evidence හොයනවා.
Logs කියන්නේ Messages විතරක් නෙවෙයි.
Application එක ගිය Path එකේ Breadcrumbs.

CMNexa - Learn. Debug. Build.

22/08/2026

🚨 Terminal එක රතු වුණාම Project එකම කැඩුණා කියලා හිතනවද?

Project එක හොඳට run වෙනවා.

Button එක click කරනවා.
Form එක submit කරනවා.
API එක call කරනවා.

හදිසියේම…

Screen එක freeze.
Terminal එක රතු.
File Names, Line Numbers, Function Names ගොඩක්.

Beginner Developer කෙනෙක්ට හිතෙන්නේ:

“මගේ මුළු Project එකම ඉවරයි!”

ඊට පස්සේ Google කරනවා. AI එකට Error එක paste කරනවා. Random Code Lines වෙනස් කරනවා.

හැබැයි වැදගත් Truth එක මෙන්න:

Stack Trace එක ඔයාව බය කරන්න ආපු දෙයක් නෙවෙයි.

ඒ Error එක පටන් ගත්තේ කොහෙන්ද කියලා පෙන්වන Map එකක්.

මුලින්ම බලන්න:

🔹 Error Message එක
🔹 File Name එක
🔹 Line Number එක
🔹 Function එක

උදාහරණයක්:

Cannot read properties of undefined
StudentList.jsx:35

දැන් whole project එක search කරන්න ඕනේ නැහැ.

Line 35ට ගිහින් බලන්න.

students.map(...)

දැන් questions clear:

students Array එකක්ද?
Data load වෙලාද?
API Response එක match වෙනවද?

Stack Trace එක Bug එක auto-fix කරන්නේ නැහැ.

හැබැයි Bug එක හොයන්න ඕනේ exact area එක පෙන්වනවා.

තව දෙයක්:

Error එක පේන තැන සහ Root Cause එක එකම තැන නොවෙන්න පුළුවන්.

UI එක user.name line එකේ crash වෙන්න පුළුවන්.

හැබැයි real problem එක API එක null return කරපු එක වෙන්න පුළුවන්.

Good Debugging කියන්නේ Error එක silence කරන එක නෙවෙයි. Root Cause එක තේරුම්ගන්න එක.

Network Tab → Request/Response
Status Code → Result
JSON → Data
Backend Logs → Server Story
Stack Trace → File + Line + Function

Beginner කෙනෙක් Error එක දැකලා panic වෙනවා.

Experienced Developer කෙනෙක් clues හොයනවා.

Great Developer කෙනෙක් කියන්නේ Errors නැති කෙනෙක් නෙවෙයි.

Errors කියවන්න දන්න කෙනෙක්.

ඊළඟ වතාවේ Terminal එක රතු වුණාම:

Message එක කියවන්න.
File එක හොයන්න.
Line Number එක බලන්න.
Actual Data එක inspect කරන්න.
Root Cause එක fix කරන්න.

Error එකෙන් දුවන්න එපා. ඒක පෙන්වන පාර follow කරන්න.

ඔයා Stack Trace එකේ Line Number එක බලන්නේ නැතුව Error එක Google කරලා තියෙනවද? 😅👇

CMNexa - Learn. Debug. Build.

21/08/2026

🔍 UI එක කියන්නේ “Something Went Wrong” විතරයි… හැබැයි ඇත්තටම වැරදුණේ මොකක්ද කියලා Network Tab එක දන්නවා!

Login Form එකක් build කළා.

Email සහ Password enter කරලා Login click කළා.

UI එකේ පේන්නේ:

“Something went wrong.”

එච්චරයි.

API එක fail ද? Password wrong ද? Token missing ද? Backend crash ද? CORS ද?

Beginner Developer කෙනෙක් Frontend restart කරනවා. Backend restart කරනවා. Variables වෙනස් කරනවා. අන්තිමට AI එකට full code එක දාලා:

“මේක fix කරන්න.”

විනාඩි 30කට පස්සේ Code එක වෙනස්කම් ගොඩකින් පිරිලා.

හැබැයි Original Problem එක තවම තියෙනවා.

ඇයි?

ඔයා Debug කරන්නේ Evidence එකෙන් නෙවෙයි. Guess කරලා.

Professional Developer කෙනෙක් Random Code Changes කරන්නේ නැහැ.

DevTools open කරලා Network Tab එක බලනවා.

Network Tab කියන්නේ Application එකේ Investigation Room එක.

UI එක “Failed” කියනවා.

Network Tab එක කියනවා:

🔹 Request එක ඇත්තටම ගියාද?
🔹 Correct URL එකටද?
🔹 GET ද POST ද?
🔹 Status Code එක මොකක්ද?
🔹 Payload එකේ මොනවද ගියේ?
🔹 Token එක attach වෙලාද?
🔹 Backend Response එක මොකක්ද?

UI එක Story එකේ Cover Page එක විතරයි.

Network Tab එකේ Full Evidence එක තියෙනවා.

Request එකක්ම නැත්නම් Backend එකට blame කරන්න එපා.

404 නම් URL/Resource බලන්න.

400 නම් Payload බලන්න.

401 නම් Token/Header බලන්න.

403 නම් Permission බලන්න.

500 නම් Backend Logs බලන්න.

UI එකේ Form Fields ඔක්කොම fill වෙලා තිබුණත් Request එකේ Data missing වෙන්න පුළුවන්.

User Login වෙලා වගේ පෙනුණත්:

Authorization: Bearer undefined

යනවා වෙන්න පුළුවන්.

UI එක:

“Something went wrong.”

කියද්දී Backend Response එක:

“Email is required.”

කියලා exact problem එක දීලා තියෙන්නත් පුළුවන්.

ඒ නිසා මේ Debugging Flow එක මතක තියාගන්න:

Request → URL → Method → Status → Payload → Headers → Response → Logs

Beginner කෙනෙක් කියනවා:

“API එක වැඩ කරන්නේ නැහැ.”

Developer කෙනෙක් කියනවා:

“POST Request එක 400 return කරනවා. Payload එකේ departmentId missing.”

අන්න ඒක තමයි Professional Debugging.

Confusion → Evidence → Understanding → Real Fix

ඊළඟ වතාවේ “Something went wrong” දැක්කම panic වෙන්න එපා.

DevTools open කරන්න.

Network Tab එක බලන්න.

Request එක follow කරන්න.

Guess කරන්න කලින් Inspect කරන්න.

ඔයා Network Tab එකෙන් හොයාගත්ත අමතක නොවන Bug එක මොකක්ද? 😅👇

CMNexa - Learn. Debug. Build.

20/08/2026

🚨 API එක Postman එකේ වැඩ... Browser එකේ Fail? එහෙනම් Problem එක Code එකේම නොවෙන්න පුළුවන්!

Frontend එක හරි.
Backend එක run වෙනවා.
Database එක connected.
API Route එක Postman එකෙන් test කළාම perfect response එකක් එනවා.
හැබැයි React App එකෙන් Button එක click කළාම Console එක red වෙලා මෙහෙම message එකක් එනවා:
"Access to fetch has been blocked by CORS policy."
එතකොට Beginner Developer කෙනෙක් අහනවා:
"API එක කැඩිලාද?"
"Frontend URL එක වැරදිද?"
"Postman එකේ වැඩ කරන එක Browser එකේ වැඩ නොකරන්නේ ඇයි?"
CORS Error එක මුලින්ම දැක්කම Monster එකක් වගේ පේන්න පුළුවන්.
හැබැයි ඇත්ත කතාව වෙනස්.
CORS ඔයාගේ සතුරා නෙවෙයි.
ඒ Browser එකේ Security Guard කෙනෙක්.
Browser එක Website පෙන්වන Window එකක් විතරක් නෙවෙයි.
ඒ Userගේ Data සහ Login Sessions ආරක්ෂා කරනවා.
Bank Account එකකට Login වෙලා ඉන්න වෙලාවක Malicious Website එකකට Background එකෙන් Requests යවන්න පුළුවන් නම්?
User Data read කරන්නත්, Actions perform කරන්නත් ඉඩ ලැබෙනවා.
ඒක dangerous.
ඒ නිසා Browser එක අහනවා:
"මේ Website එකට මේ Server එකේ Data access කරන්න Permission තියෙනවද?"
අන්න ඒකට තමයි CORS කියන්නේ.
CORS = Cross-Origin Resource Sharing
Origin එක හැදෙන්නේ කොටස් තුනකින්:
✅ Protocol
✅ Domain
✅ Port
localhost:5173 සහ localhost:5000 එකම Computer එකේ run වුණත් Ports වෙනස් නම් Browser එකට ඒවා Different Origins.
මේක තමයි වැදගත්ම Point එක.
Postman කියන්නේ Browser එකක් නෙවෙයි.
Postman එක API එකට direct Request එක යවනවා.
හැබැයි Browser එක Origin එක check කරනවා.
Backend එකෙන් correct CORS Permissions නැත්නම් Browser එක Response එක block කරනවා.
ඒ නිසා Postman එකේ වැඩ කරනවා කියලා Browser එකෙත් වැඩ කරන්නම ඕනේ කියලා හිතන්න එපා.
Problem එක Browser සහ Backend අතර Permission Configuration එක වෙන්න පුළුවන්.
CORS Fix කරන්නේ කොහෙද?
Backend එකේ.
Frontend එකට Browser Security ignore කරන්න කියන්න බැහැ.
Professional Developer කෙනෙක් Browser Security disable කරන්නේ නැහැ.
Backend Configuration එක නිවැරදි කරනවා.
CORS Error එකක් ආවම මේවා බලන්න:
✅ Frontend Origin එක
✅ Allowed Origins
✅ Port
✅ HTTP Method
✅ Authorization Headers
✅ OPTIONS Request
✅ Response Headers
Network Tab එක open කරන්න.
Request එක trace කරන්න.
Random Code වෙනස් කරන්න කලින් Flow එක බලන්න.
Beginner කෙනෙක් කියනවා:
"Backend එක වැඩ කරන්නේ නැහැ."
Developer කෙනෙක් කියනවා:
"Backend එක මේ Frontend Origin එකට Access දීලා තියෙනවද බලමු."
අන්න ඒ Thinking Shift එක තමයි Real Debugging.
CORS Monster එකක් නෙවෙයි.
ඒ Browser එක අහන Security Question එකක්.
CORS is not your enemy.
It is the browser protecting users.
ඔයාටත් Postman එකේ වැඩ කරලා Browser එකේ CORS Error එකක් ඇවිත් පැය ගණනක් stuck වෙලා තියෙනවද? 😅
👇 Comment එකකින් කියන්න.
CMNexa - Learn. Debug. Build.

19/08/2026

🚨 GitHub එකට Project එක Push කළා... ඒත් එක්ක Database Password එකත් ලෝකයටම දුන්නාද?

දවස් ගණනක් code කළා.

Errors fix කළා.

Frontend එක Backend එකට connect කළා.

Database එක වැඩ.

Login එක වැඩ.

අන්තිමට Terminal එක open කරලා:

git add .
git commit -m "Complete project"
git push

Project එක GitHub එකට ගියා.

ඔයාට හිතෙනවා:

"Finally! දැන් මගේ Project එක හැමෝටම පෙන්වන්න පුළුවන්."

හැබැයි ඔයා නොදැනුවත්ව මේවාත් Public කරලා නම්?

❌ Database Password

❌ MongoDB Connection String

❌ JWT Secret

❌ Email Password

❌ API Keys

❌ Cloud Credentials

එතකොට ඔයා share කළේ Code එක විතරක් නෙවෙයි.

ඔයාගේ System එකේ Keys ටිකත් ලෝකයටම දීලා.

Code එක Public වෙන්න පුළුවන්.

Secrets කවදාවත් Public වෙන්න බැහැ.

Public GitHub Repositories බලන්නේ මිනිස්සු විතරක් නෙවෙයි.

Automated Bots නිතරම API Keys, Access Tokens සහ Database Passwords හොයනවා.

Small Project එකකට භාවිතා කරපු Paid API Key එකක් accidentally push වුණා කියලා හිතන්න.

වෙන කෙනෙක් ඒක භාවිතා කළා.

Quota එක ඉවරයි.

Account එක charge වුණා.

Small Copy-Paste Mistake එකක් Real Security Problem එකක් වෙන්න පුළුවන්.

Secrets code එක ඇතුළේ hardcode කරන්න එපා.

ඒ වෙනුවට Environment Variables භාවිතා කරන්න.

ඒත් .env file එක GitHub එකට push කළොත්?

ප්‍රශ්නය ආයෙත් එනවා.

ඒ නිසා .gitignore file එකට .env add කරන්න.

තවත් හොඳ practice එකක් තමයි .env.example file එකක් create කරන එක.

මේකෙන් Project එක run කරන්න අවශ්‍ය variables මොනවද කියලා පෙන්නන්න පුළුවන්.

හැබැයි Real Values expose වෙන්නේ නැහැ.

වැදගත්ම දේ:

Secret එකක් GitHub එකට push වුණාම file එකෙන් delete කළා කියලා ප්‍රශ්නය ඉවර වෙන්නේ නැහැ.

Git එකට history එකක් තියෙනවා.

ඒ නිසා exposed secret එකක් දැක්කොත්:

❌ "Delete කළා. දැන් හරි."

✅ "මේ Secret එක compromise වෙලා. Replace කරන්න ඕනේ."

මේකට කියන්නේ Secret Rotation.

තවත් වැදගත් දෙයක්:

Frontend Environment Variables automatically private වෙන්නේ නැහැ.

Browser එකට ගිය දෙයක් Secret කියලා හිතන්න එපා.

Private Secrets Server Side එකේම තියාගන්න.

Professional Developer කෙනෙක් අහන්නේ:

"මම Public කරන්න යන්නේ Code එක විතරද? නැත්නම් Private Access එකකුත් ද?"

මතක තියාගන්න:

✅ Code Public වෙන්න පුළුවන්.

✅ README Public වෙන්න පුළුවන්.

✅ .env.example Public වෙන්න පුළුවන්.

හැබැයි,

❌ Real .env File

❌ Database Password

❌ JWT Secret

❌ API Keys

කවදාවත් Public වෙන්න බැහැ.

Your Code Can Be Public.

Your Secrets Should Never Be.

👇 ඔයා කවදාවත් .env file එක accidentally GitHub එකට push කරලා තියෙනවද? 😅

CMNexa - Learn. Debug. Build.

18/08/2026

🔐 "ඔයාගේ Password එක මට කියන්න" කියන App එකක්... ඇත්තටම Secure App එකක්ද?

User කෙනෙක් Register වෙනවා.

Email එක දානවා.

Password එක type කරනවා.

Create Account click කරනවා.

Developer Database එක open කරලා බලනවා.

Email: [email protected]

Password: myPassword123

Registration success.

Login success.

Dashboard එකත් open වෙනවා.

Beginner Developer කෙනෙක්ට හිතෙන්න පුළුවන්:

"හරි! Login System එක complete."

හැබැයි ඇත්තටම ඒ System එක ඇතුළේ තියෙන්නේ ලොකු Security Disaster එකක්.

Database එකට Userගේ Original Password එක කියවන්න පුළුවන් නම්, ඒ App එක Password එක protect කරන්නේ නැහැ.

Real Application එකක් Userගේ Password එක දැනගෙන ඉන්න ඕනේ නැහැ.

ඒක දැනගන්න ඕනේ එකම දේ:

User දැන් type කරපු Password එක නිවැරදිද?

Database එක leak වුණොත් මොකද වෙන්නේ?

Attackersලාට Usersලාගේ Passwords direct කියවන්න පුළුවන්.

ප්‍රශ්නය එතනින් ඉවර වෙන්නේ නැහැ.

ගොඩක් මිනිස්සු එකම Password එක Email, Social Media සහ Banking Accounts වලටත් භාවිතා කරනවා.

එක Weak Application එකක් නිසා User කෙනෙක්ගේ Digital Life එකම අවදානමට යන්න පුළුවන්.

එහෙනම් Password එක Save කරන්නේ කොහොමද?

Original Password එක Save කරන්නේ නැහැ.

Save කරන්නේ Password Hash එකක්.

Hashing කියන්නේ Password එක secure representation එකක් බවට පත් කරන process එකක්.

User Login කරනකොට System එක Password එක කියවන්නේ නැහැ.

Password එක Stored Hash එකත් එක්ක compare කරලා verify කරනවා.

Hashing සහ Encryption එකම දේද?

නැහැ.

Encryption වලදී Original Data එක ආපහු ලබාගන්න පුළුවන්.

Password Hashing වලදී Goal එක Password එක ආපහු කියවීම නෙවෙයි.

Password එක match වෙනවද කියලා verify කිරීමයි.

තවත් වැදගත් දෙයක්.

හැම Hash Function එකක්ම Password Storage සඳහා සුදුසු නැහැ.

Professional Applications භාවිතා කරන්නේ:

✅ bcrypt

✅ Argon2

✅ PBKDF2

තව Security Lesson එකක්:

Security කියන්නේ Data එක hide කරන එක විතරක් නෙවෙයි.

අවශ්‍ය නැති Information reveal නොකිරීමත් Security.

Working Software හැමදාම Secure Software නෙවෙයි.

Beautiful Login Page එකක් තිබුණත් Passwords Plain Text නම් ඒ System එක dangerous.

User Password එකක් type කරනකොට ඔයාට Trust එකක් දෙනවා.

Developer කෙනෙක් විදිහට ඒ Trust එක protect කරන එක ඔයාගේ Responsibility එක.

මතක තියාගන්න:

❌ Password එක Save කරන්න එපා.

✅ Password Hash එක Save කරන්න.

❌ Password එක decrypt කරන්න හදන්න එපා.

✅ Stored Hash එකත් එක්ක compare කරන්න.

Password එක Save කරන්න එපා.

Hash එක Save කරන්න.

Userව Protect කරන්න.

ඔයා හදපු මුල් Login Project එකේ Password එක Plain Text විදිහට save කරලා තිබුණද? 😅

👇 Comment එකකින් කියන්න.

CMNexa - Learn. Debug. Build.

17/08/2026

🎫 Login වුණාට පස්සේ හැම Request එකකම Email සහ Password ආයෙත් යවන්නේ නැත්තේ ඇයි? මෙන්න පිටිපස්සේ තියෙන Digital Pass එක!

User කෙනෙක් Login Page එක open කරනවා.

Email එක type කරනවා.

Password එක enter කරනවා.

Login Button එක click කරනවා.

Credentials හරි නම් Dashboard එක open වෙනවා.

Userට පේන්නේ:

"Login Successful."

හැබැයි Developer කෙනෙක්ට තවත් ප්‍රශ්නයක් එනවා.

User Dashboard එකෙන් Reports Page එකට ගියාම Backend එක ඒ Userව හඳුනාගන්නේ කොහොමද?

Protected API එකක් call කරන හැම වතාවකම Email සහ Password ආයෙත් යවනවද?

නැහැ.

අන්න එතනට තමයි JWT එන්නේ.

JWT (JSON Web Token) කියන්නේ Login වුණාට පස්සේ Application එක භාවිතා කරන Digital Access Pass එකක්.

Secure Building එකක් හිතන්න.

Entrance එකේ Security Officer ඔයාගේ ID එක verify කරනවා.

ඊට පස්සේ Temporary Access Pass එකක් දෙනවා.

දැන් Building එක ඇතුළේ හැම Door එකකදීම Passport එක ආයෙත් පෙන්වන්න ඕනේ නැහැ.

Access Pass එක විතරක් ඇති.

JWT එකත් ඒ වගේ.

Login වුණාම Backend එක Token එකක් create කරලා Frontend එකට දෙනවා.

ඊට පස්සේ හැම Protected Request එකක් සමඟම Frontend එක ඒ Token එක Backend එකට යවනවා.

Backend එක check කරනවා:

✅ Token එක valid ද?

✅ Expire වෙලාද?

✅ User කවුද?

✅ Permission තියෙනවද?

හැමදේම හරි නම් Request එක continue වෙනවා.

Token එක missing, invalid හෝ expired නම් Request එක reject වෙනවා.

වැදගත්ම දේ:

JWT කියන්නේ Permission දෙන්න හදපු system එකක් නෙවෙයි.

JWT කියන්නේ Identity carry කරන mechanism එකක්.

Authentication අහන්නේ:

"ඔයා කවුද?"

Authorization අහන්නේ:

"ඔයාට මොනවද කරන්න පුළුවන්?"

JWT Authentication එකට උදව් කරනවා.

හැබැයි Authorization checks replace කරන්නේ නැහැ.

🔒 401 = Identity problem

🚫 403 = Permission problem

තවත් වැදගත් Security Lesson එකක්:

JWT එක Signed වුණා කියලා ඒක Automatically Encrypted කියලා හිතන්න එපා.

ඒ නිසා Token එක ඇතුළට Passwords, Credit Card Details හෝ Sensitive Data දාන්න එපා.

JWT එක Protect කරන්න.

Expiration check කරන්න.

Backend එකේ හැම Request එකකම Token verify කරන්න.

JWT Magic එකක් නෙවෙයි.

ඒක Login වුණාට පස්සේ Userගේ Identity carry කරන Digital Pass එකක්.

Userට පේන්නේ Dashboard එකක්.

Developerට පේන්නේ Complete Security Flow එකක්.

JWT කියන වචනය මුලින්ම අහද්දී ඔයාටත් complicated වගේ දැනුණද? 🎫

👇 Comment එකකින් කියන්න.

CMNexa - Learn. Debug. Build.

16/08/2026

🔐 Login වුණා කියලා System එකේ හැමදේම කරන්න පුළුවන්ද?

ගොඩක් Developersලා මෙතන තමයි වැරදියට තේරුම් ගන්නේ.

User කෙනෙක් Email එකයි Password එකයි දාලා Login කරනවා. Dashboard එක open වෙනවා.

එතකොට හිතෙනවා:

"දැන් Userට System එකේ හැමදේටම access තියෙනවා."
හැබැයි ඇත්ත එහෙම නෙවෙයි.
Software Security එකේ වැදගත් Concepts දෙකක් තියෙනවා.
🔐 Authentication = "ඔයා කවුද?"
🛡️ Authorization = "ඔයාට මොනවද කරන්න පුළුවන්?"
Company Building එකක් හිතන්න.
Security Officer කෙනෙක් ID Card එක check කරනවා.
එයා confirm කරනවා:
"මේ පුද්ගලයා ඇත්තටම මේ Company එකේ කෙනෙක්."
මේක Authentication.
හැබැයි Building එක ඇතුළට ගියා කියලා Server Room එකට, Finance Department එකට හෝ CEO Office එකට යන්න පුළුවන්ද?
නැහැ.
ඒක තීරණය වෙන්නේ Permission එකෙන්.
👑 Admin
👨‍🏫 Teacher
🎓 Student

තුන් දෙනාම Login වෙන්න පුළුවන්.
හැබැයි තුන් දෙනාටම එකම permissions නැහැ.
Login Page එකක් තිබුණා කියලා System එක Secure වෙන්නේ නැහැ.
Normal User කෙනෙක්ට Admin Dashboard එක open කරන්න පුළුවන් නම්, Authentication තිබුණත් Authorization නැහැ.
තව වැදගත් දෙයක්:
Frontend එකේ Admin Button එක hide කළාම Security complete වෙන්නේ නැහැ.
Frontend එක hide කරනවා.

Backend එක protect කරනවා.
🔒 401 = Identity problem.
🚫 403 = Permission problem.
Token එක Identity එක prove කරනවා.
Permission එක Actions තීරණය කරනවා.

Authentication Front Door එක open කරනවා.
Authorization ඇතුළේ මොන Doors open කරන්න පුළුවන්ද කියලා තීරණය කරනවා.

Address

No 15, Mattawa Road, Warakamura

21300

Website

Alerts

Be the first to know and let us send you an email when CMNexa posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Shortcuts

  • Want your business to be the top-listed Computer & Electronics Service?

Share