JavaRush /جاوا بلاگ /Random-SD /JAAS - ٽيڪنالاجي جو تعارف (حصو 1)

سطح

28 February 2021
35 views
0 comments

JAAS - ٽيڪنالاجي جو تعارف (حصو 1)

رسائي سيڪيورٽي ڪافي عرصي کان جاوا ۾ لاڳو ڪئي وئي آهي ۽ هن سيڪيورٽي کي فراهم ڪرڻ لاءِ فن تعمير کي JAAS - Java Authentication and Authorization Service سڏيو ويندو آهي. هي جائزو ان راز کي ختم ڪرڻ جي ڪوشش ڪندو ته تصديق، اختيار ڇا آهي ۽ JAAS کي ان سان ڇا ڪرڻو آهي. ڪيئن JAAS Servlet API سان دوست آهي، ۽ انهن جي رشتي ۾ ڪٿي مسئلا آهن.

تعارف

هن جائزي ۾ آئون اهڙي موضوع تي بحث ڪرڻ چاهيندس جيئن ويب ايپليڪيشن سيڪيورٽي. جاوا وٽ ڪيترائي ٽيڪنالاجيون آھن جيڪي سيڪيورٽي مهيا ڪن ٿيون:

" جاوا SE پليٽ فارم سيڪيورٽي آرڪيٽيڪچر "، جنهن بابت وڌيڪ تفصيل پڙهي سگهجي ٿو Oracle کان گائيڊ ۾: " جاوا ٽي ايم ايس پليٽ فارم سيڪيورٽي آرڪيٽيڪچر ". هي فن تعمير بيان ڪري ٿو ته اسان کي جاوا ايس اي رن ٽائم ماحول ۾ اسان جي جاوا ايپليڪيشنن کي ڪيئن محفوظ ڪرڻ جي ضرورت آهي. پر هي اسان جي اڄ جي گفتگو جو موضوع ناهي.
" جاوا ڪرپٽوگرافي آرڪيٽيڪچر " ھڪڙو جاوا ايڪسٽينشن آھي جيڪو بيان ڪري ٿو ڊيٽا انڪرپشن. توھان وڌيڪ پڙھي سگھوٿا JavaRush تي ھن توسيع جي باري ۾ جائزو " جاوا ڪرپٽوگرافي آرڪيٽيڪچر: پھريون واقفيت " يا Oracle جي گائيڊ ۾: " جاوا ڪرپٽوگرافي آرڪيٽيڪچر (JCA) ريفرنس گائيڊ ".

پر اڄ اسان جي گفتگو هڪ ٻي ٽيڪنالاجي بابت هوندي، جنهن کي ”جاوا آٿنٽيڪيشن اينڊ اٿارائزيشن سروس (JAAS)“ چيو ويندو آهي. اها هوءَ آهي جيڪا اهڙين اهم شين کي بيان ڪري ٿي جيئن تصديق ۽ اختيار. اچو ته هن کي وڌيڪ تفصيل سان ڏسو.

JAAS

JAAS جاوا SE لاءِ هڪ واڌارو آهي ۽ جاوا آٿنٽيڪيشن اينڊ اٿارائزيشن سروس (JAAS) ريفرنس گائيڊ ۾ بيان ڪيل آهي . جيئن ته ٽيڪنالاجي جو نالو مشورو ڏئي ٿو، JAAS بيان ڪري ٿو ته ڪيئن تصديق ۽ اختيار ڪرڻ گهرجي:

" تصديق ": يوناني مان ترجمو ٿيل، "authentikos" جو مطلب آهي "حقيقي، حقيقي". اهو آهي، تصديق صداقت جو امتحان آهي. جيڪو به تصديق ڪري رهيو آهي اهو ئي آهي جيڪو اهي چون ٿا ته اهي آهن.
" اجازت ": انگريزيءَ مان ترجمو ٿيل مطلب آهي "اجازت". اھو آھي، اختيار آھي رسائي ڪنٽرول ڪامياب تصديق کان پوء انجام ڏنو ويو آھي.

اهو آهي، JAAS اهو طئي ڪرڻ بابت آهي جيڪو ڪنهن وسيلن تائين رسائي جي درخواست ڪري رهيو آهي ۽ اهو فيصلو ڪري ٿو ته ڇا هو هن رسائي حاصل ڪري سگهي ٿو. زندگي مان هڪ ننڍڙو قياس: توهان روڊ تي ڊرائيونگ ڪري رهيا آهيو ۽ هڪ انسپيڪٽر توهان کي روڪي ٿو. مھرباني ڪري دستاويز مهيا ڪريو - تصديق. ڇا توهان دستاويزن سان ڪار هلائي سگهو ٿا - اختيار. يا، مثال طور، توهان هڪ دڪان ۾ شراب خريد ڪرڻ چاهيو ٿا. پهرين، توهان کي پاسپورٽ لاء چيو ويندو آهي - تصديق. اڳيون، توهان جي عمر جي بنياد تي، اهو فيصلو ڪيو ويو آهي ته ڇا توهان شراب خريد ڪرڻ جا اهل آهيو. هي اختيار آهي. ويب ايپليڪيشنن ۾، صارف جي طور تي لاگ ان ٿيڻ (يوزرنيم ۽ پاسورڊ داخل ڪرڻ) جي تصديق آهي. ۽ اهو طئي ڪرڻ ته توهان ڪهڙا صفحا کولي سگهو ٿا اختيار جي طرفان طئي ٿيل آهي. اهو آهي جتي "جاوا تصديق ۽ اختيار ڪرڻ جي خدمت (JAAS)" اسان جي مدد ڪري ٿي. جڏهن JAAS تي غور ڪيو وڃي، اهو ضروري آهي ته ڪيترن ئي اهم تصورن کي سمجهڻ لاء جيڪي JAAS بيان ڪري ٿو: مضمون، پرنسپل، سند. مضمون جي تصديق جو موضوع آهي. يعني اهو حقدار يا مالڪ آهي. دستاويزن ۾، مضمون کي ڪجهه عمل ڪرڻ جي درخواست جو ذريعو بيان ڪيو ويو آهي. مضمون يا ماخذ ڪنهن نه ڪنهن طرح بيان ڪيو وڃي ٿو ۽ ان مقصد لاءِ پرنسپل استعمال ڪيو ويندو آهي، جنهن کي روسي ۾ ڪڏهن ڪڏهن پرنسپال به چيو ويندو آهي. اهو آهي، هر پرنسپل هڪ خاص نقطي نظر کان هڪ مضمون جي نمائندگي آهي. ان کي واضح ڪرڻ لاء، اچو ته هڪ مثال ڏيو: هڪ خاص شخص هڪ مضمون آهي. ۽ هيٺيان ڪم ڪري سگھن ٿا پرنسپل طور:

سندس ڊرائيور جو لائسنس هڪ شخص جي نمائندگي جي طور تي هڪ روڊ استعمال ڪندڙ جي طور تي
سندس پاسپورٽ، سندس ملڪ جي شهري جي حيثيت ۾ هڪ شخص جي نمائندگي جي طور تي
سندس پرڏيهي پاسپورٽ، بين الاقوامي لاڳاپن ۾ هڪ شرڪت جي طور تي هڪ شخص جي نمائندگي جي طور تي
لائبريري ۾ سندس لائبريري ڪارڊ، هڪ شخص جي نمائندگي جي طور تي لائبريري سان ڳنڍيل هڪ پڙهندڙ جي طور تي

ان کان علاوه، مضمون جو هڪ سيٽ آهي "Credential"، جنهن جو مطلب آهي "شناخت" انگريزي ۾. هي ڪيئن مضمون تصديق ڪري ٿو ته هو هو آهي. مثال طور، صارف جو پاسورڊ ٿي سگهي ٿو سند. يا ڪو به اعتراض جنهن سان استعمال ڪندڙ تصديق ڪري سگهي ٿو ته هو واقعي هو آهي. اچو ته ھاڻي ڏسون ڪيئن JAAS ويب ايپليڪيشنن ۾ استعمال ٿيندو آھي.

ويب ايپليڪيشن

تنهن ڪري، اسان کي هڪ ويب ايپليڪيشن جي ضرورت آهي. Gradle خودڪار منصوبي جي تعمير سسٽم اسان کي ان کي ٺاهڻ ۾ مدد ڪندي. Gradle جي استعمال جي مهرباني، اسان ڪري سگهون ٿا، ننڍڙن حڪمن تي عمل ڪندي، هڪ جاوا پروجيڪٽ گڏ ڪري سگهون ٿا فارميٽ ۾ جنهن جي اسان کي ضرورت آهي، خود بخود ضروري ڊاريڪٽري ڍانچي ٺاهي، ۽ گهڻو ڪجهه. توھان وڌيڪ پڙھي سگھو ٿا Gradle بابت مختصر جائزو ۾: " A Brief Introduction to Gradle " يا سرڪاري دستاويزن ۾ " Gradle Getting Start ". اسان کي پروجيڪٽ جي شروعات ڪرڻ جي ضرورت آهي (ابتدائي ڪرڻ)، ۽ ان مقصد لاءِ Gradle وٽ هڪ خاص پلگ ان آهي: “ Gradle Init Plugin ” (Init شروعات لاءِ مختصر آهي، ياد رکڻ ۾ آسان). ھن پلگ ان کي استعمال ڪرڻ لاء، ڪمانڊ لائن تي حڪم ھلايو:

gradle init --type java-application

ڪامياب مڪمل ٿيڻ کان پوء، اسان وٽ هڪ جاوا پروجيڪٽ هوندو. اچو ته ھاڻي کوليون اسان جي پروجيڪٽ جي بلڊ اسڪرپٽ ايڊيٽنگ لاءِ. هڪ بلڊ اسڪرپٽ هڪ فائل آهي جنهن کي سڏيو ويندو آهي build.gradle، جيڪو ايپليڪيشن جي تعمير جي نونسن کي بيان ڪري ٿو. ان ڪري نالو، لکت ٺاھيو. اسان چئي سگهون ٿا ته هي هڪ پروجيڪٽ تعمير اسڪرپٽ آهي. Gradle ھڪڙو ورھايل اوزار آھي، جنھن جي بنيادي صلاحيتون پلگ ان سان وڌايو ويو آھي. تنهن ڪري، سڀ کان پهريان، اچو ته "پلگ ان" بلاڪ تي ڌيان ڏيو:

plugins {
    id 'java'
    id 'application'
}

ڊفالٽ طور، Gradle، جيڪو اسان بيان ڪيو آهي ان جي مطابق " --type java-application"، ڪجهه بنيادي پلگ انز جو هڪ سيٽ قائم ڪيو آهي، يعني اهي پلگ ان جيڪي پاڻ Gradle جي تقسيم ۾ شامل آهن. جيڪڏهن توهان gradle.org ويب سائيٽ تي "Docs" (يعني، دستاويزن) سيڪشن تي وڃو، پوء "حوالو" سيڪشن ۾ عنوانن جي فهرست ۾ کاٻي پاسي اسان کي " ڪور پلگ ان " سيڪشن، يعني. سيڪشن انهن تمام بنيادي پلگ ان جي وضاحت سان. اچو ته چونڊون بلڪل اهي پلگ ان جيڪي اسان کي گهربل آهن، ۽ نه اهي جيڪي Gradle اسان لاءِ ٺاهيا آهن. دستاويزن جي مطابق، " Gradle Java پلگ ان " جاوا ڪوڊ سان گڏ بنيادي آپريشن مهيا ڪري ٿي، جيئن ته ماخذ ڪوڊ گڏ ڪرڻ. پڻ، دستاويزن جي مطابق، " گريڊل ايپليڪيشن پلگ ان " اسان کي "قابل عمل JVM ايپليڪيشن" سان ڪم ڪرڻ لاء اوزار فراهم ڪري ٿو، يعني. هڪ جاوا ايپليڪيشن سان جيڪو هڪ اسٽينڊل ايپليڪيشن طور شروع ڪري سگهجي ٿو (مثال طور، هڪ ڪنسول ايپليڪيشن يا پنهنجي UI سان ايپليڪيشن). اهو ظاهر ٿئي ٿو ته اسان کي "ايپليڪيشن" پلگ ان جي ضرورت ناهي، ڇاڪاڻ ته ... اسان کي اسٽينڊ اڪيلو ايپ جي ضرورت ناهي، اسان کي ويب ايپ جي ضرورت آهي. اچو ته ان کي ختم ڪريون. انهي سان گڏ "mainClassName" سيٽنگ، جيڪا صرف هن پلگ ان کي ڄاڻايل آهي. وڌيڪ، ساڳئي " پيڪيجنگ ۽ تقسيم " سيڪشن ۾ جتي ايپليڪيشن پلگ ان دستاويزن جي لنڪ مهيا ڪئي وئي هئي، اتي هڪ لنڪ آهي Gradle War پلگ ان. Gradle War پلگ ان ، جيئن بيان ڪيل دستاويز ۾، مدد مهيا ڪري ٿي جاوا ويب ايپليڪيشن ٺاهڻ لاءِ جنگ جي فارميٽ ۾. WAR فارميٽ ۾ مطلب ته هڪ JAR آرڪائيو جي بدران، هڪ WAR آرڪائيو ٺاهي ويندي. اهو لڳي ٿو ته اهو ئي آهي جيڪو اسان کي گهرجي. پڻ، جيئن دستاويز چوي ٿو، "جنگ پلگ ان جاوا پلگ ان کي وڌايو". اھو آھي، اسان جاوا پلگ ان کي جنگ جي پلگ ان سان تبديل ڪري سگھون ٿا. تنهن ڪري، اسان جو پلگ ان بلاڪ آخرڪار هن طرح نظر ايندو:

plugins {
    id 'war'
}

"Gradle War پلگ ان" جي دستاويز ۾ پڻ چيو ويو آهي ته پلگ ان هڪ اضافي "پروجيڪٽ لي آئوٽ" استعمال ڪري ٿو. Layout انگريزيءَ مان ترجمو ڪيو ويو آھي جڳھ جي طور تي. اهو آهي، ڊفالٽ طرفان جنگ پلگ ان فائلن جي هڪ خاص جڳهه جي وجود جي توقع رکي ٿي جيڪا اها پنهنجي ڪمن لاءِ استعمال ڪندي. اهو ويب ايپليڪيشن فائلن کي ذخيرو ڪرڻ لاءِ هيٺ ڏنل ڊاريڪٽري استعمال ڪندو: src/main/webapp پلگ ان جو رويو هن ريت بيان ڪيو ويو آهي:

اھو آھي، پلگ ان ھن جڳھ کان اڪائونٽ فائلن ۾ وٺي ويندي جڏھن اسان جي ويب ايپليڪيشن جي WAR آرڪائيو ٺاھيو. ان کان علاوه، Gradle War پلگ ان دستاويزن جو چوڻ آهي ته هي ڊاريڪٽري "آرڪائيو جي جڙ" هوندي. ۽ اڳ ۾ ئي ان ۾ اسان هڪ WEB-INF ڊاريڪٽري ٺاهي سگهون ٿا ۽ اتي web.xml فائل شامل ڪري سگهون ٿا. هي ڪهڙي قسم جي فائل آهي؟ web.xml- هي هڪ "تعميراتي بيان ڪندڙ" يا "تعميراتي بيان ڪندڙ" آهي. ھي ھڪڙي فائل آھي جيڪا بيان ڪري ٿي ته اسان جي ويب ايپليڪيشن کي ڪم ڪرڻ لاء ڪيئن ترتيب ڏيو. هي فائل بيان ڪري ٿي ته ڪهڙيون درخواستون اسان جي ايپليڪيشن سنڀالينديون، سيڪيورٽي سيٽنگون، ۽ گهڻو ڪجهه. ان جي بنيادي طور تي، اهو ڪجهه حد تائين هڪ JAR فائل مان ظاهر ڪيل فائل سان ملندڙ جلندڙ آهي (ڏسو " منفيسٽ فائلن سان ڪم ڪرڻ: بنياديات "). Manifest فائل ٻڌائي ٿي ته جاوا ايپليڪيشن سان ڪيئن ڪم ڪجي (يعني هڪ JAR آرڪائيو)، ۽ web.xml ٻڌائي ٿو ته ڪيئن ڪم ڪجي جاوا ويب ايپليڪيشن (يعني WAR آرڪائيو) سان. "تعميراتي بيان ڪندڙ" جو بلڪل تصور پاڻ تي پيدا نه ٿيو، پر دستاويز ۾ بيان ڪيو ويو آهي " Servlet API Specification"". ڪا به جاوا ويب ايپليڪيشن هن "Servlet API" تي منحصر آهي. اهو سمجهڻ ضروري آهي ته هي هڪ API آهي - اهو آهي، اهو ڪجهه رابطي واري معاهدي جي وضاحت آهي. ويب ايپليڪيشنون آزاد ايپليڪيشنون نه آهن. اهي ويب سرور تي هلن ٿيون. ، جيڪو صارفين سان نيٽ ورڪ ڪميونيڪيشن مهيا ڪري ٿو. يعني ويب سرور ويب ايپليڪيشنن لاءِ هڪ قسم جو ”ڪنٽينر“ آهي. اهو منطقي آهي، ڇاڪاڻ ته اسان ويب ايپليڪيشن جي منطق کي لکڻ چاهيون ٿا، يعني صارف ڪهڙا صفحا ڏسندا ۽ ڪيئن. انهن کي صارف جي عملن تي رد عمل ڏيڻ گهرجي. ۽ اسان اهو ڪوڊ لکڻ نٿا چاهيون ته صارف کي ڪيئن پيغام موڪليو ويندو، معلومات جا بائيٽ ڪيئن منتقل ڪيا ويندا ۽ ٻيون گهٽ-سطح ۽ تمام گهڻي معيار جون شيون. ان کان علاوه، اهو ظاهر ٿيو ته ويب ايپليڪيشنون سڀ مختلف آهن، پر ڊيٽا جي منتقلي ساڳي آهي. يعني، هڪ ملين پروگرامرن کي هڪ ئي مقصد لاء ڪوڊ بار بار لکڻو پوندو. تنهنڪري ويب سرور ڪجهه صارف جي رابطي لاء ذميوار آهي. ۽ ڊيٽا جي مٽاسٽا، ۽ ويب ايپليڪيشن ۽ ڊولپر ان ڊيٽا کي پيدا ڪرڻ جا ذميوار آهن. ۽ انهن ٻن حصن کي ڳنڍڻ لاء، i.e. ويب سرور ۽ ويب ايپليڪيشن، توهان کي انهن جي رابطي لاء هڪ معاهدي جي ضرورت آهي، يعني. ان لاءِ اهي ڪهڙا قاعدا پيروي ڪندا؟ ڪنهن به طرح معاهدي کي بيان ڪرڻ لاء، ويب ايپليڪيشن ۽ ويب سرور جي وچ ۾ رابطي کي ڇا ڏسڻ گهرجي، Servlet API ايجاد ڪئي وئي هئي. دلچسپ ڳالهه اها آهي ته، جيتوڻيڪ جيڪڏهن توهان اسپرنگ وانگر فريم ورڪ استعمال ڪندا آهيو، اتي اڃا تائين هڪ سرورٽ API آهي هود هيٺ. اھو آھي، توھان استعمال ڪريو بهار، ۽ بهار توھان لاءِ Servlet API سان ڪم ڪري ٿو. اهو ظاهر ٿئي ٿو ته اسان جي ويب ايپليڪيشن پروجيڪٽ تي منحصر هجڻ گهرجي Servlet API. انهي صورت ۾، Servlet API هڪ انحصار هوندو. جيئن اسان ڄاڻون ٿا، Gradle پڻ توهان کي منصوبي جي انحصار کي بيان ڪرڻ جي اجازت ڏئي ٿو بياناتي انداز ۾. پلگ ان بيان ڪري ٿو ته انحصار کي ڪيئن منظم ڪري سگهجي ٿو. مثال طور، Java Gradle Plugin متعارف ڪرايو "testImplementation" انحصار انتظام جو طريقو، جيڪو چوي ٿو ته اهڙي انحصار صرف ٽيسٽن لاءِ گهربل آهي. پر Gradle War پلگ ان هڪ انحصار انتظام جو طريقو شامل ڪري ٿو "providedCompile"، جنهن جو چوڻ آهي ته اهڙي انحصار اسان جي ويب ايپليڪيشن جي WAR آرڪائيو ۾ شامل نه ڪئي ويندي. اسان پنهنجي WAR آرڪائيو ۾ Servlet API کي ڇو نه شامل ڪريون؟ ڇو ته Servlet API اسان جي ويب ايپليڪيشن کي مهيا ڪئي ويندي ويب سرور طرفان. جيڪڏهن هڪ ويب سرور مهيا ڪري ٿو هڪ Servlet API، پوء سرور کي سڏيو ويندو آهي servlet ڪنٽينر. تنهن ڪري، اها ويب سرور جي ذميواري آهي ته اسان کي Servlet API مهيا ڪري، ۽ اها اسان جي ذميواري آهي ته ServletAPI صرف ان وقت مهيا ڪريون جڏهن ڪوڊ مرتب ڪيو وڃي. هن ڪري providedCompile. اهڙيء طرح، انحصار بلاڪ هن طرح نظر ايندو:

dependencies {
    providedCompile 'javax.servlet:javax.servlet-api:3.1.0'
    testImplementation 'junit:junit:4.12'
}

سو، اچو ته واپس وڃون web.xml فائل. ڊفالٽ طور، Gradle ڪو به ٺاھڻ وارو بيان نه ٺاھيندو آھي، تنھنڪري اسان کي اھو پاڻ ڪرڻ گھرجي. اچو ته هڪ ڊاريڪٽري ٺاهي src/main/webapp/WEB-INF، ۽ ان ۾ اسان هڪ XML فائل ٺاهينداسين web.xml. ھاڻي اچو ته "Java Servlet Specification" پاڻ کي ۽ باب " CHAPTER 14 Deployment Descriptor " کي کوليون. جيئن بيان ڪيو ويو آهي "14.3 Deployment Descriptor"، Deployment Descriptor جي XML دستاويز کي اسڪيما طرفان بيان ڪيو ويو آهي http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd . هڪ XML اسڪيما بيان ڪري ٿو ته دستاويز ڪهڙن عنصرن تي مشتمل ٿي سگهي ٿو ۽ انهن کي ڪهڙي ترتيب ۾ ظاهر ٿيڻ گهرجي. ڪهڙا لازمي آهن ۽ ڪهڙا نه آهن. عام طور تي، اهو دستاويز جي جوڙجڪ کي بيان ڪري ٿو ۽ توهان کي چيڪ ڪرڻ جي اجازت ڏئي ٿو ته ڇا XML دستاويز صحيح طرح سان ٺهيل آهي. ھاڻي اچو ته باب " 14.5 مثالن " مان مثال استعمال ڪريون ، پر اسڪيم کي ورجن 3.1 لاءِ بيان ڪيو وڃي، يعني.

http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd

اسان جو خالي هڪ web.xmlهن طرح نظر ايندو:

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
         http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
         version="3.1">
    <display-name>JAAS Example</display-name>
</web-app>

اچو ته ھاڻي بيان ڪريون servlet جيڪو اسين JAAS استعمال ڪندي حفاظت ڪنداسين. اڳي، Gradle پيدا ڪيو ايپ ڪلاس اسان لاءِ. اچو ته ان کي هڪ سروليٽ ۾ تبديل ڪريو. جيئن ته وضاحت ۾ بيان ڪيو ويو آهي " باب 2 The Servlet انٽرفيس "، ته " اڪثر مقصدن لاءِ، ڊولپرز HttpServlet کي وڌائيندا انهن جي سرورليٽ کي لاڳو ڪرڻ لاءِ "، يعني ڪنهن طبقي کي سرورليٽ بنائڻ لاءِ، توهان کي هن طبقي کي ورثي ۾ آڻڻو پوندو HttpServlet:

public class App extends HttpServlet {
	public String getGreeting() {
        return "Secret!";
    }
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        response.getWriter().print(getGreeting());
    }
}

جيئن اسان چيو، Servlet API سرور ۽ اسان جي ويب ايپليڪيشن جي وچ ۾ هڪ معاهدو آهي. اهو معاهدو اسان کي بيان ڪرڻ جي اجازت ڏئي ٿو ته جڏهن صارف سرور سان رابطو ڪري ٿو، سرور صارف کان هڪ اعتراض جي صورت ۾ هڪ درخواست ٺاهي HttpServletRequest۽ ان کي سرورٽ ڏانهن منتقل ڪندو. اهو به هڪ اعتراض سان servlet مهيا ڪندو HttpServletResponseته جيئن servlet ان کي استعمال ڪندڙ لاء هڪ جواب لکي سگهي ٿو. هڪ دفعو servlet ختم ٿيڻ بعد، سرور صارف کي ان جي بنياد تي جواب ڏيڻ جي قابل هوندو HttpServletResponse. اهو آهي، servlet سڌو سنئون صارف سان رابطو نٿو ڪري، پر صرف سرور سان. سرور کي ڄاڻڻ لاءِ ته اسان وٽ هڪ servlet آهي ۽ ڪهڙن درخواستن لاءِ ان کي استعمال ڪرڻ جي ضرورت آهي، اسان کي ضرورت آهي سرور کي ان بابت ٻڌائڻ واري بيان ۾:

<servlet>
	<servlet-name>app</servlet-name>
	<servlet-class>jaas.App</servlet-class>
</servlet>
<servlet-mapping>
	<servlet-name>app</servlet-name>
	<url-pattern>/secret</url-pattern>
</servlet-mapping>

انهي صورت ۾، سڀني درخواستن کي /secretخطاب نه ڪيو ويندو اسان جي هڪ سرورٽ جي نالي سان app، جيڪو طبقي سان ملندو آهي jaas.App. جيئن اسان اڳ ۾ چيو آهي، هڪ ويب ايپليڪيشن صرف ويب سرور تي ترتيب ڏئي سگهجي ٿي. ويب سرور الڳ الڳ انسٽال ڪري سگھجي ٿو (اسٽالون). پر هن جائزي جي مقصدن لاء، هڪ متبادل اختيار مناسب آهي - هڪ ايمبيڊڊ سرور تي هلندڙ. هن جو مطلب اهو آهي ته سرور ٺاهيو ويندو ۽ پروگرام سان شروع ڪيو ويندو (پلگ ان اسان لاء اهو ڪندو)، ۽ ساڳئي وقت اسان جي ويب ايپليڪيشن ان تي ترتيب ڏني ويندي. Gradle بلڊ سسٽم توهان کي انهن مقصدن لاءِ " Gradle Gretty Plugin " پلگ ان استعمال ڪرڻ جي اجازت ڏئي ٿو:

plugins {
    id 'war'
    id 'org.gretty' version '2.2.0'
}

اضافي طور تي، گريٽي پلگ ان وٽ سٺو دستاويز آهي . اچو ته حقيقت سان شروع ڪريون ته گريٽي پلگ ان توهان کي مختلف ويب سرورز جي وچ ۾ سوئچ ڪرڻ جي اجازت ڏئي ٿي. اهو دستاويز ۾ وڌيڪ تفصيل سان بيان ڪيو ويو آهي: " سروليٽ ڪنٽينرز جي وچ ۾ مٽائڻ ". اچو ته تبديل ڪريون Tomcat، ڇاڪاڻ ته ... اهو استعمال ۾ سڀ کان وڌيڪ مشهور آهي، ۽ پڻ سٺو دستاويز آهي ۽ ڪيترائي مثال ۽ تجزياتي مسئلا آهن:

gretty {
    // Переключаемся с дефолтного Jetty на Tomcat
    servletContainer = 'tomcat8'
    // Укажем Context Path, он же Context Root
    contextPath = '/jaas'
}

ھاڻي اسان "gradle appRun" کي هلائي سگھون ٿا ۽ پوء اسان جي ويب ايپليڪيشن دستياب ٿي ويندي http://localhost:8080/jaas/secret

اهو چيڪ ڪرڻ ضروري آهي ته servlet ڪنٽينر Tomcat طرفان چونڊيو ويو آهي (ڏسو #1) ۽ چيڪ ڪريو ته ڪهڙي پتي تي اسان جي ويب ايپليڪيشن موجود آهي (ڏسو #2).

تصديق

تصديق جي سيٽنگون اڪثر ڪري ٻن حصن تي مشتمل هونديون آهن: سيٽنگون سرور جي پاسي ۽ سيٽنگون ويب ايپليڪيشن جي پاسي تي جيڪي هن سرور تي هلن ٿيون. ويب ايپليڪيشن جي سيڪيورٽي سيٽنگون ويب سرور جي سيڪيورٽي سيٽنگن سان رابطو نه ڪري سگھن ٿيون، جيڪڏهن انهي کان سواء ٻيو ڪو سبب ناهي ته ويب ايپليڪيشن ويب سرور سان رابطو نه ڪري سگهي. اهو بيڪار نه هو ته اسان Tomcat ڏانهن تبديل ڪيو، ڇاڪاڻ ته ... Tomcat هڪ چڱي طرح بيان ڪيل فن تعمير آهي (ڏسو " Apache Tomcat 8 آرڪيٽيڪچر "). هن فن تعمير جي وضاحت مان اهو واضح ٿئي ٿو ته Tomcat، هڪ ويب سرور جي طور تي، ويب ايپليڪيشن کي هڪ خاص حوالي سان نمائندگي ڪري ٿو، جنهن کي سڏيو ويندو آهي " Tomcat Context ". هي حوالو هر ويب ايپليڪيشن کي پنهنجي سيٽنگن جي اجازت ڏئي ٿو، ٻين ويب ايپليڪيشنن کان الڳ. اضافي طور تي، ويب ايپليڪيشن هن سلسلي جي سيٽنگن تي اثر انداز ڪري سگهي ٿي. لچڪدار ۽ آسان. وڌيڪ سمجھڻ لاءِ، اسان مضمون پڙھڻ جي صلاح ڏيون ٿا ” سمجھڻ Tomcat Context Containers “ ۽ Tomcat دستاويزي سيڪشن ” The Context Container “. جيئن مٿي بيان ڪيو ويو آهي، اسان جي ويب ايپليڪيشن اسان جي ايپليڪيشن جي Tomcat Context تي اثر انداز ڪري سگهي ٿي /META-INF/context.xml. ۽ هڪ تمام اهم سيٽنگون جنهن تي اسان اثرانداز ٿي سگهون ٿا سيڪيورٽي ريمز. سيڪيورٽي ريمز هڪ قسم جو "سيڪيورٽي علائقو" آهي. ھڪڙو علائقو جنھن لاء مخصوص سيڪيورٽي سيٽنگون بيان ڪيون ويون آھن. ان جي مطابق، جڏهن سيڪيورٽي ريم استعمال ڪريون ٿا، اسان لاڳو ڪريون ٿا حفاظتي سيٽنگون جيڪي بيان ڪيون ويون آهن هن دائري لاءِ. سيڪيورٽي جا علائقا هڪ ڪنٽينر جي ذريعي منظم ڪيا ويا آهن، يعني. ويب سرور، نه اسان جي ويب ايپليڪيشن. اسان صرف سرور کي ٻڌائي سگھون ٿا ته اسان جي ايپليڪيشن کي ڪهڙي حفاظتي دائري کي وڌائڻ جي ضرورت آهي. Tomcat دستاويزي سيڪشن ۾ " The Realm Component " هڪ ريئم کي بيان ڪري ٿو ڊيٽا جي مجموعن جي طور تي صارفين ۽ انهن جي ڪردار جي تصديق ڪرڻ لاءِ. Tomcat مهيا ڪري ٿو مختلف حفاظتي دائري جي عملن جو هڪ سيٽ، جن مان هڪ آهي " جاس ريم ". ٿوري اصطلاح کي سمجھڻ کان پوء، اچو ته فائل ۾ Tomcat Context کي بيان ڪريون /META-INF/context.xml:

<?xml version="1.0" encoding="UTF-8"?>
<Context>
    <Realm className="org.apache.catalina.realm.JAASRealm"
           appName="JaasLogin"
           userClassNames="jaas.login.UserPrincipal"
           roleClassNames="jaas.login.RolePrincipal"
           configFile="jaas.config" />
</Context>

appName- ايپليڪيشن جو نالو. Tomcat ڪوشش ڪندو ھن نالو کي ملائڻ جي نالن سان configFile. configFile- ھي آھي "لاگ ان ڪنفيگريشن فائل". ان جو هڪ مثال JAAS دستاويزن ۾ ڏسي سگھجي ٿو: " ضميمو B: مثال لاگ ان ترتيبون ". ان کان علاوه، اهو ضروري آهي ته هي فائل پهرين وسيلن ۾ ڳولي ويندي. تنهن ڪري، اسان جي ويب ايپليڪيشن هن فائل کي پاڻ مهيا ڪري سگهي ٿي. خاصيتون userClassNames۽ roleClassNamesانهن طبقن جو هڪ اشارو شامل آهي جيڪي صارف جي پرنسپل جي نمائندگي ڪن ٿا. JAAS ٻن مختلف تصورن وانگر "صارف" ۽ "ڪردار" جي تصورن کي الڳ ڪري ٿو java.security.Principal. اچو ته مٿين طبقن کي بيان ڪريون. اچو ته يوزر پرنسپل لاءِ آسان ترين عمل ٺاھيون:

public class UserPrincipal implements Principal {
    private String name;
    public UserPrincipal(String name) {
        this.name = name;
    }
    @Override
    public String getName() {
        return name;
    }
}

اسان ورجائينداسين بلڪل ساڳي عمل لاءِ RolePrincipal. جئين توهان انٽرفيس مان ڏسي سگهو ٿا، پرنسپل لاءِ بنيادي شيءِ ذخيرو ڪرڻ ۽ واپس ڪرڻ آهي ڪجهه نالو (يا ID) جيڪو پرنسپل جي نمائندگي ڪري ٿو. هاڻي، اسان وٽ هڪ سيڪيورٽي ريم آهي، اسان وٽ پرنسپل ڪلاس آهن. اهو فائل کي ڀرڻ لاءِ رهي ٿو " configFile" وصف مان، عرف login configuration file. ان جو تفصيل Tomcat دستاويزن ۾ ملي سگهي ٿو: " The Realm Component ".

اھو آھي، اسان پنھنجي ويب ايپليڪيشن جي وسيلن ۾ JAAS Login Config سيٽنگ رکي سگھون ٿا ۽ Tomcat Context جي مھرباني ڪري اسان ان کي استعمال ڪرڻ جي قابل ٿي وينداسين. هي فائل لازمي طور تي موجود هجڻ گهرجي ClassLoader لاءِ وسيلن جي طور تي، تنهنڪري ان جو رستو هن طرح هجڻ گهرجي: \src\main\resources\jaas.config اچو ته هن فائل جي مواد کي ترتيب ڏيو:

JaasLogin {
    jaas.login.JaasLoginModule required debug=true;
};

اها ڳالهه نوٽ ڪرڻ جي قابل آهي ته context.xmlساڳيو نالو هتي ۽ ۾ استعمال ڪيو ويندو آهي. هي نقشو حفاظتي دائري کي لاگ ان موڊيول ڏانهن وٺي ٿو. تنهن ڪري، Tomcat Context اسان کي ٻڌايو ته ڪهڙا ڪلاس پرنسپل جي نمائندگي ڪن ٿا، انهي سان گڏ ڪهڙن LoginModule کي استعمال ڪرڻ لاء. اسان کي اهو ڪرڻو آهي ته هن LoginModule تي عمل ڪيو وڃي. LoginModule شايد JAAS ۾ سڀ کان وڌيڪ دلچسپ شين مان هڪ آهي. سرڪاري دستاويز اسان جي مدد ڪندا LoginModule: " Java Authentication and Authorization Service (JAAS): LoginModule ڊولپرز گائيڊ ". اچو ته لاگ ان ماڊل کي لاڳو ڪريو. اچو ته هڪ ڪلاس ٺاهيو جيڪو انٽرفيس کي لاڳو ڪري ٿو LoginModule:

public class JaasLoginModule implements LoginModule {
}

پهرين اسان بيان ڪريون ٿا شروعات جو طريقو LoginModule:

private CallbackHandler handler;
private Subject subject;
@Override
public void initialize(Subject subject, CallbackHandler callbackHandler, <String, ?> sharedState, Map<String, ?> options) {
	handler = callbackHandler;
	this.subject = subject;
}

اهو طريقو محفوظ ڪندو Subject، جنهن کي اسين وڌيڪ تصديق ڪنداسين ۽ پرنسپل جي معلومات سان ڀرينداسين. اسان مستقبل جي استعمال لاءِ به بچت ڪنداسين CallbackHandler، جيڪو اسان کي ڏنو ويو آهي. مدد سان، CallbackHandlerاسان ٿوري دير بعد تصديق جي موضوع بابت مختلف معلومات جي درخواست ڪري سگھون ٿا. توھان ان بابت وڌيڪ پڙھي سگھوٿا CallbackHandlerدستاويز جي لاڳاپيل حصي ۾: " JAAS ريفرنس گائيڊ: CallbackHandler ". loginاڳيون، تصديق جو طريقو جاري ڪيو ويو آهي Subject. هي تصديق جو پهريون مرحلو آهي:

@Override
public boolean login() throws LoginException {
	// Добавляем колбэки
	Callback[] callbacks = new Callback[2];
	callbacks[0] = new NameCallback("login");
	callbacks[1] = new PasswordCallback("password", true);
	// При помощи колбэков получаем через CallbackHandler логин и пароль
	try {
		handler.handle(callbacks);
		String name = ((NameCallback) callbacks[0]).getName();
		String password = String.valueOf(((PasswordCallback) callbacks[1]).getPassword());
		// Далее выполняем валидацию.
		// Тут просто для примера проверяем определённые значения
		if (name != null && name.equals("user123") && password != null && password.equals("pass123")) {
			// Сохраняем информацию, которая будет использована в методе commit
			// Не "пачкаем" Subject, т.к. не факт, что commit выполнится
			// Для примера проставим группы вручную, "хардcodeно".
			login = name;
			userGroups = new ArrayList<String>();
			userGroups.add("admin");
			return true;
		} else {
			throw new LoginException("Authentication failed");
		}
	} catch (IOException | UnsupportedCallbackException e) {
		throw new LoginException(e.getMessage());
	}
}

اهو ضروري آهي ته loginاسان کي تبديل نه ڪرڻ گهرجي Subject. اهڙيون تبديليون صرف تصديق واري طريقي ۾ ٿيڻ گهرجن commit. اڳيون، اسان کي ڪامياب تصديق جي تصديق ڪرڻ جو طريقو بيان ڪرڻ گهرجي:

@Override
public boolean commit() throws LoginException {
	userPrincipal = new UserPrincipal(login);
	subject.getPrincipals().add(userPrincipal);
	if (userGroups != null && userGroups.size() > 0) {
		for (String groupName : userGroups) {
			rolePrincipal = new RolePrincipal(groupName);
			subject.getPrincipals().add(rolePrincipal);
		}
	}
	return true;
}

اهو شايد عجيب لڳي سگھي ٿو ته طريقي کي الڳ ڪرڻ login۽ commit. پر نقطو اهو آهي ته لاگ ان ماڊلز کي گڏ ڪري سگهجي ٿو. ۽ ڪامياب تصديق لاءِ ضروري ٿي سگھي ٿو ڪيترن ئي لاگ ان ماڊلز کي ڪاميابيءَ سان ڪم ڪرڻ لاءِ. ۽ صرف جيڪڏهن سڀئي ضروري ماڊل ڪم ڪيا آهن، پوء تبديلين کي بچايو. هي تصديق جو ٻيو مرحلو آهي. اچو ته ختم ڪريون abort۽ طريقن سان logout:

@Override
public boolean abort() throws LoginException {
	return false;
}
@Override
public boolean logout() throws LoginException {
	subject.getPrincipals().remove(userPrincipal);
	subject.getPrincipals().remove(rolePrincipal);
	return true;
}

اهو طريقو abortسڏيو ويندو آهي جڏهن تصديق جو پهريون مرحلو ناڪام ٿئي ٿو. اهو طريقو logoutسڏيو ويندو آهي جڏهن سسٽم لاگ آئوٽ ٿيندو. اسان کي لاڳو ڪرڻ Login Module۽ ان کي ترتيب ڏيڻ Security Realm، هاڻي اسان کي web.xmlحقيقت کي ظاهر ڪرڻ جي ضرورت آهي ته اسان هڪ مخصوص استعمال ڪرڻ چاهيون ٿا Login Config:

<login-config>
  <auth-method>BASIC</auth-method>
  <realm-name>JaasLogin</realm-name>
</login-config>

اسان پنھنجي سيڪيورٽي ريلي جو نالو بيان ڪيو ۽ تصديق جو طريقو بيان ڪيو - BASIC. ھي ھڪڙي قسم جي تصديق جي قسمن مان آھي جيڪو Servlet API ۾ سيڪشن " 13.6 تصديق " ۾ بيان ڪيو ويو آھي. رهيل ن

تبصرا

TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION