မင်္ဂလာပါ!

လှိုက်လှဲစွာကြိုဆိုပါသည်။ ယခု ပထမဆုံးအကြိမ် ရောက်ဖူးခြင်းဖြစ်ပါသလား? ဝင်ရောက် ဆွေးနွေး မေးမြန်းလိုပါလျှင် အောက်တွင်ဖော်ပြထားသော button များမှတဆင့် ဝင်ရောက် ဆွေးနွေးနိုင်သကဲ့သို့ အဖွဲ့ဝင်အသစ်အနေဖြင့်လည်း လျှောက်ထားနိုင်ပါတယ်။

MYSTERY ZILLION တွင် English သို့မဟုတ် Unicode ဖြင့်သာ အသုံးပြုခွင့်ရှိသည်။ ဇော်ဂျီ ၊ ဧရာ စသည်တို့ကို အသုံးပြုခွင့် မရှိ။ Unicode fonts များမှာ Mon3,Yunghkio, Myanamr3 စသည်များ အသုံးပြုနိုင်သည်။ Unicode Guide ကို ဒီမှာ Download ချပါ။ Zawgyi to Unicode Converter
Don't share ebook or software if nobody request. You can find free book websites on here. We are welcome for discussion or asking question instead.

Servlet အကြောင်း ကျွန်တော် သိသလောက် အကြမ်းဖျင်း

edited November 2014 in Java

Servlet ဆိုတာ ဘာမှ မဟုတ်ဘူး Java Program ပါပဲ

အရင် ဆုံး GET method နဲ. POST method အကြောင်းလေးကို အဆင့်ကျော်ပြီး ပြောပြမယ်

ဘယ်အချိန်မှာ GET နဲ. သုံးပြီး ဘယ်အချိန်မှာ POST ကို သုံးမလဲ ?

အဲ့တာလေး သိသလိုလို နဲ. အမှတ်မှား နေကြတယ်ဗျ။

သိသလားဆို သိသယောင်ယောင်ပဲ တကယ်ပြောဟေ့ဆို ကွဲကွဲပြားပြား မသိတော့ဘူး။

ကဲထားတော့ အစကပဲ စပြောတော့မယ်။

အရင် ဆုံး Client နဲ. Server ဆိုတာကို သိရမယ်။

Client ဆိုတာ Browser ကို ပြောတာ။

Server ဆိုတာ web server ကိုပြောတာ။

web server ဆိုတာ ဥပမာ Tomcat , GlashFish , JBoss  တို.ပေါ့။

အဲ့ဒီ့ web server တွေထဲမှာ ဘာရှိလဲ ဆိုတော့ servlet.jar ဆိုတာလေး ရှိတယ်။

အဲ့ကောင်က ဘာလုပ်ပေးလဲ ဆိုရင် server ကို ဥပမာ tomcat ကို စလိုက်ရင် Servlet container ကို ဆောက်ပေးတယ်။

Servlet container ဆိုတာ Servlet တွေကို handle လုပ်ပေးတဲ့ container။

အရင် ဆုံး servlet lifecycle ကိုပြောပြမယ်။

တို.တွေ client ကနေ client ဆိုတာ browser ပေါ့ url bar မှာ တစ်ခုခု ထည်.လိုက်ရင် ဘာစလုပ်လဲ ဆိုတော့ request တစ်ခုကို create လုပ်တယ်
request ကို create လုပ်တာက browser ကနေလုပ်ပေးတာ ။ တစ်ခြား ဘာကမှလုပ်ပေးတာ မဟုတ်ဘူး ။

အဆင့် ၁ ။ url bar မှာ တစ်ခုခုထည်.လိုက်တာနဲ. browser က request တစ်ခုကို တည်ဆောက်ပေးတယ်။
အဆင့် ၂ ။ အဲ့ဒီ့ request ကို သက်ဆိုင်ရာ server ဆီကို ပို.ပေးတယ်

တို.က tomcat server နဲ. project ကို run ထားရင် အဲ့ဒီ့ request က tomcat server ဆီကို HTTP protocol ကနေတစ်ဆင့်ရောက်လာတယ်

URL မှာ port ရှိတယ် မဟုတ်လား ? local host 8080 ဘာညာပေါ့ ။

tomcat က စ  run ကတည်းကလည်း သူ.ရဲ. listen port က ရှိပြီးသားလေ။

browser က request လုပ်တဲ့ port နဲ. server listen လုပ်တဲ့ port မတူရင်တော့ tomcat server ဆီကို ရောက်လာမှာ မဟုတ်ဘူး။

အဆင့် ၃ ။ server က (tomcat)  ရောက်လာတဲ့ request ကို mapping လုပ်ထားတဲ့ servlet ကို activate လုပ်တယ်။

mapping လုပ်တယ်ဆိုတာ ဘယ်မှာ လုပ်တာလဲ ဆိုတော့ tomcat ရဲ. Deployment Descriptor ထဲမှာ mapping လုပ်တာ။

တို.ရဲ. java ee  project ထဲမှာ ကြေငြာတဲ့ web.xml file ဟာ tomcat server ပေါ်တင်လိုက်ရင် tomcat ရဲ. deployment descriptor အနေနဲ. အလုပ်လုပ်တယ်

အဲ့အထဲမှာ တို.က နေ servlet mapping တွေကြေငြာတယ် မဟုတ်လား ?

URL က ဘာနဲ.လာရင် ဘယ် servlet ကိုလုပ်ပါဆိုပြီးလေ။

Servlet Class ကို ညွှန်းထားတယ်။

Servlet Class ဆိုတာက javax.servlet.http.HTTPServlet class ကို extend လုပ်ထားတဲ့ class ကိုပြောတာ

servlet class ကို activate လုပ်တယ် ဆိုတာ ဘယ်လိုလုပ်လဲ ပြောပြမယ်။

HTTPServlet ဆိုတဲ့ class မှာ method သုံးခု ရှိတယ် ။ init() , service() , destroy()

အဲ့အထဲကမှ init method ကို အရင် ခေါ်လိုက်တယ်။

အဲတာဆိုရင် ဘာဖြစ်သွားလဲ ဆိုတော့ အဲ့ဒီ့ servlet class ကို Servlet container ကနေ instantiate လုပ်ပြီး Servlet container ထဲမှာ addressing လုပ်ပြီး 

မှတ်ထားလိုက်တယ်

tomcat server ကို စလိုက်ရင် servlet container ဟာ memory ပေါ်မှာ နေရာယူသွားတယ်။

ဆိုတော့ servlet container က servlet ကို instantiate လုပ်တဲ့ ပြီးတဲ့ အခါမှာ အဲ့ဒီ့ servet ဟာ memory ပေါ်မှာ နေရာယူထားတဲ့ servlet container အထဲမှာ 
သွားသိမ်းတယ်။

အဲ့တာကို servlet activate လုပ်တယ်လို.ခေါ်တယ်။

အဆင့် ၄ ။ သက်ဆိုင်ရာ servlet ရဲ. service() method ကိုခေါ်တယ်။

service() ဆိုတဲ့ method ဟာ servlet ရဲ. အဓိက method ပဲ ။ သူက request တစ်ခု ဝင်လာတိုင်း လုပ်မှာ။

init() method နဲ. မတူတာက init() method ဟာ servlet ကို ပထမဆုံး အကြိမ် instantiate  လုပ်တဲ့ တစ်ကြိမ်ပဲ ခေါ်မှာ

service() method ကတော့ request လာတိုင်း ခေါ်ပေးမှာ။

အဆင့် ၅ ။ service() method မှ တစ်ဆင့် request ရဲ. type အပေါ်မူတည်ပြီး သက်ဆိုင်ရာ method ကို ခေါ်ပေးတယ်

request က GET နဲ. ခေါ်ရင် doGet() method ကို ခေါ်မယ် POST နဲ.လာရင် post method ကို ခေါ်မယ်။

အဆင့် ၆ ။ request က ပါလာတဲ့ information တွေကို manipulate လုပ်တယ်။

file တွေ write တာ DB ထဲကို data သိမ်းတာ ။ DB ထဲက data တွေ သွားယူတာ အဲ့တာမျိုး service method တွေလုပ်တာပေါ့။

အဆင့် ၇ ။ Response ကို create လုပ်တယ်။

အခု တောင်း ခံ တဲ့ request နဲ.လျော်ညီစွာ သက်ဆိုင် တဲ့ inforamtion တွေကို client ဘက်ကို ပြန်ပေးဖို. အတွက် Response ကို create လုပ်ပေးတယ်။

အဆင့် ၈ ။ client ဘက်ကို response ပြန်ပေးတယ်။
အဆင့် ၉  ။ client ဘက်မှာ response ပြန်လာတဲ့ data တွေကို ပြန်ပြီး render လုပ်တယ်။

client ဆိုတာ browser ကိုပြောတာနော်။

အဲ့တာ servlet ရဲ. LifeCycle ပဲ ။

အဲ့တော့ တစ်ခုစီ နည်းနည်း detail ပြန်သွား မယ်။
browser က request တစ်ခုကို create လုပ်တာကနေ စပြောမယ်။
browser က request တစ်ခုကို create လုပ်တဲ့ အခါမှာ ဘာတွေ ပေးလိုက်သလဲ ဆိုရင် 

requestHeader
requestBody 
session
cookie

အဲ့တာတွေ server ဘက်ကို ပို.ပေးလိုက်တယ်

requestHeader ထဲမှာ ဘာတွေ ပါမလဲ ဆိုတာ သိချင်ရင် fireBug ကနေကြည်.ကြည်. http://puu.sh/ccMvs/7301f28f2d.png

requestHeader ကိုပဲ ကြည်.နော် responseHeader ကိုသွားမကြည်.နဲ.။

အဲ့ဒီ့ information တွေက browser ကနေထည်.ပေးတာ။

ကိုယ်တိုင် explicit ထည်.ပေးတာမဟုတ်ဘူး။

ဒီနေရာမှာ ပြောပြမှာက request method

request method မှာ GET နဲ. POST ဆိုတာ အဓိက အားဖြင့်ရှိတယ်။

get ဆိုတာ ယူတာ post ဆိုတာ ပို.ပေးတာ အဲ့လိုများ ဘာသာ သွားပြန်မိလို.ကတော့ စလွဲပြီပဲ။

get ဆိုတာလည်း request လုပ်တာ post ဆိုတာလည်း request လုပ်တာလို.မှတ်။

ဘာကွာလဲ ဆိုတော့ get method နဲ. ဆို Query String ကို အသုံးပြုတာ။

post method ဆို request body ထဲမှာ ထည်.ပြီးပို.တာ။

အရင်ဆုံး get ကို အရင်ပြောပြမယ် get ဆိုတာ url ကနေ parameter တွေကို ထည်.ပေးတာ http://www.colay.com.mm/automobile/news/search?q=test&n=top100 ဒါမျိုး

? အနောက်ကနေ စပြီး အဆုံးထိက Query String လို.ခေါ်တယ်

Server ဘက်မှာ အဲ့ဒီ့ ပို.ပေးလိုက်တဲ့ query string ကို ကြည်.ပြီး manipulate လုပ်မှာ

Post method ကကျတော့ request ရဲ. body ထဲမှာ ထည်.ပြီး ပို.တာ http://puu.sh/ccN1Z/c3403d1787.png ဒါမျိုး

သူ.တန်ဖိုးတွေကို URL မှာ မမြင်ရဘူး ။

GET method မှာ ကန်.သတ်ချက်ရှိတယ်။ Query String က 1024 ထက်မကျော်ရဘူး။

နောက် အဓိက အချက်က password တို.ဘာတို.နဲ. request လုပ်တဲ့ နေရာမှာ မသုံးရဘူး

ဘာလို.လည်း ဆိုတော့ URL bar မှာ တိုက်ရိုက်မြင်နေရလို.ပေါ့

အဲ့ post method က ကျတော့ request body ထဲထည်.ပို.တာ ဆိုတော့ တိုက်ရိုက်တော့မမြင်ရဘူးပေါ့

ဒါပေမယ့် firebug တို.လို web devloper tool တွေနဲ. request body ကို ထောက်ကြည်.ရင် မမြင်ရဘူးလား ?

မြင်ရတာပေါ့ ။ အဲ့တာဆို ဘယ်လိုလုပ်မလဲ ?

encode လုပ်တာပေါ့ ။ encode လုပ်ပြီး ပို.တာပေါ့ ။ တို.ဆို အခု md5 နဲ. encode လုပ်ပြီး ပို.တယ်လေ။

အဲ့မှာ စလာပြီ အဲ့တာဆို ကျွန်တော်တို. အမြဲတန်း request method ကို POST ပဲ သုံးရမှာလား ?

မဟုတ်ဘူး ။ သူ.နေရာနဲ.သူ ။ POST ကို သုံးထား ရင် ကိုယ်သုံးချင်တဲ့ URL ကို မရနိုင်တော့ဘူး ။

GET က ရနိုင်တယ်။ ရှုပ်သွားလား  ?
ဥပမာ ကျွန်တော်က toyota ကားတွေ ရှာထားတဲ့ လင့်ကို ခင်ဗျားကို ပို.ပေးမယ် ။  http://www.colay.com.mm/automobile/news/search?q=toyota&n=top ဒါမျိုး

url ကို ကြည်.လိုက်ရင် GET ကို သုံးထားတာကို တွေ.ရမှာပေါ့

အဲ့တာကို ကျွန်တော်က post method နဲ.သာ သုံးပြီး ရှာလိုက်ရင် ခင်ဗျားတို.ကို toyota ကား ရှာထားတဲ့ page ကို URL နဲ. ခင်ဗျားတို.ကို လင့် 
ဘယ်လိုပေးရမလဲ ?

http://www.colay.com.mm/automobile/news ဒါမျိုးပဲ ပို.ပေးနိုင်တော့မှာပေါ့ ။

အဲဒီ့ သဘောတရားကို နားလည် ရင် get method ကို ဘယ်လိုနေရာ POST method ကို ဘယ်လို နေရာဆိုတာ နားလည် မယ်ထင်တယ်။

ဥပမာ သတင်းလင့်တစ်ခုကို ခင်ဗျားတို.ကို ပို.ပေးမယ် http://www.colay.com.mm/automobile/news/detail/1642
အဲ့တာ GET နဲ. ယူထားတာလေ

ဒီနေရာမှာ ကျွန်တော်က ပေးလိုက်တဲ့ id ကို request body ထဲထည်.ပြီး request လုပ်လိုက်ရင် ဒီလိုပြလို. မရတော့ဘူး။

ကဲ GET နဲ. POST ကို နည်းနည်း ကွဲပြီ ဆိုရင် server ဘက်ကို ထပ်ပြောပြမယ်။

server က  request လုပ်လာတဲ့ request ကိုကနေ browser က ပို.ပေးလိုက်တဲ့ ဟာ မှန်သမျှ ရနိုင်တယ်။

browser က ဘာတွေ ပို.ပေးလိုက်လဲ ဆိုတာ အထက်မှာ ပြောပြခဲ့ပြီးပြီ user ရဲ. session တို. cookie တို.မှ အစပေါ့

ဘယ်က နေ ယူရမလဲ ဆိုရင် request ရဲ. header information တွေကို ယူချင်ရင် request.getHeader("param") ဆိုပြီးယူ

key တွေကတော့ firebug မှာကြည်.

request  header ထဲမှာ ရှိတဲ့ content-length ဆိုတာက post method မှာပဲရှိမှာ ။ GET method ဆိုမရှိဘူး။

အဲ့နောက်ပြီး session ကို ယူချင်ရင် request.getSession() ပေါ့

cookie ကိုယူချင်ရင် request.getCookie ပေါ့

request လုပ်လိုက်တဲ့ data တွေကို ယူချင်ရင် POST နဲ.ပဲ လာလာ GET နဲ.ပဲ လာလာ request.getParameter("param") နဲ.ယူ

အဲ့တော့ response အကြောင်းထပ်ပြောမယ်။

အင်း တစ်ခုကျန်ခဲ့သေးတယ် တစ်ချို. ဟာတွေက POST method ကို သုံးမှ ရမှာ မျိုးတွေရှိတယ်။ ဥပမာ fileupload လုပ်တာမျိုးပေါ့ ။ get ကိုသုံးရင် url length 

က မဆန်.ဘူးလေ

ကိုင်း response

Response ပြန်တဲ့ အခါမှာလည်း request နည်းတူ header နဲ. body ဆိုတာရှိတယ်။

response header မှာ အဓိက ကျတဲ့ attribute ကိုပဲ ပြောပါမယ် content type

content-type ဆိုတာက browser ကနေ ပေးလိုက်တဲ့ response ကို ဘယ်လို render လုပ်ရမလဲ ဆိုတာပြောပေးတာ

တစ်ခြား attribute တွေလည်း ရှိသေးတယ်နော် status code တွေ

status code ဆိုတာက servlet ကနေထည်.ပေးတာမဟုတ်ဘူး ။ servlet container ကနေတစ်ဆင့်ထည်.ပေးတာ

content-type တွေမှာ အမျိုးအမျိုးရှိတယ်။

test တွေချည်းပြ ပြချင်သလား ? text/plan

html တွေနဲ.ပြန်ပြချင်ရင်  text/html

ပုံတွေပြန်ပေးမှာလား  ? image/png , image/jpg

pdf ဖိုင်လား ? application/pdf

excel file လား ? applicatiion/ms-excel

အဲ့ type တွေအကုန်လုံးကို သိချင်ရင် google မှာ MIME လို.ရှာကြည်.

response ပြန်တဲ့ အခါမှာ server ဘက်ကနေ ဘာတွေ လုပ်ပေးနိုင်သေးလဲ ဆိုတော့ cache တွေ create လုပ်တာ ။ cookie ထဲ ထည်.တာ ။ session ထဲမှာ 

သိမ်းတာတွေလည်း လုပ်ပေးနိုင်သေးတယ်။

နောက်ထပ် Servlet ဘက်ကို ထပ်သွားမယ်။

servelt ကို တစ်ကြိမ်ပဲ create လုပ်တယ်။ request တစ်ခုလာတိုင်း အသစ်မလုပ်ဘူး။

နောက်ပြီး servlet တွေဟာ project စ run ကတည်းက servlet container က instantiate လုပ်ထားတာမဟုတ်ဘူး ။

သက်ဆိုင်ရာ servlet နဲ. ကိုက်ညီတဲ့ mapping ရောက်လာတော့မှ (ပထမဆုံးအကြိမ် request ဝင်လာမှ) create လုပ်တာ

ဘယ်လို create လုပ်သလဲ ဆိုတာ အထက်မှာ ပြောခဲ့ပြီးပြီ

ပထမဆုံး တစ်ကြိမ် request ဝင်လာမှ လုပ်မှာနော်

နောက်ထပ် request ဝင်လာလို.ရှိရင် ရှိပြီးသား servlet instance ကို ပဲ ပြန်ပြန်သုံးသွားမှာ

singleton ဖြစ်တယ်ပေါ့။

ပြောရရင် servlet ရဲ. init() method ကို ထပ်မခေါ်တော့ဘူး။

service() method ကိုပဲ ထပ်ထပ်ခေါ်ပေးတယ်။

service() method က requst ရဲ. type ကိုကြည်.ပြီး သက်ဆိုင်ရာ doGet doPost ကို လွှဲပေးတယ်။

အဲ့ဒီတော့ servlet တစ်ခုကို ထားပါတော့ AServlet ကို A user နဲ. B user က တစ်ပြိုင်တည်း request လုပ်တယ်ဆိုပါဆို.

အဲ့လိုမျိုး request တွေဝင်လာရင် servlet container ကနေ request တစ်ခုချင်း စီကို thread တစ်ခုစီ အဖြစ် လုပ်ဆောင်ပေးတယ်။

ဒါပေမယ့် request တိုင်းကတော့ servlet instant တစ်ခုတည်းကိုပဲ သုံးသွားမှာနော်။ အဲ့တာ သိထားရမယ့် အချက်ပဲ။

ဘာကြောင့်လဲ ဆိုတဲ့ servlet ထဲမှာ member data တွေ static data တွေကို သုံးမိရင် local variable တွေမဟုတ်ပဲနဲ.လေ။

အဲ့တာ ဟာ thread တိုင်းမှာ လိုက်ပြီး reflect ဖြစ်နေမှာ ဆိုတာကို သိထားရမယ်။

နောက်ထပ် ဘာကို ဆက်သွားမလဲ ဆိုတော့ ServletContext …..

ServletContext ဆိုတာကို မကြာခဏ တွေ.ဖူးကြမှာပေါ့ ။ Spring ကိုသုံးတော့။

servlet ဟာ servlet container ထဲမှာ addressing လုပ်ပြီး သိမ်းထားတယ်။ request တစ်ခု ဝင်လာလိုက်ရင် အဲ့ servlet ကို အသုံးပြုပြီး handle လုပ်တယ်။

request ရဲ. session တို.ဘာတို.ပေါ့။

thread တစ်ခုချင်းစီအနေနဲ.။

A user ရဲ. request နဲ. B user ရဲ. request တစ်ခုနဲ. တစ်ခု ဆက်စပ်မှုမရှိဘူး ။ thread ကွဲတာကိုး

A user ရဲ. session ထဲထည်.ပေးလိုက်တာက A user ရဲ. request ထဲကိုပဲ response အနေနဲ.ပြန်ပါသွားမယ်။ B user ထဲ ပါမှာမဟုတ်ဘူး။

ဒါပေမယ့် servletContext က ကျတော့ servlet container ထဲမှာ သိမ်းတာ

အဲ့တာကြောင့် request တိုင်းက နေ ယူသုံးလို.ရတယ်။

ServletContext ဟာ web application တစ်ခုလုံးနဲ. ဆိုင်တယ်။

servletContext ထဲက data ကိုယူချင်ရင် ServletContext context = request.getSession().getServletContext();

HTTPRequest Object ကနေယူရမယ်။

နောက်ထပ်ထပ်ပြောပြမှာက RequestDispatcher ဆိုတာပဲ။

ဒါလဲ Spring ကိုသုံးရင် တွေ.ဖူးမှာပေါ့။

Request dispacher ဆိုတာက servlet တစ်ခုကနေတစ်ခု လွှဲပေးတဲ့ နေရမှာသုံးတယ်။

ဥပမာ page တစ်ခုကိုလာလိုက်တယ်။ login မဝင်ရသေးဘူး  ဒါဆို login servlet ကိုပြန်လွှဲပေးတယ်။

login ဝင်တယ် အကောင့်မရှိသေးဘူး ။ ဒါဆို register servlet ကို ပြန်လွှဲပေးတယ်။

စသည်ဖြင့် servlet တစ်ခုက နေ တစ်ခြား servlet တစ်ခုကို လွှဲပေးတဲ့ နေရတွေမှာ RequestDispatcher ကိုသုံးတယ်။

RequestDispatcher မှာ နှစ်နည်း ရှိတယ်။ forward နဲ. include နဲ.

forward ကျတော့ အခု လက်ရှိရောက်နေတဲ့ servlet ရဲ. အလုပ်တွေ …. response ထဲကို ဘာထည်.ညာထည်.ပေါ့ အဲ့တာတွေကို discard လုပ်လိုက်ပြီး အစက 

ဝင်လာတဲ့ request obj ကိုပဲ နောက် servlet ကိုလွှဲပေးလိုက်တာ

include ကတော့ merge လုပ်ပေးတဲ့ အခု servlet က response  ကော နောက် servlet က response ကော ။

နောက်တစ်ခု ServletFilter

Servlet filter က လည်း servlet နဲ. တစ်ပုံစံတည်းပဲ ။ deployment descripter ထဲမှာ mapping လုပ်ပေးရတယ်။ Servlet Container ထဲမှာ နေရာယူတယ် ။ 

အားလုံး အတူတူပဲ servlet လုပ်သလို။

ဘာကွာလဲ ဆိုတော့ သူက သက်ဆိုင် ရာ servlet ကို request လာတဲ့ အခါမှာ ကြားဖြတ် အရင်ဝင်တယ်။ servlet ကို မရောက်မီ။

ServletFilter ထဲကို ဝင်လာပါပြီ ရဲ. အဲ့အချိန်မှာ လိုအပ်တာတွေ စစ်လို.ရပြီ ။ ပြောရရင် ဂိတ်စောင့်ပေါ့။

ဘာလာလုပ်တာလဲ ။ ဘယ်သူနဲ. တွေ.ချင်တာလဲ ။ တွေ.ခွင့်ရှိလား ။ ဘယ်အချိန်ရှိပြီလဲ ။

အဲတာမျိုးတွေ ဝင်မေးရော

ဥပမာ Role Base နဲ.ပါတ်သတ်တာတွေပေါ့

Role မရှိဘူး ဆိုရင် ဘယ် url ကို redirect လုပ်ပါ ပေါ့ Role ရှိရင်တော့ ဆက်သွား ပေါ့ ။ ဆိုပြီး success ဖြစ်ရင် servlet ကို ဆက်သွားခိုင်းတယ်။

ဥပမာ ဒါမျိုး ။ 

            public void doFilter(ServletRequest request, ServletResponse response,
                                 FilterChain filterChain)
            throws IOException, ServletException {

                String myParam = request.getParameter("myParam");

                if(!"blockTheRequest".equals(myParam)){
                    filterChain.doFilter(request, response);
                }
            }

filterChain.doFilter ဆိုတာက သူ request လုပ်တဲ့ servlet ကို ဆက်သွားခိုင်းတာ။

Spring Security တွေကို လေ့လာရင် ဒီသဘောတရားတွေကို သိထားရမယ်။

နောက်ဆုံး အနေနဲ. တစ်ခုပဲ ပြောပါတော့မယ်။

Servlet တွေဟာ ပထမဆုံး request လာမှပဲ instantiate လုပ်မှာဆိုတော့ တစ်ချို.ဟာတွေဆိုရင် server စတတ်ကတည်းက ရှိနေဖို.လို.တဲ့ servlet တွေရှိတယ်။

ဥပမာ DB နဲ. connection ယူတာ

အဲ့တာမျိုးဆိုရင် ဘယ်လိုလုပ်ရမလဲ ဆိုတော့ web.xml ထဲမှာ servlet ကို ကြေငြာတဲ့ အခါမှာ  1 ဆိုတဲ့ attribute လေးထည်.ပေးလိုက်ရုံပါပဲ။

ဂဏန်းငယ်တဲ့ အကောင်က အရင် instantiate လုပ်ပါမယ်။

Servlet ရဲ. Destory() method ကို web server ကို ပိတ်လိုက်တဲ့ အချိန်မှာ လုပ်ပါတယ်။

web server ဆိုတာ tomcat ကို ပြောတာနော်။

ဘာလို. destroy () method ကိုထားပေးတာလဲ ဆိုတော့ server မပိတ်ခင် လုပ်ချင်တာလေးတွေရှိရင် လုပ်လို.ရအောင်။

ဥပမာ DB connection တွေကို close လုပ်တာ ။ file တွေ save တာပေါ့။

ဖတ်ကြည်.တာ ကျေးဇူးပဲ။ ကျွန်တော့်အလုပ်မှာ ဂျူနီယာလေးတွေကို ရှင်းပြတာကို ဒီမှာ တင်လိုက်တာပါ။ fomat သိပ်မကျတဲ့ အတွက် sorry ပါ။ ကျွန်တော်ပြောတဲ့အထဲ မှားနေတာ ရှိရင်လည်း ပြင်ပေးကြပါဦးဗျာ။

Tagged:

မှတ်ချက်များ

  • edited December 2014 Administrators

    စိတ်ရှည်လက်ရှည် ရေးထားတာ ကောင်းပါတယ် Java အတွက် ဖတ်မယ့်လူရှိရင် အသုံးတည့်မှာပါ တခုပဲဖြည့်ပြောချင်တာက HTTP ပေါ်မှာ Request တွေဟာ Secure ဖြစ်တယ် မဖြစ်ဘူးဆိုတာက Firebug or Developer Tools တို့လို Debugging Tools တွေနဲ့ ကြည့်ရင် မြင်ရတယ် မမြင်ရတာက အဲဒီ့ Layer ဟာ Application Layer ဖြစ်နေပြီ User ကိုယ်တိုင် ဖြစ်နေပြီဖြစ်လို့ အဲဒီ့ Layer မှာ တကယ်တော့ Secure ဖြစ်ဖို့ အရမ်းကြိုးစားပြီး လုပ်စရာ မလိုအပ်ပါဘူး။ တကယ်တမ်းက အရေးကြီးတာက Client နဲ့ Server ကြားမှာ Plain HTTP ပေါ်က သွားနေရင်တော့ Network Gateway, ISP စသည်ဖြင့် နေရာတွေကနေ Capture လုပ်ရင် မြင်နေရမှာပါပဲ။ ဘယ်လောက်ပဲ ကြိုးစားကြိုးစား Browser Client ဖြစ်တဲ့အတွက် Client ဘက်မှာ Source တွေက Open ဖြစ်နေတဲ့အတွက် ဘယ်လိုလုပ်လုပ် Secure မဖြစ်ပါဘူး။ POST မှာ MD5 နဲ့ encode လုပ်မယ်လို့ တွေ့တဲ့အတွက် အဲလိုလုပ်ရင် Secure ဖြစ်တယ် ယူဆကြမှာစိုးလို့ ဖြည့်ရေးသွားတာပါ။ နောက်ပြီးတော့ MD5 ဆိုတာက encode လို့မခေါ်ပါဘူး encode/decode ဆိုတာက အသွားအပြန်ရှိတယ် MD5 ကတော့ hash ပါ hash ဟာ အသွားအပြန်မရှိဘူး one way ပဲရတဲ့အတွက် သုံးရင်တောင် Password လို Data အတွက်ပဲ သုံးလို့ရမှာ ဒါတောင်မှ capture လုပ်လို့ရသွားခဲ့ရင် တဆင့်လောက် နည်းနည်းခက်ဖို့ပဲ သုံးလို့ရလိမ့်မယ်။ လက်ရှိ Technology အရဆိုရင် Secure တယ်လို့ ပြောလို့ရတာက HTTP ကို SSL ပေါ်က သုံးတဲ့အခြေအနေ တခုပဲရှိပါလိမ့်မယ်။

Sign In or Register to comment.