Turing Programming Training Center

How does JavaEE work.
Java က စထုတ်တုန်းက SE ပဲရတယ် standard edition ပေါ့ ဆိုချင်တာက desktop application ပဲရေးဖို.လုပ်ထားတာ။ နောက်ကျတော့ JavaEE ထုတ်လာတယ် အဲ့တော့ enterprise application လွယ်လွယ်ပြောရရင် server side web application ရေးလို.ရလာတယ်။

PHP လိုကောင်မျိုးကျတော့ စထုတ်ကတည်းက server side scripting language အနေနဲ.ထုတ်တာ။ Programming language တွေက ဘယ်လိုလုပ်ပြီး web server တွေနဲ.ချိတ်ဆက်လုပ်တယ် ဒါမှမဟုတ် ဘယ်လိုလုပ် web application ပေးရေးတယ်ဆိုတာကိုနားလည်ဖို. HTTP protocol ရယ် Web server အကြောင်းရယ် နားလည်ဖို.လိုတယ်။
အရင်က အဲ့ဒီအကြောင်းဒီမှာရေးဖူးတယ်

https://web.facebook.com/thet.khine.587/posts/10207213385452495
PHP လို server side scripting language တွေကျတော့ web server နဲ.တန်းချိတ်ပြီးအလုပ်လုပ်တယ်။ Apache လို web server မျိုးပေါ့။ Web server တွေသည် external application program တွေနဲ.ချိတ်ဆက်လုပ်ဖို. interface ပေးထားတယ်။ CGI လို.ခေါ်ကြတယ်။ Common Gateway interface ပေါ့။ Request တခုလာမယ် အဲ့ကနေ web server က တခြား external program ကိုခေါ်မယ် နောက်လိုအပ်တဲ့ data တွေလှမ်းပေးမယ်။ နောက် external program (eg PHP) လိုကောင်က ထွက်လာတဲ့ output တွေကို web client ကိုပြန်ပေးမယ်ပေါ့။ CGI တွေက request တခုလာ process တခုလုပ်လေးလာတော့ နောက်ပိုင်း fast CGI သုံးလာတယ်။

ထားတော့ Java ဘက်ကျတော့ အဲ့လိုမဟုတ်ဘူး web server နဲ.တိုက်ရိုက်မချိတ်ဘူး အဲ့တော့ ဘာလုပ်ရသလဲဆိုတော့ ကိုယ်ပိုင် HTTP server(web server) ဆောက်ရတယ်။ ဉပမာ Java နဲ. Web server ရေးလိုက်တယ်(JavaSE က network programming သုံးပြီး socket program တွေနဲ.လုပ်လိုက်တယ်) ဒါဆို web content တွေ serve လုပ်လို.ရပြီ။ အဲ့ layer အပေါ်ကိုမှ server side program တွေ ရေးလို.ရအောင် servlet ဆိုတဲ့ class တွေထပ်ထဲ့လိုက်တယ်။

Servlet သည် Web request ကိုလက်ခံမယ် output ကိုပြန်ပေးမယ် အဲ့တာလေးပဲ basic flow က ။ ခုနက servlet API ကို support ပေးထားတဲ့ container တွေကို servlet container လို.ခေါ်တယ် ဥပမာ tomcat ပေါ့။
အဲ့တော့ tomcat ထဲမှာဘာပါလဲ ဆိုရင် အဓိက web server (Coyote http connector လို.သုံးတယ်) နောက် servlet ကို support လုပ်ဖို. servlet container( Catalina လို.ခေါ်တယ်) ပါတယ်။

နောက် ခုနက Servlet သည် Java code တွေချည်းရေးရတာ ဆိုချင်တာက html view layout တွေရေးမယ်ဆိုရင် IO command တွေကနေ string နဲ.ရိုက်ထုတ်ရတာ။ အဲ့တော့ view အပိုင်းအဆင်မပြေဘူး အဲ့တာကိုရှင်းဖို.အတွက် JSP ထုတ်လိုက်တယ်( JavaServer Page ) ပေါ့ HTML , Java code တခါတည်းပေါင်းရေးလို.ရသွားတယ်။ JSP ဆိုတာလဲ တကယ်တမ်းက servlet ပါပဲ JSP page ကို compile လုပ်ရင် servlet ပြန်ရတယ်။

ခုနက JSP ကနေ servlet ထုတ်ပေးတဲ့ကောင်ကို JSP Engine လို.ခေါ်တယ်။ Tomcat မှာဆို Jasper engine ပေါ့။ နောက် JSF လို MVC ကောင်တွေထွက်လာတယ် သူတို.လဲ အောက်ဆုံးမှာ Servlet ကိုသုံးရတာပါပဲ။
JavaEE component တွေ technologies တွေ မအောင်မြင်တာကြောင့် third party framework တွေ Spring လိုကောင်တွေထုတ်လာတယ်။ Spring ကျတော့ အဓိက DI support ပေးတယ်။ နောက်ကွယ်မှာ အဓိက server side သုံးတာကတော့ servlet based ကိုပဲသုံးတာ။ Front Contoller pattern ကိုသုံးထားတဲ့ servlet က request တွေကိုအကုန်ဖမ်းထိန်းပြီး မှ နောက် ဆိုင်ရာ controller တွေဆီကိုပို.ပေးတာ။ DispatcherServlet လို.ခေါ်တယ်။

နောက်ပိုင်း Node.js က rest API framework တွေခေတ်စားလာတော့ Java ဘက်မှာခုနက container တွေမလိုပဲ framework ထဲမှာတင် web server ပါလာအောင် content handling ထဲ့ပေးထားတဲ့ micro framework တွေပေါ်လာတယ် eg. spark.

Why use token authentication

Authentication ဆိုတာက system တခုကိုသုံးခွင့်ရှိတဲ့ user ဟုတ်မဟုတ်(identity) ကိုစစ်တာ ဥပမာ ကျောင်းထဲဝင်ဖို့
ကျောင်းသား ဒါမှမဟုတ် ဆရာ ဒါမှမဟုတ် ကျောင်းမှာအလုပ်လုပ်နေတဲ့သူတွေပဲဝင်လို့ရမယ်။ ကျောင်းကို system လို့သတ်မှတ်ရင်
ခုနက ကျောင်းသား ဆရာ စတာတွေက valid user ပဲ။ အပြင်လူဝင်လို့မရဘူး။ ဥပမာ facebook သုံးရင် facebook user ဖြစ်မှ
သုံးလို့ရမယ်။

Authorization

Authorization ဆိုတာကျတော့ user က valid user ဖြစ်ပြီ(already authenticated) ဒါပေမဲ့ resource တခုခုကို
access လုပ်ဖို့ right ရှိသလားဆိုတာစစ်တာ၊ ဥပမာကျောင်းထဲ ကျောင်းသားကဝင်လို့ရပေမဲ့ ကျောင်းအုပ်ကြီး ဗီဒိုတော့ဖွင့်ခွင့်ရှိမှာမဟုတ်ဘူး။
အဲ့တာက Authorization, ဥပမာ user level role ပဲရှိတဲ့သူက admin level role ရှိတဲ့ page, function စတာတွေ
သုံးလို့မရဘူး။

Token based authentication ဆိုတာ Web, Mobile, Server to server(microservices) စတာတွေမှာ
token တခုကိုသုံးပီးတော့ authenticated လုပ်တာကိုပြောတာ။ Token ဆိုတာ ကတော့ များသောအားဖြင့် user identity ဒါမှမဟုတ် grant ကို hash ယူထားတာပါပဲ။
Physical token (key card လိုကောင်တွေ) တွေရှိသလို software token တွေရှိပါတယ်။ software token ဘက်မှာဆို OAuth, JWT စတာမျိုးတွေရှိကြပါတယ်။

JWT ကဒီမှာရေးထားဖူးပါတယ်။
https://www.facebook.com/thet.khine.587/posts/pfbid02NLUMj5Vi8cu5gFXNv1CFHg2SNuXrrXtuyRkqU6tggA7hQKCYfUdcRKG87rJWLCvWl

Token based authentication flow က ဒီလိုသွားတယ် အကြမ်းဖျင်းပေါ့

user က login ဝင်ဖို့ username,password နဲ့ပေးလိုက်တယ် server ဘက်က username password မှန်ရင် token
ပြန်ပေးလိုက်တယ်။ အဲ့ token ကို နောက် API call တွေဖို့ header ထဲမှာထဲ့ပေးလိုက်တာ။ဒါဆို server က token
ကိုစစ်ပြီး valid token ဆိုရင် authenticated ဖြစ်ပြီဆိုပြီးသတ်မှတ်လိုက်တာ။

များသောအားဖြင့် access token, refresh token ဆိုပြီးသုံးကြတယ်။ Access token က သက်တမ်းတိုတယ်။
ဘာလို့ဆိုတော့ token ကိုရသွားရင်ပေါက်သွားမှာစိုးလို့၊ အဲ့တော့ acess token expiry ဖြစ်သွားရင် refresh token
ကိုသုံးပြီး access token ပြန်ထုတ်တယ်။ refresh token ကျတော့ expire time ကိုကြာကြာထားလေ့ရှိတယ်။

Web application တွေဆိုရင် session based authentication ကိုလဲသုံးလို့ရတယ်။ User က login ဝင်မယ်။
Credential မှန်ရင် unique session ID ထုတ်ပေးလိုက်မယ်။ Session ID ကိုဘယ်လိုထုတ်သလဲဆိုတော့ timestamp,
user_id, random number, hash စတာတွေသုံးပြီးထုတ်တယ်။ Language တခုနဲ့တခုတော့မတူဘူး Guess လုပ်ရခက်အောင်
unique ဖြစ်တဲ့ hash ပဲ။ ပြဿနာက သူ့ကို file system ဖြစ်ဖြစ် (PHP မှာဆို file မှာသိမ်းတယ်) DB မှာဖြစ်ဖြစ်သိမ်းရတယ်။
အဲ့တော့ scalable မဖြစ်ဘူး။ဥပမာ ဒီ session က valid ဖြစ်လား စစ်ဖို့ File read, DB Read လုပ်နေတာ မျိုးသည် IO ပါတယ်။
JWT လို token မျိုးကျတော့ in memory မှာတင် hash တွက်လို့ရတယ် ပိုမြန်တယ်။
နောက် session တွေသည် ဆိုင်ရာ web server နဲ့ tie ဖြစ်တယ်။ တကယ်လို့ ကိုယ်က scalability ရဖို့ load balancer
နောက်မှာ web server ၂ ခုသုံးရမယ်ဆိုရင် web server1 နဲ့ session ID ထုတ်ထားတဲ့ request သည် web server 1 ဆီကိုပဲသွားရတယ်
အဲ့တော့ load balancing မှာအဆင်မပြေဘူး။ sticky session လို့ခေါ်တယ်။
Token based ကျတော့အဲ့လိုမဖြစ်ဘူး ကြိုက်တဲ့ကောင်သွား microservices architecture မှာဆိုအိုကေတယ်။

များသောအားဖြင့် web session တွေကို cookie မှာသိမ်းကြတယ်အဲ့တော့ CRSF attack ဖြစ်နိုင်တယ်။

Token တွေကို server ဘက်ကနေ revoke လုပ်နိုင်တယ်။အဲ့အခါကျတော့ tigher control ဖြစ်တယ်။

Federate authentication

Authentication system တခုထဲကိုသုံးပြီးတော့ multiple system တွေကို access ပေးတာ၊ ဥပမာ Facebok, Google
သုံးပြီးတော့ medium တို့လိုကောင်တွေကို register/login ဝင်လို့ရတယ် ဒါမျိုးကို Federate authentication လို့ခေါ်တယ်။
SSO (Single Sign On )လို့လဲသုံးကြသေးတယ်။

ခုနက session id လိုကောင်မျိုးက ဆိုင်ရာ system DB, file system မှာသိမ်းတဲ့အတွက် ဥပမာ app1 က db ကို app2 ကို
ပေးသုံးမှ login ဝင်လို့ရမဲ့ပုံစံဖြစ်တယ်။ Token ကျတော့ သိမ်းထားတာမရှိတဲ့အတွက် Federate authentication
ပိုအဆင်ပြေတယ်။