JWT آپ کی انٹرپرائز ایپ کو محفوظ بنانے کی کلید کیوں ہے - اور KumuluzEE آپ کا نیا بہترین دوست کیوں ہو سکتا ہے

آج کل، ہمیں کارکردگی کے بارے میں زیادہ سے زیادہ خدشات ہیں، اور ساتھ ہی، ہم یہ جاننا چاہتے ہیں کہ نظام کس طرح تیزی سے اور قابل اعتماد طریقے سے بات چیت کر سکتے ہیں۔ کئی بار ہم معلومات بھیجنا چاہتے ہیں اور اسے زیادہ سے زیادہ خفیہ اور محفوظ رکھنا چاہتے ہیں۔ حساس ڈیٹا کو بعض اوقات ویب کے ذریعے عوامی طور پر بھی جانا چاہیے اور تار کے دوسرے سرے پر کارروائیوں کو متحرک کرنا چاہیے۔ زیادہ تر، ہم ایسی حرکتیں پیدا کرنا چاہتے ہیں جو ڈیٹا کی تبدیلی کا سبب بنیں۔ ان معاملات میں، ہم نہ صرف اپنے ڈیٹا کی حفاظت کو دیکھ رہے ہیں۔ ہم اس بات کو یقینی بنانا چاہتے ہیں کہ ہمارا ڈیٹا بھیجنے سے شروع ہونے والی کارروائیاں قابل اعتماد ہیں۔ ہم اپنے ڈیٹا کو کئی طریقوں سے محفوظ کر سکتے ہیں۔ عام طور پر، ہم ڈیٹا کو (ٹرانسپورٹ لیئر سیکیورٹی) محفوظ کنکشن کے ذریعے بھیجتے ہیں۔ یہ اس بات کو یقینی بنائے گا کہ ہمارا ڈیٹا تار کے ذریعے انکرپٹ ہو جائے۔ ہم سرٹیفکیٹس کا استعمال دو فریقوں کے درمیان اعتماد کے رشتے بنانے اور اسے حاصل کرنے کے لیے کرتے ہیں۔ اس مضمون میں، میں معیار پر بات کرنا چاہتا ہوں اور مزید دیکھنا چاہتا ہوں کہ ہم ایک مشترکہ ایپلی کیشن میں کیسے ضم کر سکتے ہیں۔ اس صورت میں، ہم پر ایک نظر ڈالیں گے .آئیے کچھ بنیادی تصورات پر ایک نظر ڈالتے ہیں۔ یا JSON ویب ٹوکن، یا اس سے بہتر، JavaScript آبجیکٹ نوٹیشن ویب ٹوکن، میں بیان کردہ ایک معیار ہے۔ یہ معیار، تمام (تبصروں کی درخواست) کے معیارات کی طرح، (انٹرنیٹ انجینئرنگ ٹاسک فورس) کے ذریعہ بیان کردہ، تحریری، اور شائع کیا گیا ہے۔ اس کی متعدد طریقوں سے تعریف کی جا سکتی ہے۔ عام طور پر، ہم کہہ سکتے ہیں کہ دو فریقوں کے درمیان دعووں کو منتقل کرنے کی ایک کمپیکٹ، محفوظ شکل ہے۔ دعویٰ کیا ہے اس کو آسان بنانے کا ایک طریقہ بنیادی طور پر اسے نام/قدر کے جوڑے کے طور پر بیان کرنا ہے جس میں معلومات شامل ہیں۔ ہمیں اپنے انٹرنیٹ مواصلات کے چند اہم پہلوؤں کی ضمانت کے لیے اس معلومات کی ضرورت ہے۔ ہمیں اس بات کو یقینی بنانے کی ضرورت ہے کہ ہمیں جو معلومات موصول ہوتی ہیں اس کی توثیق ہوتی ہے اور پہلی صورت میں اس پر بھروسہ کیا جاتا ہے۔ پھر ہمیں اس کی توثیق کرنے کی ضرورت ہے۔ یہ بنیادی طور پر ہے۔ اسپرنگ بوٹ کا بڑے پیمانے پر استعمال کیا جا رہا ہے۔ کئی بار اسے بعض تنظیموں جیسے بینکوں اور دیگر مالیاتی تنظیموں کے ملکیتی سافٹ ویئر میں دوسرے نام سے بھی لپیٹ دیا جاتا ہے۔ ہماری مثال کے لیے، میں نے کچھ مختلف کرنے کا فیصلہ کیا۔ اسپرنگ بوٹ کے بجائے، ہم کے ساتھ ایک مثال دیکھنے جا رہے ہیں۔ نقطہ یہ ہے کہ یہ شناخت کرنا ہے کہ کیا ہے اور یہ کیسا لگتا ہے۔ جاوا انٹرپرائز ایپلی کیشنز بنیادی طور پر ایپلی کیشنز ہیں جو کسی ایپلیکیشن سرور میں تعینات کی جا سکتی ہیں یا ایمبیڈڈ سرور کے استعمال کے ذریعے خود چلائی جا سکتی ہیں۔ مثال کے طور پر، اسپرنگ بوٹ ایپلی کیشنز ایمبیڈڈ ٹامکیٹ سرور پر چلتی ہیں۔ اس مضمون میں، ہماری توجہ پر رکھی جائے گی۔ اسپرنگ بوٹ کی طرح اس میں بھی ایمبیڈڈ سرور ہوتا ہے۔ سوائے اس کے کہ اس صورت میں اسے جیٹی کہا جاتا ہے۔ یہ CDI (Context Dependency Injection) فراہم کرنے کے لیے ویلڈ کے ساتھ استعمال کیا جاتا ہے۔ تمام Java اور ٹیکنالوجی کے معیارات اس کے ساتھ مطابقت رکھتے ہیں۔ TLS JWT JWT Enterprise KumuluzEE JWT RFC7519 RFC IETF JWT KumuluzEE JWT KumuluzEE EE Jakarta EE framework 2. کیس کی مثال مثال دینے کے لیے کہ اپنی بنیادی شکل میں کیسے کام کرتا ہے، مجھے اسے پیش کرنے کا طریقہ سوچنا پڑا۔ بہترین مثالیں جہاں سیکیورٹی ایک تشویش کا باعث ہے وہ بینک ہیں۔ تاہم، یہ بتانے کے لیے کہ کیسے کام کرتا ہے ایک پوری بینک درخواست بنانا وقت کا ضیاع ہوگا اور شاید بہت سارے تصورات اس میں شامل ہوں گے۔ اس کے بجائے، میں نے جو بنایا ہے وہ ایک بہت ہی آسان بینکنگ سسٹم ہے۔ ہماری بنیادی تشویش یہ بتانا ہے کہ ڈیٹا تار سے کیسے گزرتا ہے اور صارفین کو ہماری ایپلیکیشن کے مخصوص علاقوں تک کیسے رسائی حاصل ہوتی ہے۔ میں TLS پر بھی بات نہیں کروں گا یا ہم تار کے ذریعے خفیہ کردہ معلومات کیسے بھیج سکتے ہیں۔ ہم اپنی توجہ پر اس کی خالص ترین شکل میں رکھیں گے۔ ہمارا کیس ایک بینکنگ سسٹم ہے جسے فطرت اور ماحول کا دفاع کرنے والا گروپ استعمال کرتا ہے۔ یہ صرف یہ دکھانے کا ایک تفریحی طریقہ ہے کہ کیسے کام کرتا ہے۔ اس لیگ آف نیچر کا مرکزی کردار لوسی ہے جو میرے تمام مضامین میں ایک عام کردار بنتا جا رہا ہے۔ JWT JWT JWT JWT 3. فن تعمیر اس سے پہلے کہ ہم شروع کریں، آئیے صرف اپنی چل رہی ایپلیکیشن کا خاکہ بنائیں۔ یہ ایک بہت ہی آسان ایپلی کیشن ہے، لیکن پھر بھی اسے کھینچنا اچھی بات ہے: اس کی اتنی سادہ وجہ یہ ہے کہ چونکہ ہر درخواست پر چیک کیا جاتا ہے اور ہر درخواست کی عوامی کلید کے خلاف تصدیق ہو جاتی ہے، اس لیے ہم جانتے ہیں کہ جب تک ہم ہر درخواست پر درست ٹوکن بھیجیں گے ہم اسے حاصل کر سکیں گے۔ OAuth2، Okta SSO، یا کسی اور اجازت کے طریقہ کار کے ساتھ مربوط کیا جا سکتا ہے۔ اس صورت میں، ہم جو کچھ کر رہے ہیں وہ تصدیق اور اجازت کو قائم کر رہا ہے۔ ہماری درخواست میں، ہم استعمال کرنے جا رہے ہیں اور اس کے ساتھ، دستخط کے ذریعے اپنے پیغام کی تصدیق کریں۔ اگرچہ ہم درخواست میں لاگ ان نہیں ہوں گے۔ اس کے بجائے، ہم کامیاب تصدیق کے بعد صارفین کو اپنی ایپلیکیشن استعمال کرنے کی اجازت دیں گے۔ اس مقام پر، یہ دیکھنا آسان ہے کہ اس کی اصل میں ایک مکمل ایپلی کیشن کا ایک بہت چھوٹا حصہ ہے۔ بہر حال، کچھ فعالیت کو شامل کرنے کی ضرورت ہے۔ یہ وہ وسائل ہیں جن کی ہمیں ضرورت ہے: JWT JWT JWT JWT توازن کا نظام کریڈٹ سسٹم آئیے صرف یہ کہتے ہیں کہ ہمارا بنیادی نظام صرف رقم اور کریڈٹ کی درخواستوں کو رجسٹر کرے گا۔ بنیادی طور پر یہ صرف اقدار کو جمع کرے گا۔ آئیے یہ بھی مان لیں کہ کچھ لوگ کریڈٹ حاصل کرنے کے قابل ہوں گے اور دوسروں کو نہیں ملے گا۔ کچھ لوگ پیسے ذخیرہ کر سکیں گے اور دوسرے لوگ کریڈٹ حاصل کر سکیں گے۔ 4. ٹیکنالوجیز کا انتخاب جیسا کہ تعارف میں ذکر کیا گیا ہے، ہم اپنے انٹرپرائز ایپلیکیشن فریم ورک کے طور پر استعمال کریں گے، اور ہم ایک انتہائی بنیادی ایپلی کیشن کو اس طرح لاگو کریں گے کہ ہم بنیادی اصطلاحات اور تصورات کو دیکھ سکیں۔ درست جاوا ورژن کو یقینی بنائیں۔ اس مرحلے پر، ہمیں کم سے کم Java 17 SDK انسٹال کرنے کی ضرورت ہوگی۔ ہمیں maven، git، ایک جاوا سے مطابقت رکھنے والا IDE جیسے IntelliJ، اور کسی قسم کے شیل کی ضرورت ہوگی۔ KumuluzEE JWT 5. سیٹ اپ ہماری درخواست شروع کرنے کے لیے، ہمارے پاس چند انحصار ہیں۔ یہ بنیادی طور پر ہے کیونکہ ، بالکل اسی طرح جیسے Spring Boot کو کچھ انحصار کی ضرورت ہے۔ آئیے مختصراً POM فائل پر ایک نظر ڈالتے ہیں: KumuluzEE KumuluzEE com.kumuluz.ee.openapi kumuluzee-openapi-mp com.kumuluz.ee.openapi kumuluzee-openapi-mp-ui com.kumuluz.ee kumuluzee-microProfile-3.3 ch.qos.logback logback-core ch.qos.logback logback-classic org.jetbrains.kotlin kotlin-stdlib org.assertj assertj-core test org.junit.jupiter junit-jupiter test io.mockk mockk-jvm test com.ninja-squad springmockk test io.kotest kotest-assertions-core-jvm test آئیے چند انحصارات پر مختصراً گفتگو کرتے ہیں۔ جیسے ہی آپ اسے پڑھتے ہیں، براہ کرم ہماری فائل کو اوپر سے نیچے تک فالو کریں۔ درج ذیل وضاحت کو سمجھنے کے لیے یہ ضروری ہے۔ ہمیں اپنی درخواست کو کام کرنے کے لیے انحصار کے پیکج کی ضرورت ہے۔ خوش قسمتی سے، ، ہمیں مائیکرو پروفائل لائبریریاں فراہم کرتا ہے جس میں اس ایپلیکیشن کو شروع کرنے کے لیے بنیادی معیاری بنڈل ہوتے ہیں۔ یہ سب -Microprofile لائبریری میں موجود ہے۔ اپنی ایپ کو تمام پیرامیٹرز کے ساتھ ترتیب دینے کے قابل ہونے کے لیے، ہمیں اس میں ایک مائیکرو پروفائل لائبریری شامل کرنا ہوگی۔ ایک ہی وقت میں، ہمیں JSON پروسیسنگ لائبریری کی ضرورت ہے۔ یہ وہی ہوگا جو جانسن کور کرتا ہے۔ ہمیں یقیناً کام کرنے کے لیے کے بنیادی حصے کی ضرورت ہے۔ Jetty بنیادی سرور ہے جو فریم ورک چلاتا ہے۔ یہی وجہ ہے کہ ہمیں اپنے انحصار میں اس کی ضرورت ہے۔ اس بات پر غور کرتے ہوئے کہ ہمیں ضرورت ہے، ہمیں اس کی حمایت کرنے والی لائبریری کی بھی ضرورت ہے۔ اپنے REST اینڈ پوائنٹس کو فعال کرنے کے لیے، ہمیں کی باقی لائبریری کی ضرورت ہے۔ ہمارا API حاصل کرنے کے لیے، ہمیں پھر ایک Geronimo لائبریری کی ضرورت ہے۔ یہ یقینی بنائے گا کہ ہمارے پاس کا نفاذ دستیاب ہے۔ ہمیں اپنے اور اس کے مواد کی تشریح کرنے کی بھی ضرورت ہے۔ لومبوک کی واقعی ضرورت نہیں ہے۔ یہ صرف ہر چیز کو خوبصورت اور چمکدار بناتا ہے! لاگ بیک کا ہونا بھی ضروری ہے تاکہ ہم لاگز کی بہتر تشریح کر سکیں اور اپنے نتائج کو سمجھ سکیں۔ آئیے اب اپنے فولڈر پر ایک نظر ڈالتے ہیں۔ شروع کرنے کے لیے پہلے یہ سمجھیں کہ ہم اس فولڈر میں کیا تلاش کرنے کی توقع رکھتے ہیں۔ ہمیں اپنی ایپلی کیشن کو ، لاگ بیک سے متعلق کسی چیز سے کنفیگر کرنے کی ضرورت ہے اور آخر میں، ہمیں ان پھلیوں کے بارے میں کچھ کہنے کی ضرورت ہے جو ہم بنانے جا رہے ہیں۔ آئیے سب سے آسان فائل کو دیکھیں۔ beans.xml META-INF میں پایا جا سکتا ہے: pom.xml KumuluzEE KumuluzEE JWT KumuluzEE KumuluzEE CDI KumuluzEE JSR-374 JWT JSON-formatted resources JWT یہ صرف ایک عام ہے اور جیسا کہ آپ اب سوچ رہے ہوں گے، ایک پرانی فائل کا تھوڑا سا۔ اس وقت، خیال صرف یہ ہے کہ چلایا جائے۔ ہمارے پاس ایک خارجی کارروائی ہے۔ یہ ویلڈ سے کہتا ہے کہ بینز ایکشن کے لیے اسکیننگ میں کلاس اکاؤنٹس پر غور نہ کرے۔ یہ ضروری ہے کیونکہ ہم جس عمل کو استعمال کر رہے ہیں، بنیادی طور پر خالی کنسٹرکٹر والی ہر کلاس کو بین سمجھے گا۔ ہم بعد میں دیکھیں گے کہ ہم کیوں نہیں چاہتے کہ اکاؤنٹس کو بین سمجھا جائے۔ اس لمحے کے لیے ذہن میں رکھیں کہ ہم درخواست دائرہ کار کے تحت درخواستیں کر رہے ہیں۔ یہ منطقی ہے کیونکہ ہر درخواست کا ایک مختلف صارف ہو سکتا ہے۔ آئیے اب دیکھتے ہیں کہ " " کو کیسے لاگو کیا جاتا ہے۔ یہ میں بھی پایا جاتا ہے: KumuluzEE Weld logback META-INF %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n یہ ہمارے کے لیے صرف ایک بہت سیدھی سی ترتیب ہے .آخر میں، شاید ہماری درخواست کی سب سے اہم فائل۔ یہ config-template ہے۔ اس مقام پر، یہ نوٹ کرنا ضروری ہے کہ میں نے اس پروجیکٹ میں جو فائلیں بنائی ہیں ان میں سے کچھ ٹیمپلیٹ ڈھانچے کا حصہ ہیں۔ میں بعد میں اس کے بارے میں مزید وضاحت کروں گا۔ اس ٹیمپلیٹ فائل کو ایک config.yml فائل میں تبدیل کیا جانا چاہئے جسے مائیکرو پروفائل پڑھے گا۔ یہ فائل وسائل کی جڑ میں واقع ہے: logs kumuluzee: name: your-financeje-banking version: 1.0.0 jwt-auth: public-key: {{ publicKey }} issuer: {{ issuer }} healthy: true ہم بعد میں دیکھیں گے کہ ان تمام خصوصیات کا اصل میں کیا مطلب ہے۔ یہ سب خود وضاحتی ہیں۔ PublicKey اور جاری کنندہ تمام پیرامیٹرز ہیں جنہیں تبدیل کر دیا جائے گا۔ ہم اسے بعد میں دریافت کریں گے۔ ہماری باش اسکرپٹ اس بات کو یقینی بنائے گی کہ وہ تبدیل ہوجائیں۔ ہم کوڈنگ کرنے کے لیے تقریباً تیار ہیں، لیکن پہلے، آئیے اپنے ٹوکن ڈھانچے پر ایک نظر ڈالیں۔ JWT 6. ہینڈ آن کوڈ آئیے اپنی بہت چھوٹی ایپلی کیشن بناتے ہیں۔ یہ سیکشن وضاحت کرے گا کہ ہم کے ساتھ کام کرنے کے لیے اپنی درخواست کیسے حاصل کر سکتے ہیں۔ ہم جو دیکھنا چاہتے ہیں وہ یہ ہے کہ آیا ہم صارفین کو اپنے کچھ طریقوں تک رسائی کے لیے مخصوص کر سکتے ہیں نہ کہ دوسروں تک۔ اس کوڈ کو دیکھنا شروع کرنے کا ایک طریقہ یہ ہے کہ پہلے اپنے سادہ ٹوکن پر ایک نظر ڈالیں۔ ہمارے منتظم کی مثال یہ ہے: JWT REST JWT { "iss": "joaofilipesabinoesperancinha", "jti": "01MASTERFINANCE", "sub": "admin", "aud": "nature", "upn": "admin", "groups": [ "user", "admin", "client", "credit" ], "user_id": 1, "access": "TOP", "name": "Admin" } ہمارے میں ان ناموں میں سے ہر ایک کو دعویٰ کہا جاتا ہے۔ ہماری مثال میں، ہم کچھ محفوظ دعوے دیکھتے ہیں: JSON " " — یہ ٹوکن جاری کرنے والا ہے۔ ہم من مانی طور پر اس کے لیے ایک قدر کا انتخاب کر سکتے ہیں۔ اس پیرامیٹر کی قدر config.yml میں تبدیل کرنے کے لیے جاری کنندہ متغیر سے مماثل ہونی چاہیے جسے ہم نے پہلے دیکھا ہے۔ iss " " — یہ ٹوکن کا ایک منفرد شناخت کنندہ ہے۔ مثال کے طور پر ہم اس دعوے کو استعمال کر سکتے ہیں تاکہ ٹوکن کو دو یا زیادہ بار استعمال ہونے سے روکا جا سکے۔ jti " " - یہ ٹوکن کا موضوع ہے۔ یہ صارف یا ہماری پسند کی کوئی بھی چیز ہو سکتی ہے۔ یہ ذہن میں رکھنا ضروری ہے کہ اسے شناخت کنندہ، کلید، نام یا کسی بھی چیز کے طور پر بھی استعمال کیا جا سکتا ہے جسے ہم چاہتے ہیں۔ sub " " - صارف کا پرنسپل نام۔ اس کا استعمال صارف کے استعمال کردہ پرنسپل کی شناخت کے لیے کیا جاتا ہے۔ upn " " — یہ ان گروپس کی ایک صف ہے جن سے موجودہ صارف کا تعلق ہے۔ بنیادی طور پر یہ طے کرے گا کہ اس ٹوکن کے ساتھ درخواست کیا کر سکتی ہے۔ ہمارے ٹوکن میں، ہم پھر کچھ حسب ضرورت دعوے دیکھتے ہیں۔ ہم اسے صرف محفوظ دعووں کے ساتھ ساتھ استعمال کر سکتے ہیں۔ groups " " — ہم اسے صارف کی شناخت سیٹ کرنے کے لیے استعمال کریں گے۔ user_id " " - ہم صارف کی رسائی کی سطح کا تعین کریں گے۔ access " " - صارف کا نام۔ name 7. ہینڈ آن کوڈ آئیے ہم اب تک جو کچھ جانتے ہیں اس کا ایک خلاصہ بنائیں۔ ہم جانتے ہیں کہ ہم ٹوکنز کے ساتھ اس ڈھانچے کے ساتھ بات چیت کریں گے جس کا ہم نے تعین کیا ہے۔ مزید، ہم نے اپنی ایپلیکیشن کی کنفیگریشن، لاگ بیک کنفیگریشن ترتیب دی ہے اور آخر میں، ہم نے انٹرپرائز بین کی تلاش کے لیے ایک حسب ضرورت کنفیگریشن ترتیب دی ہے۔ آئیے پیکیج ماڈل کو دیکھیں۔ یہاں ہمیں 3 کلاسیں ملیں گی۔ یہ کلاسیں بنیادی طور پر صرف اکاؤنٹس کے مجموعے اور اور کے درمیان نمائندگی کی نمائندگی کرتی ہیں۔ اس طرح ہم kotlin فائل Model.kt کو دیکھ کر شروع کر سکتے ہیں جہاں واقع ہے: client account Client data class Client constructor( @JsonProperty var name: String ?= null ) یہ پہلی ماڈل کلاس ہمارے کلائنٹ کی نمائندگی ہے۔ ہمارے کیس کے لیے ہمارے صرف ایک نام ہے۔ یہ وہ صارف نام ہے جس کی نمائندگی " " انتساب کے نام سے ہوتی ہے۔ مزید یہ کہ ہمارے پاس ہے : client jwt Account data class Account( @JsonProperty val accountNumber: String?, @JsonProperty val client: Client? = null, @JsonProperty var currentValue: BigDecimal = BigDecimal.ZERO, @JsonProperty var creditValue: BigDecimal = BigDecimal.ZERO ) { fun addCurrentValue(value: Long) = Account( accountNumber, client, currentValue .add(BigDecimal.valueOf(value)), creditValue ) fun addCreditValue(value: Long): Account = Account( accountNumber, client, currentValue, currentValue .add(BigDecimal.valueOf(value)) ) } اس کلاس میں، ہم بنیادی طور پر ایک اکاؤنٹ نمبر، ایک کلائنٹ، ایک کرنٹ ویلیو اور آخر میں ایک کریڈٹ ویلیو ترتیب دیتے ہیں۔ نوٹ کریں کہ ہم تمام اقدار کو 0 پر ڈیفالٹ کر رہے ہیں۔ ہم BigDecimal بھی استعمال کر رہے ہیں، خالصتاً اس لیے کہ ہم پیسے کے ساتھ کام کر رہے ہیں۔ پیسہ بالکل درست ہونا چاہیے اور نظام کے چکر یا راؤنڈ ڈاؤن کا شکار نہیں ہو سکتا۔ اس کا مطلب دوسرے الفاظ میں اور مثال کے طور پر یہ ہے کہ ایک نمبر جیسے 0. یورو ہر وقت اس نمبر کو رہنا چاہئے۔ اس کے علاوہ، ہم اپنے اکاؤنٹ میں قدریں شامل کرنا چاہتے ہیں۔ یہ وہ جگہ ہے جہاں طریقہ addCurrentValue وجود میں آتا ہے۔ انہی وجوہات کی بنا پر، ہم کے ساتھ اپنا کریڈٹ بھی ٹاپ اپ کریں گے۔ آخر کار، اپنے ڈیٹا سیٹ اپ کے آخری حصے میں ہم کلاس پر آتے ہیں: 0000000000000000000000000000000000000000000000000001 addCreditValue Accounts open class Accounts constructor( open val accountMap: MutableMap = mutableMapOf() ) یہ بنیادی طور پر ہمارے تمام اکاؤنٹس کا صرف ایک مجموعہ ہے۔ ہم اس کے نقشے کے مواد کو ڈیٹا بیس کے رویے کی نقل کرنے کے لیے استعمال کریں گے۔ اب آئیے کنٹرولر پیکج کو دیکھتے ہیں۔ یہ وہ جگہ ہے جہاں ہم اپنے ڈیٹا ماڈل کے ساتھ چلنے والی اپنی ایپلیکیشن بناتے ہیں۔ سب سے پہلے، آئیے کلاس پر ایک نظر ڈالتے ہیں: BankApplication @LoginConfig(authMethod = "MP-JWT") @ApplicationPath("/") @DeclareRoles("admin", "creditor", "client", "user") class BankApplication : Application() اس کے ساتھ ہم 3 اہم باتیں بتا رہے ہیں۔ LoginConfig تشریح کے ساتھ، ہم مائکرو پروفائل کے مطابق ٹوکن کو استعمال کرنے اور سمجھنے کے لیے اس کی وضاحت کرتے ہیں۔ ApplicationPath درخواست کی جڑ کی وضاحت کرتا ہے۔ یہیں سے درخواست کا URL شروع ہوگا۔ ہماری مثال میں، یہ ہوگا ۔ آخر میں، DeclareRoles ان کرداروں کی وضاحت کرتا ہے جو ہماری درخواست کے ذریعے استعمال اور قبول کیے جانے والے ہیں۔ اس صورت حال میں رولز اور گروپس قابل تبادلہ ہیں۔ JWT HTTP://localhost:8080 annotation class AccountsProduct فل سکرین موڈ میں داخل ہوں فل سکرین موڈ سے باہر نکلیں۔ اگلا، ہم ایک کیشے آبجیکٹ فیکٹری اکاؤنٹس فیکٹری بناتے ہیں: class AccountsFactory : Serializable { @Produces @AccountsProduct @ApplicationScoped fun accounts(): Accounts = Accounts(mutableMapOf()) companion object { @Throws(JsonProcessingException::class) fun createResponse( currentAccount: Account, name: JsonString, accounts: Accounts, log: Logger, objectMapper: ObjectMapper, principal: Principal?, jsonWebToken: JsonWebToken? ): Response { val jsonObject = Json.createObjectBuilder() .add("balance", currentAccount.currentValue) .add("client", name) .build() accounts.accountMap[name.string] = currentAccount log.info("Principal: {}", objectMapper.writeValueAsString(principal)) log.info("JSonWebToken: {}", objectMapper.writeValueAsString(jsonWebToken)) return Response.ok(jsonObject) .build() } } } یہ فیکٹری یہی وجہ ہے کہ ہم نے خاص طور پر کی تلاش کو غیر فعال کر دیا۔ تلاش کرنے کے عمل کو بین بنانے کی اجازت دینے کے بجائے، ہم خود کو ایگریگیٹر مثال بناتے ہیں۔ Produces تشریح کا استعمال کرتے ہوئے، ہمیں بین بنانے کی اجازت دیتا ہے۔ اپنی حسب ضرورت تشریح، اکاؤنٹس پروڈکٹ کا استعمال کرتے ہوئے، ہم اس بین کے استعمال کو مزید مخصوص بناتے ہیں۔ آخر میں، استعمال کرتے ہوئے، ہم اس کے دائرہ کار کو اسکوپ کے طور پر بیان کرتے ہیں۔ دوسرے لفظوں میں، اکاؤنٹ ایگریگیشن بین پوری ایپلی کیشن میں سنگلٹن آبجیکٹ کے طور پر برتاؤ کرے گا۔ JSON جوابات بنانے کے لیے " " صرف ایک عام طریقہ ہے۔ اب ہمیں جس چیز کی ضرورت ہے وہ دو "وسائل" ہیں۔ یہ بنیادی طور پر بہار میں " " جیسا ہی ہے۔ یہ ایک مختلف نام ہے، لیکن اس کا بالکل وہی استعمال ہے۔ آئیے کلاس کو دیکھیں: Accounts ApplicationScoped Application createResponse Controllers AccountsResource @Path("accounts") @RequestScoped @Produces(MediaType.APPLICATION_JSON) open class AccountResource { @Inject @AccountsProduct open var accounts: Accounts? = null @Inject open var principal: Principal? = null @Inject open var jsonWebToken: JsonWebToken? = null @Inject @Claim("access") open var access: JsonString? = null @Claim("iat") @Inject open var iat: JsonNumber? = null @Inject @Claim("name") open var name: JsonString? = null @Inject @Claim("user_id") open var userId: JsonNumber? = null @POST @RolesAllowed("admin", "client", "credit") @Throws(JsonProcessingException::class) open fun createAccount(): Response = createResponse( requireNotNull(accounts).accountMap[requireNotNull(name).string] ?: Account( client = Client(name = requireNotNull(name).string), accountNumber = UUID.randomUUID().toString() ) ) @POST @RolesAllowed("admin", "user") @Path("user") @Throws(JsonProcessingException::class) open fun createUser(): Response { return createResponse( requireNotNull(accounts).accountMap[requireNotNull(name).string] ?: Account( client = Client(name = requireNotNull(name).string), accountNumber = UUID.randomUUID().toString() ) ) } @GET @RolesAllowed("admin", "client") @Throws(JsonProcessingException::class) open fun getAccount(): Response? { return createResponse( requireNotNull(accounts).accountMap[requireNotNull(name).string] ?: return Response.serverError() .build() ) } @PUT @RolesAllowed("admin", "client") @Consumes(MediaType.APPLICATION_JSON) @Throws( JsonProcessingException::class ) open fun cashIn(transactionBody: TransactionBody): Response? { val userAccount = requireNotNull(accounts).accountMap[requireNotNull(name).string] ?: return Response.serverError() .build() val currentAccount = userAccount.addCurrentValue(transactionBody.saldo?: 0) requireNotNull(accounts).accountMap[requireNotNull(name).string] = currentAccount return createResponse(currentAccount) } @GET @Path("all") @Produces(MediaType.APPLICATION_JSON) @Throws( JsonProcessingException::class ) open fun getAll(): Response? { val allAccounts = ArrayList( requireNotNull(accounts).accountMap .values ) logger.info("Principal: {}", objectMapper.writeValueAsString(principal)) logger.info("JSonWebToken: {}", objectMapper.writeValueAsString(jsonWebToken)) return Response.ok(allAccounts) .build() } @GET @Path("summary") @Throws(JsonProcessingException::class) open fun getSummary(): Response? { val totalCredit = requireNotNull(accounts).accountMap .values .map(Account::currentValue) .stream() .reduce { result, u -> result.add(u) } .orElse(BigDecimal.ZERO) val jsonObject = Json.createObjectBuilder() .add("totalCurrent", totalCredit) .add("client", "Mother Nature Dream Team") .build() logger.info("Summary") logger.info("Principal: {}", objectMapper.writeValueAsString(principal)) logger.info("JSonWebToken: {}", objectMapper.writeValueAsString(jsonWebToken)) return Response.ok(jsonObject) .build() } @GET @RolesAllowed("admin", "client") @Path("jwt") open fun getJWT(): Response? { val jsonObject = Json.createObjectBuilder() .add("jwt", requireNotNull(jsonWebToken).rawToken) .add("userId", requireNotNull(userId).doubleValue()) .add("access", requireNotNull(access).string) .add("iat", requireNotNull(iat).doubleValue()) .build() return Response.ok(jsonObject) .build() } @Throws(JsonProcessingException::class) private fun createResponse(currentAccount: Account): Response = AccountsFactory.createResponse( currentAccount, requireNotNull(name), requireNotNull(accounts), logger, objectMapper, principal, jsonWebToken ) companion object { val objectMapper: ObjectMapper = ObjectMapper() val logger: Logger = LoggerFactory.getLogger(AccountResource::class.java) } } اس کلاس کو مزید تفصیل سے دیکھنے کے لیے ایک لمحہ نکالیں۔ تشریح اس بات کی وضاحت کرتی ہے کہ جڑ سے اس وسائل تک کیسے پہنچنا ہے۔ یاد رکھیں کہ ہم "/" کو روٹ کے طور پر استعمال کر رہے ہیں۔ اس صورت میں، "اکاؤنٹس" اس وسائل کے لیے ہمارے روٹ ایکسس پوائنٹ ہیں۔ ہمارے تمام وسائل، ہمارے معاملے میں صرف دو اسکوپ RequestResource کے ساتھ چل رہے ہیں۔ تشریح کے ساتھ Produces اس بات کا تعین کرتا ہے کہ تمام درخواستوں کے تمام جوابات قطع نظر ان کی قسم JSON فارمیٹ شدہ پیغامات کی شکل اختیار کریں گے۔ اپنے انجیکشن کرنے کے لیے ہم صرف انجیکشن تشریح اور تشریح کے امتزاج کا استعمال کرتے ہیں: Path aggregator AccountsProduct @Inject @AccountsProduct open var accounts: Accounts? = null یہ اس سے میل کھاتا ہے جس کی ہم نے فیکٹری میں تعریف کی ہے۔ مزید یہ کہ ہم سیکیورٹی کے دو اہم عناصر کو بھی انجیکشن کر رہے ہیں۔ ایک اور : principal jsonWebToken @Inject open var principal: Principal? = null @Inject open var jsonWebToken: JsonWebToken? = null اور دونوں ایک جیسے ہوں گے، اور ہم اسے اپنے لاگز میں دیکھیں گے۔ اپنے وسائل میں، ہم ہمیشہ ایک مخصوص ٹوکن کے ساتھ درخواست سے دعوے لگا سکتے ہیں: JsonWebToken Principal @Inject @Claim("name") open var name: JsonString? = null @Inject @Claim("user_id") open var userId: JsonNumber? = null یہ اور تشریحات کے امتزاج سے پورا ہوتا ہے۔ تشریح کے تحت رکھا گیا نام اس بات کی وضاحت کرتا ہے کہ ہم کون سا دعویٰ لگانا چاہتے ہیں۔ ہمیں اس قسم کے ساتھ محتاط رہنا ہوگا جس کے ساتھ ہم اپنے پیرامیٹرز کی وضاحت کرتے ہیں۔ ہماری مثال میں، ہمیں صرف اور اقسام کی ضرورت ہے۔ سب سے پہلے، آئیے دیکھتے ہیں کہ ہم اکاؤنٹس اور صارفین کیسے بنا رہے ہیں: Inject Claim Claim JsonString JsonNumber @POST @RolesAllowed("admin", "client", "credit") @Throws(JsonProcessingException::class) open fun createAccount(): Response = createResponse( requireNotNull(accounts).accountMap[requireNotNull(name).string] ?: Account( client = Client(name = requireNotNull(name).string), accountNumber = UUID.randomUUID().toString() ) ) @POST @RolesAllowed("admin", "user") @Path("user") @Throws(JsonProcessingException::class) open fun createUser(): Response { return createResponse( requireNotNull(accounts).accountMap[requireNotNull(name).string] ?: Account( client = Client(name = requireNotNull(name).string), accountNumber = UUID.randomUUID().toString() ) ) } اکاؤنٹس اور صارفین بنانا یہاں کا مقصد طریقوں کو الگ کرنے اور انہیں مختلف اجازتیں دینے کے قابل ہونا ہے۔ ہماری مثال میں، وہ دونوں صرف ایک اکاؤنٹ بناتے ہیں، لیکن یہ نوٹ کرنا ضروری ہے کہ صرف کردار والے صارف ہی createUser طریقہ استعمال کر سکتے ہیں۔ اسی طرح، کلائنٹ اور کریڈٹ کے کردار کے حامل صارف ہی طریقہ CreateAccount تک رسائی حاصل کر سکتے ہیں۔ آئیے اب اس وسائل کے PUT درخواست کے طریقہ کار کو تفصیل سے دیکھتے ہیں: @PUT @RolesAllowed("admin", "client") @Consumes(MediaType.APPLICATION_JSON) @Throws( JsonProcessingException::class ) open fun cashIn(transactionBody: TransactionBody): Response? { val userAccount = requireNotNull(accounts).accountMap[requireNotNull(name).string] ?: return Response.serverError() .build() val currentAccount = userAccount.addCurrentValue(transactionBody.saldo?: 0) requireNotNull(accounts).accountMap[requireNotNull(name).string] = currentAccount return createResponse(currentAccount) } کیش ان ہم جانتے ہیں کہ تشریح اشارہ کرتی ہے کہ یہ طریقہ صرف قسم کی درخواستوں کے ساتھ ہی قابل رسائی ہے۔ تشریح کا راستہ پھر جیٹی کو بتاتا ہے کہ اس طریقہ کا راستہ ایک قدر ہے۔ اسے نام سے بھی جانا جاتا ہے۔ آخر میں، ہم اس طریقہ کی وضاحت کر سکتے ہیں کہ صرف منتظم یا کلائنٹ کے کردار والے صارفین کو استعمال کرنے کی اجازت ہو۔ ان پٹ ویلیو کو پھر PathParam کے استعمال سے ہمارے لانگ ویلیو متغیر کو منتقل کیا جاتا ہے۔ اگر ہم کسی کردار کی وضاحت نہیں کرتے ہیں، تو صحیح ٹوکن والا کوئی بھی صارف ان طریقوں تک رسائی حاصل کر سکے گا طریقہ: PUT PUT PathParam CreditResource @Path("credit") @RequestScoped @Produces(MediaType.APPLICATION_JSON) open class CreditResource { @Inject @AccountsProduct open var accounts: Accounts? = null @Inject open var principal: Principal? = null @Inject open var jsonWebToken: JsonWebToken? = null @Inject @Claim("access") open var access: JsonString? = null @Inject @Claim("iat") open var iat: JsonNumber? = null @Inject @Claim("name") open var name: JsonString? = null @Inject @Claim("user_id") open var userId: JsonNumber? = null @GET @RolesAllowed("admin", "credit") @Throws(JsonProcessingException::class) open fun getAccount(): Response = requireNotNull(accounts).let { accounts -> createResponse( accounts.accountMap[requireNotNull(name).string] ?: return Response.serverError().build() ) } @PUT @RolesAllowed("admin", "credit") @Consumes(MediaType.APPLICATION_JSON) @Throws( JsonProcessingException::class ) open fun cashIn(transactionBody: TransactionBody) = requireNotNull(accounts).let { accounts -> requireNotNull(name).let { name -> accounts.accountMap[name.string] = (accounts.accountMap[name.string] ?: return Response.serverError() .build()).addCreditValue(transactionBody.saldo?: 0L) createResponse( (accounts.accountMap[name.string] ?: return Response.serverError() .build()).addCreditValue(transactionBody.saldo?: 0L) ) } } @GET @Path("all") @Produces(MediaType.APPLICATION_JSON) @Throws( JsonProcessingException::class ) open fun getAll(): Response? { val allAccounts = ArrayList( requireNotNull(accounts).accountMap .values ) logger.info("Principal: {}", objectMapper.writeValueAsString(principal)) logger.info("JSonWebToken: {}", objectMapper.writeValueAsString(jsonWebToken)) return Response.ok(allAccounts) .build() } @GET @Path("summary") @Produces(MediaType.APPLICATION_JSON) @Throws( JsonProcessingException::class ) open fun getSummary(): Response? { val totalCredit = requireNotNull(accounts).accountMap .values .map(Account::creditValue) .stream() .reduce { total, v -> total.add(v) } .orElse(BigDecimal.ZERO) val jsonObject = Json.createObjectBuilder() .add("totalCredit", totalCredit) .add("client", "Mother Nature Dream Team") .build() logger.info("Summary") logger.info("Principal: {}", objectMapper.writeValueAsString(principal)) logger.info("JSonWebToken: {}", objectMapper.writeValueAsString(jsonWebToken)) return Response.ok(jsonObject) .build() } @GET @RolesAllowed("admin", "client") @Path("jwt") open fun getJWT(): Response? { val jsonObject = Json.createObjectBuilder() .add("jwt", requireNotNull(jsonWebToken).rawToken) .add("userId", requireNotNull(userId).doubleValue()) .add("access", requireNotNull(access).string) .add("iat", requireNotNull(iat).doubleValue()) .build() return Response.ok(jsonObject) .build() } @Throws(JsonProcessingException::class) private fun createResponse(currentAccount: Account): Response { return AccountsFactory.createResponse( currentAccount, requireNotNull(name), requireNotNull(accounts), logger, objectMapper, principal, jsonWebToken ) } companion object { val objectMapper: ObjectMapper = ObjectMapper() val logger: Logger = LoggerFactory.getLogger(CreditResource::class.java) } } فرق صرف اتنا ہے کہ اور رولز استعمال کرنے کے بجائے اب ہم اور رولز استعمال کر رہے ہیں۔ نیز، یہ بھی نوٹ کریں کہ اس میں صارفین کے اکاؤنٹس کبھی نہیں بنائے جائیں گے۔ یہ صرف اکاؤنٹ کے کے ذریعے ہی ممکن ہے admin client admin credit resource resource REST 8. درخواست کا استعمال آئیے استعمال ہونے والی خدمات کی فہرست چیک کریں: قسم، URL، پے لوڈ، نتیجہ، کرداروں کی اجازت ہے۔ پوسٹ، کریڈٹ، تمام http://localhost:8080/accounts,n/a,تخلیق شدہ اکاؤنٹ، ایڈمن/کلائنٹ/کریڈٹ پوسٹ، http://localhost:8080/accounts/user,n/a,تخلیق شدہ صارف، منتظم/صارف حاصل کریں، http://localhost:8080/accounts,n/a,Matching اکاؤنٹ، ایڈمن/کلائنٹ ڈالو http://localhost:8080/accounts،{saldo: طویل}، موجودہ بیلنس، منتظم/کلائنٹ حاصل کریں، http://localhost:8080/accounts/all,n/a,All کرنٹ اکاؤنٹس، تمام حاصل کریں، http://localhost:8080/accounts/summary,n/a,Sum تمام بیلنس کے، تمام حاصل کریں، http://localhost:8080/credit,n/a,Matching اکاؤنٹ، ایڈمن/کلائنٹ ڈالو http://localhost:8080/credit،{saldo: Long}، موجودہ کریڈٹ، منتظم/کلائنٹ حاصل کریں، http://localhost:8080/credit/all,n/a,All کریڈٹ، تمام حاصل کریں، http://localhost:8080/credit/summary,n/a,Sum 9. ٹیسٹ ماحول پیدا کرنا میں نے روٹ فولڈر میں ایک فائل بنائی ہے۔ اس فائل کو "setupCertificates.sh" کہا جاتا ہے۔ آئیے اس پر ایک نظر ڈالتے ہیں کہ یہ کیا کرتا ہے: bash #!/bin/bash mkdir -p your-finance-files cd your-finance-files || exit openssl genrsa -out baseKey.pem openssl pkcs8 -topk8 -inform PEM -in baseKey.pem -out privateKey.pem -nocrypt openssl rsa -in baseKey.pem -pubout -outform PEM -out publicKey.pem echo -e '\033[1;32mFirst test\033[0m' java -jar ../your-finance-jwt-generator/target/your-finance-jwt-generator.jar \ -p ../jwt-plain-tokens/jwt-token-admin.json \ -key ../your-finance-files/privateKey.pem >> token.jwt CERT_PUBLIC_KEY=$(cat ../your-finance-files/publicKey.pem) CERT_ISSUER="joaofilipesabinoesperancinha" echo -e "\e[96mGenerated public key: \e[0m $CERT_PUBLIC_KEY" echo -e "\e[96mIssued by: \e[0m $CERT_ISSUER" echo -e "\e[96mYour token is: \e[0m $(cat token.jwt)" cp ../your-financeje-banking/src/main/resources/config-template ../your-financeje-banking/src/main/resources/config_copy.yml CERT_CLEAN0=${CERT_PUBLIC_KEY//"/"/"\/"} CERT_CLEAN1=${CERT_CLEAN0//$'\r\n'/} CERT_CLEAN2=${CERT_CLEAN1//$'\n'/} CERT_CLEAN3=$(echo "$CERT_CLEAN2" | awk '{gsub("-----BEGIN PUBLIC KEY-----",""); print}') CERT_CLEAN4=$(echo "$CERT_CLEAN3" | awk '{gsub("-----END PUBLIC KEY-----",""); print}') CERT_CLEAN=${CERT_CLEAN4//$' '/} echo -e "\e[96mCertificate cleanup: \e[0m ${CERT_CLEAN/$'\n'/}" sed "s/{{ publicKey }}/$CERT_CLEAN/g" ../your-financeje-banking/src/main/resources/config_copy.yml > ../your-financeje-banking/src/main/resources/config_cert.yml sed "s/{{ issuer }}/$CERT_ISSUER/g" ../your-financeje-banking/src/main/resources/config_cert.yml > ../your-financeje-banking/src/main/resources/config.yml rm ../your-financeje-banking/src/main/resources/config_cert.yml rm ../your-financeje-banking/src/main/resources/config_copy.yml echo -e "\e[93mSecurity elements completely generated!\e[0m" echo -e "\e[93mGenerating tokens...\e[0m" TOKEN_FOLDER=jwt-tokens mkdir -p ${TOKEN_FOLDER} # CREATE_ACCOUNT_FILE=createAccount.sh CREATE_USER_FILE=createUser.sh SEND_MONEY_FILE=sendMoney.sh ASK_CREDIT_FILE=askCredit.sh TOKEN_NAME_VALUE=tokenNameValue.csv echo "#!/usr/bin/env bash" > ${CREATE_ACCOUNT_FILE} chmod +x ${CREATE_ACCOUNT_FILE} echo "#!/usr/bin/env bash" > ${CREATE_USER_FILE} chmod +x ${CREATE_USER_FILE} echo "#!/usr/bin/env bash" > ${SEND_MONEY_FILE} chmod +x ${SEND_MONEY_FILE} echo "#!/usr/bin/env bash" > ${ASK_CREDIT_FILE} chmod +x ${ASK_CREDIT_FILE} for item in ../jwt-plain-tokens/jwt-token*.json; do if [[ -f "$item" ]]; then filename=${item##*/} per_token=${filename/jwt-token-/} token_name=${per_token/.json/} cp "${item}" jwt-token.json java -jar ../your-finance-jwt-generator/target/your-finance-jwt-generator.jar \ -p jwt-token.json \ -key ../your-finance-files/privateKey.pem > token.jwt cp token.jwt ${TOKEN_FOLDER}/token-"${token_name}".jwt token=$(cat token.jwt) echo "# Create account: ""${token_name}" >> ${CREATE_ACCOUNT_FILE} echo "echo -e \"\e[93mCreating account \e[96m${token_name}\e[0m\"" >> ${CREATE_ACCOUNT_FILE} echo curl -i -H"'Authorization: Bearer ""${token}""'" http://localhost:8080/accounts -X POST >> ${CREATE_ACCOUNT_FILE} echo "echo -e \"\e[93m\n---\e[0m\"" >> ${CREATE_ACCOUNT_FILE} echo "# Create user: ""${token_name}" >> ${CREATE_USER_FILE} echo "echo -e \"\e[93mCreating user \e[96m${token_name}\e[0m\"" >> ${CREATE_USER_FILE} echo curl -i -H"'Authorization: Bearer ""${token}""'" http://localhost:8080/accounts/user -X POST >> ${CREATE_USER_FILE} echo "echo -e \"\e[93m\n---\e[0m\"" >> ${CREATE_USER_FILE} echo "# Send money to: "${token_name} >> ${SEND_MONEY_FILE} echo "echo -e \"\e[93mSending money to \e[96m${token_name}\e[0m\"" >> ${SEND_MONEY_FILE} echo curl -i -H"'Content-Type: application/json'" -H"'Authorization: Bearer ""${token}""'" http://localhost:8080/accounts -X PUT -d "'{ \"saldo\": "$((1 + RANDOM % 500))"}'" >> ${SEND_MONEY_FILE} echo "echo -e \"\e[93m\n---\e[0m\"" >> ${SEND_MONEY_FILE} echo "# Asking money credit to: "${token_name} >> ${ASK_CREDIT_FILE} echo "echo -e \"\e[93mAsking credit from \e[96m${token_name}\e[0m\"" >> ${ASK_CREDIT_FILE} echo curl -i -H"'Content-Type: application/json'" -H"'Authorization: Bearer ""${token}""'" http://localhost:8080/credit -X PUT -d "'{ \"saldo\": "$((1 + RANDOM % 500))"}'">> ${ASK_CREDIT_FILE} echo "echo -e \"\e[93m\n---\e[0m\"" >> ${ASK_CREDIT_FILE} echo "${token_name},${token}" >> ${TOKEN_NAME_VALUE} fi done ماحولیات کی نسل براہ کرم فائل کی پیروی کریں جیسا کہ میں وضاحت کرتا ہوں کہ یہ کیا کرتی ہے۔ یہ ضروری ہے تاکہ ہم سمجھ سکیں کہ یہ کیا کر رہا ہے۔ ہم سب سے پہلے فارمیٹ میں نجی اور عوامی کلید بناتے ہیں۔ اس کے بعد ہم اپنے چلانے کے قابل "your-finance-jwt-generator.jar" کے ساتھ نجی کلید استعمال کرتے ہیں۔ یہ ہمارا چلانے کے قابل جار ہے جو ٹوکنز کی فوری تخلیق کی اجازت دیتا ہے۔ جاری کنندہ کو بعد میں تبدیل نہیں کیا جا سکتا۔ آخر میں، یہ ایک ٹوکن بناتا ہے۔ ہم بعد میں دیکھیں گے کہ اس ٹوکن کو کیسے پڑھا جائے۔ اس ٹوکن میں ہیڈر کے 3 اضافی دعوے ہیں۔ یہ "بچہ"، "ٹائپ" اور "الگ" ہیں۔ یہ مندرجہ ذیل شکل کی پیروی کرتا ہے: PEM { "kid": "jwt.key", "typ": "JWT", "alg": "RS256" } کا ہیڈر JWT آئیے ان دعوؤں کو مزید قریب سے دیکھتے ہیں: "بچہ" - اشارہ کے دعوی کے طور پر کام کرتا ہے۔ یہ بتاتا ہے کہ ہم کس قسم کا الگورتھم استعمال کر رہے ہیں۔ "typ" — یہ میڈیا کی اقسام کا اعلان کرنے کے لیے استعمال ہوتا ہے۔ تین اختیارات ہیں (JSON ویب ٹوکن)، (JSON ویب انکرپشن)، اور (JSON ویب الگورتھم)۔ یہ اقسام ہمارے تجربے سے متعلق نہیں ہیں۔ ہم صرف یہ دیکھیں گے کہ ہمارا ٹوکن واقعی اچھی طرح سے خفیہ نہیں ہے اور اسے ڈکرپٹ کرنا واقعی آسان ہے۔ ہم یہ بھی دیکھیں گے کہ اگرچہ ہم ٹوکنز کو ڈکرپٹ کر سکتے ہیں، لیکن ہم دوسری کارروائیوں کو انجام دینے کے لیے آسانی سے چھیڑ چھاڑ نہیں کر سکتے۔ IANA JWT JWE JWA "alg" - اس طرح ہم دستخط کی قسم کی وضاحت کرتے ہیں جسے ہم استعمال کرنا چاہتے ہیں۔ دستخط کو ایک کرپٹوگرافک آپریشن کے طور پر سمجھا جا سکتا ہے جو اس بات کو یقینی بنائے گا کہ اصل ٹوکن تبدیل نہیں کیا گیا ہے اور اس پر بھروسہ کیا گیا ہے۔ ہمارے معاملے میں، ہم RS256 استعمال کر رہے ہیں بصورت دیگر SHA-256 کے ساتھ RSA Signature کے نام سے جانا جاتا ہے۔ اپنی عوامی کلید کے ساتھ، ہم آخر کار اسے اپنے سانچے کو تبدیل کرنے کے لیے استعمال کر سکتے ہیں۔ نئی config.yml فائل کو کچھ اس طرح نظر آنا چاہئے: kumuluzee: name: your-financeje-banking version: 1.0.0 jwt-auth: public-key: FAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKE.FAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETO.FAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKEN issuer: joaofilipesabinoesperancinha healthy: true config.yml دوسرا مرحلہ چار فائلیں بنانا ہے۔ ڈائرکٹری " " میں ہر ایک سادہ ٹوکن کے لیے، ہم چار کمانڈز بنائیں گے۔ پہلی کمانڈ یہ ہے کہ ایسے صارفین کو تخلیق کیا جائے جو اپنے اکاؤنٹس کے ساتھ مؤثر طریقے سے کام کر سکیں۔ یہ پروفائلز " "، " " اور " " والے صارف ہیں۔ آئیے ان کو بنانے کے لیے " " فائل چلائیں۔ دوسری کمانڈ باقی صارفین کو بنائے گی جن کے پاس ابھی تک کوئی حقوق نہیں ہیں۔ یہ فائل "createUser.sh" ہے۔ چلو اسے چلاتے ہیں۔ اب ہم دیکھیں گے کہ آخر کار تمام صارفین بن چکے ہیں۔ آئیے اب لین دین کے بارے میں تفصیلات دیکھیں اور باقی دو کمانڈز کو دیکھیں۔ ایک "کیشین" کے لیے اور دوسرا مزید کریڈٹ مانگنے کے لیے۔ پہلی تیار کردہ فائل "sendMoney.sh" bash اسکرپٹ ہے۔ یہاں ہم " " کی تمام درخواستیں تلاش کر سکتے ہیں۔ اس فائل میں آپ کو فی صارف، صارفین کو بے ترتیب رقم کی مقدار بھیجنے کے لیے کرل کی درخواست ملے گی۔ آئیے ایڈمن کیس کو دیکھتے ہیں: jwt-plain-tokens admin client credit createAccount.sh cashin #!/usr/bin/env bash # Send money to: admin echo -e "\e[93mSending money to \e[96madmin\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer= FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 125}' echo -e "\e[93m\n---\e[0m" # Send money to: cindy echo -e "\e[93mSending money to \e[96mcindy\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 360}' echo -e "\e[93m\n---\e[0m" # Send money to: faustina echo -e "\e[93mSending money to \e[96mfaustina\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 50}' echo -e "\e[93m\n---\e[0m" # Send money to: jack echo -e "\e[93mSending money to \e[96mjack\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 205}' echo -e "\e[93m\n---\e[0m" # Send money to: jitska echo -e "\e[93mSending money to \e[96mjitska\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 332}' echo -e "\e[93m\n---\e[0m" # Send money to: judy echo -e "\e[93mSending money to \e[96mjudy\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 295}' echo -e "\e[93m\n---\e[0m" # Send money to: lucy echo -e "\e[93mSending money to \e[96mlucy\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 160}' echo -e "\e[93m\n---\e[0m" # Send money to: malory echo -e "\e[93mSending money to \e[96mmalory\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 413}' echo -e "\e[93m\n---\e[0m" # Send money to: mara echo -e "\e[93mSending money to \e[96mmara\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 464}' echo -e "\e[93m\n---\e[0m" # Send money to: namita echo -e "\e[93mSending money to \e[96mnamita\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 51}' echo -e "\e[93m\n---\e[0m" # Send money to: pietro echo -e "\e[93mSending money to \e[96mpietro\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 491}' echo -e "\e[93m\n---\e[0m" # Send money to: rachelle echo -e "\e[93mSending money to \e[96mrachelle\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 474}' echo -e "\e[93m\n---\e[0m" # Send money to: sandra echo -e "\e[93mSending money to \e[96msandra\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 417}' echo -e "\e[93m\n---\e[0m" # Send money to: shikka echo -e "\e[93mSending money to \e[96mshikka\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 64}' echo -e "\e[93m\n---\e[0m" sendMoney.sh اقتباس انہی صارفین نے اپنی کریڈٹ کی درخواستیں بھی انہیں تفویض کی ہیں: #!/usr/bin/env bash # Asking money credit to: admin echo -e "\e[93mAsking credit from \e[96madmin\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 137}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: cindy echo -e "\e[93mAsking credit from \e[96mcindy\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 117}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: faustina echo -e "\e[93mAsking credit from \e[96mfaustina\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 217}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: jack echo -e "\e[93mAsking credit from \e[96mjack\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 291}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: jitska echo -e "\e[93mAsking credit from \e[96mjitska\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 184}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: judy echo -e "\e[93mAsking credit from \e[96mjudy\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 388}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: lucy echo -e "\e[93mAsking credit from \e[96mlucy\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 219}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: malory echo -e "\e[93mAsking credit from \e[96mmalory\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 66}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: mara echo -e "\e[93mAsking credit from \e[96mmara\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 441}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: namita echo -e "\e[93mAsking credit from \e[96mnamita\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 358}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: pietro echo -e "\e[93mAsking credit from \e[96mpietro\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 432}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: rachelle echo -e "\e[93mAsking credit from \e[96mrachelle\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 485}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: sandra echo -e "\e[93mAsking credit from \e[96msandra\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 500}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: shikka echo -e "\e[93mAsking credit from \e[96mshikka\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 89}' echo -e "\e[93m\n---\e[0m" askCredit.sh اقتباس ہمارے تمام لیگ آف کا حصہ ہیں۔ اس بینکنگ سسٹم کا حصہ بننے کے لیے بنیادی طور پر صرف کچھ لوگوں کا گروپ۔ اس تناظر میں وہ ماحولیات کا دفاع کر رہے ہیں۔ یہ مضمون کے لیے واقعی متعلقہ نہیں ہے کہ لوگوں کا یہ گروپ کیا کرتا ہے یا کہانی میں وہ کہاں فٹ ہوتے ہیں، لیکن سیاق و سباق کے لیے، وہ ماحول کے دفاع اور کے اثرات کو کم کرنے کے لیے کارروائیوں میں حصہ لیتے ہیں۔ ہمارے کچھ سب کچھ کر سکتے ہیں، دوسرے کچھ نہیں کر سکتے اور دوسرے صرف "کیشین" یا صرف "کریڈٹ مانگ" سکتے ہیں۔ یہ بھی نوٹ کریں کہ میں حساس معلومات کو مبہم کر رہا ہوں۔ ان ٹوکنز کو عام طور پر کسی خاص URL پر شیئر نہیں کیا جانا چاہیے اور نہ ہی دکھائی دینا چاہیے۔ وہ ہاں ہمیشہ براؤزر ڈویلپر کنسول کے ذریعے دستیاب ہوتے ہیں لیکن بہرحال کچھ درخواستوں کی کرنا ہے۔ یہ ایک تصور ہے جسے "سیکیورٹی-فی-مبہمیت" کے نام سے جانا جاتا ہے اگرچہ یہ تکنیکی طور پر صارف کو ٹوکن کے استعمال کے بارے میں آگاہ ہونے سے نہیں روکتا، لیکن یہ ایک رکاوٹ کا کام کرتا ہے۔ دونوں طریقوں میں، جب ہم رقم جمع کرتے ہیں یا جب ہم کریڈٹ کے لیے پوچھیں، نوٹس کریں کہ ہر درخواست کے لیے، ہم 1 سے 500 کے درمیان ایک بے ترتیب نمبر بھیج رہے ہیں۔ اب ہم اپنی درخواست شروع کرنے کے لیے تقریباً تیار ہیں، لیکن پہلے، آئیے تھوڑا سا غوطہ لگائیں۔ مزید نظریہ. characters Nature موسمیاتی تبدیلی characters protect and 10. ٹوکن کیسے بنایا جاتا ہے۔ JWT اب جب کہ ہم نے اپنے ٹوکن بنائے ہیں، آئیے ان میں سے ایک کو دیکھتے ہیں۔ میں آپ کو ایک مبہم ٹوکن دکھانے جا رہا ہوں، اور ہم اسے سمجھنے کے لیے استعمال کرنے جا رہے ہیں۔ ہمارا ٹوکن یہ ہے: ۔ . یہاں جو بات نوٹ کرنا ضروری ہے وہ یہ ہے کہ ہمارے ٹوکن کو تین حصوں میں تقسیم کیا گیا ہے: FAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKE FAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETO FAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKEN — یہ ایک بیس 64 انکوڈ شدہ JSON کنفیگریشن ہیڈر ہے، جیسا کہ ہم نے اوپر بات کی ہے۔ ہیڈر — یہ ایک بیس 64 انکوڈ شدہ JSON پے لوڈ ہے۔ یہیں پر ہم نے اپنے محفوظ اور حسب ضرورت دعووں کی وضاحت کی ہے۔ ہم یہاں پرائیویٹ اور پبلک کلیمز کی بھی تعریف کر سکتے ہیں۔ یہ دونوں اپنی مرضی کے دعووں کے تحت آتے ہیں۔ ایک فوری نوٹ کے طور پر، ہم ان دونوں دعووں کے ساتھ جو چاہیں کر سکتے ہیں۔ تاہم عوامی دعووں کو IANA JSON ویب ٹوکن رجسٹری میں بیان کردہ دعووں کے طور پر کہا جاتا ہے۔ یہ ضروری ہے کہ ہم رجسٹری کے ساتھ ٹکراؤ سے بچنے کے لیے اپنے ٹوکن کو ایک خاص طریقے سے نام دیں۔ عوامی دعووں کو معیاری اختیاری کے طور پر بھی بیان کیا جا سکتا ہے۔ نجی دعوے کسی معیار کی پیروی نہیں کرتے اور ان کی وضاحت کرنا ہم پر منحصر ہے۔ پے لوڈ - یہ وہ جگہ ہے جہاں ہم تھوڑا تخلیقی ہو سکتے ہیں۔ دستخط اور کا ایک cyphered مجموعہ ہے. ہم اس الگورتھم کا فیصلہ کرتے ہیں جسے ہم استعمال کرنا چاہتے ہیں اور یہ ٹوکن بنیادی طور پر اس بات کا تعین کرے گا کہ آیا ہم جو پیغام بھیج رہے ہیں اس پر بھروسہ کیا جائے گا۔ یہ اس امتزاج کے لیے منفرد ہے اور ہمارا سرور اس "عوامی کلید" کا استعمال کرے گا جسے ہم نے یہ تعین کرنے کے لیے بنایا ہے کہ آیا ہمارے پاس کوئی مماثلت ہے۔ اگر آپ کو اوپر سے یاد ہے تو ہم اپنی مثال میں استعمال کر رہے ہیں۔ دستخط Header Payload RS256 اس سے پہلے کہ ہم جاری رکھیں، براہ کرم نوٹ کریں کہ ہماری مثال میں اور دونوں کو جا سکتا ہے۔ ہم صرف پے لوڈ یا ہیڈر کے ساتھ چھیڑ چھاڑ نہیں کر سکتے اور پھر بھی اسے قابل بھروسہ بناتے ہیں۔ نقصان دہ ٹوکن کے ممکنہ اثرات سے تحفظ صرف ہمارے منتخب کردہ الگورتھم کے ذریعے ہی محفوظ کیا جا سکتا ہے۔ اس لیے دانشمندی سے انتخاب کریں۔ اگر آپ کسی ایسی تنظیم میں کام کر رہے ہیں جہاں سرفہرست خفیہ معلومات ایک تشویش کا باعث ہیں، جیسے کہ بینک، تو براہ کرم وہ نہ کریں جو ہم کرنے والے ہیں۔ یہ ہمارے لیے مقامی طور پر بنائے گئے ٹوکنز کے مواد کو آن لائن چیک کرنے کا ایک طریقہ ہے۔ سب سے پہلے، آئیے پر جائیں اور اپنے ٹوکن کو پُر کریں۔ وہ ٹوکن استعمال کریں جو آپ نے ابھی تیار کیا ہے: Header Payload decyphered https://jwt.io/ JWT ہمارے ٹوکن کے مواد کو چیک کرنے کے لیے استعمال کرتے ہوئے آئیے اس بات کا جائزہ لیں کہ ہمارے پاس یہاں کیا ہے۔ یہ ہمارا ایڈمنسٹریٹر ٹوکن ہے۔ وہ شخص ہماری مثال میں "ایڈمن" ہے۔ ہم دیکھ سکتے ہیں کہ ہمارے پیرامیٹرز تمام دستیاب ہیں۔ ہماری فہرست میں ہم "sub"، "aud"، "upn"، "access"، "user_id"، "iss"، "name"، "groups" اور آخر میں "jti" دیکھتے ہیں۔ ہمارے پاس کچھ اضافی دعوے بھی ہیں۔ آئیے ان کو دیکھتے ہیں: https://jwt.io/ کا " " - یہ تب ہوتا ہے جب توثیق ہوتی ہے۔ ہمارا ٹوکن جیسا کہ اتوار، 17 جولائی 2022 16:15:47 GMT+02:00 DST " " کو تصدیق شدہ ہے — یہ تب ہوتا ہے جب ٹوکن بن جاتا ہے۔ ہمارے معاملے میں، یہ auth_time کے ساتھ ساتھ ہوتا ہے۔" " — یہ ٹوکن کی میعاد ختم ہونے کی تاریخ ہے۔ اس کی میعاد اتوار، 17 جولائی 2022 16:32:27 GMT+02:00 DST کو ختم ہوگی۔ ہم نے اپنے ٹوکن میں کوئی میعاد ختم ہونے کی تاریخ نہیں بتائی۔ اس کا مطلب ہے کہ اپنی ڈیفالٹ ویلیو ~15 منٹ استعمال کرتا ہے۔ auth_time iat exp JWT آئیے اب کچھ ٹیسٹ کرتے ہیں۔ 11. ایپلیکیشن چلانا کوڈ پر استعمال کرنے کے لیے تیار ہے۔ اگر ہم کوڈ چیک کرتے ہیں اور اسے Intellij کے ساتھ کھولتے ہیں تو ہمیں اس بات سے آگاہ ہونا چاہیے کہ ہم اس ایپلی کیشن کو اسپرنگ بوٹ ایپلی کیشن کی طرح نہیں چلا سکتے۔ اسے چلانے کے لیے کوئی "psvm" نہیں ہے۔ اس کے بجائے، ہم صرف تیار کردہ جار کو براہ راست چلا سکتے ہیں اور اس بات کو یقینی بنا سکتے ہیں کہ ہم اس سے پہلے ایک "mvn build" بنائیں۔ یہ ہے کہ میں اس وقت اسے کس طرح استعمال کر رہا ہوں: GitHub [ ] "ایپلیکیشن چلانے کے لیے ماحولیات کا سیٹ اپ") https://github.com/jesperancinha/your-finance-je آئیے اب " " اسکرپٹ کو دوبارہ چلائیں۔ مجھے نہیں معلوم کہ آپ کو یہاں پہنچنے میں کتنا وقت لگا لیکن اس بات کا بہت امکان ہے کہ اس وقت 15 منٹ پہلے ہی گزر چکے ہوں۔ صرف اس صورت میں، بس انہیں دوبارہ چلائیں۔ آئیے اپنی ایپ شروع کریں! ہم اسے اس طرح شروع کر سکتے ہیں: setupCertificates.sh mvn clean install java -jar your-financeje-banking/target/your-financeje-banking.jar یا ہم اسے اپنی تیار چلنے والی ترتیب کے ذریعے چلا سکتے ہیں۔ اگر آپ ہر چیز کو سمجھنا چاہتے ہیں تو پہلے سے ریپو اور میک فائل کو چیک کریں: make dcup-full-action یہ اسکرپٹ 2 سروسز چلائے گی۔ ایک پورٹ پر اور دوسرا پورٹ پر۔ پورٹ پر ہم اس سافٹ ویئر کا ایک ورژن چلائیں گے جو ٹوکن تیار کرنے کے لیے اپنا کوڈ چلاتا ہے۔ پورٹ 8081 پر، ہم کے بنائے ہوئے جنریٹر کا استعمال کرتے ہوئے ایک ورژن چلائیں گے۔ ہم اس مضمون پر توجہ مرکوز کریں گے، تاہم پورٹ پر چلنے والی سروس پر۔ اگر آپ چاہیں تو آپ اس کے ساتھ بھی چلا سکتے ہیں: 8080 8081 8080 JWT Adam Bien jwtknizr 8080 cypress make cypress-open اس سے کنسول گا، اور آپ اپنی پسند کے براؤزر کے ساتھ ٹیسٹ چلانے کے قابل ہو جائیں گے۔ تاہم، اس مرحلے پر براؤزر کے اختیارات ابھی تک محدود ہیں۔ زیادہ تر درخواستیں دراصل کی طرف سے فراہم کردہ کمانڈ لائن درخواستیں ہوں گی براہ کرم اپنے براؤزر پر جائیں اور اس مقام پر جائیں: cypress open cypress cypress http://localhost:8080/accounts/all ہمیں اس طرح کا نتیجہ ملنا چاہئے: جیسا کہ ہم دیکھ سکتے ہیں، " "، " "، اور " " کے پاس کوئی کریڈٹ یا پیسہ نہیں ہے۔ اس کی وجہ یہ ہے کہ انہیں صرف یوزر گروپ دیا گیا ہے۔ یہ بھی نوٹ کریں کہ کوئی کریڈٹ نہیں دیا گیا ہے۔ " "، ہمارا واحد کلائنٹ ہے جس کے پاس گروپ کریڈٹ نہیں ہے۔ اگر ہم لاگز کو دیکھیں تو ہم دیکھ سکتے ہیں کہ کامیاب آپریشنز اس فارمیٹ میں ہوتے ہیں: Malory Jack Fallout Jitska Shikka Shikka Sending money to admin HTTP/1.1 200 OK Date: Sun, 17 Jul 2022 15:01:13 GMT X-Powered-By: KumuluzEE/4.1.0 Content-Type: application/json Content-Length: 32 Server: Jetty(10.0.9) {"balance":212,"client":"Admin"} A 200 ہمیں بتاتا ہے کہ آپریشن کامیابی سے ہوا ہے۔ "مالوری"، "جیک فال آؤٹ" اور "جٹسکا" کی صورت میں، دونوں آپریشن ناکام ہو جاتے ہیں اور پھر ہمیں اس قسم کا پیغام ملے گا: Sending money to jitska HTTP/1.1 403 Forbidden X-Powered-By: KumuluzEE/4.1.0 Content-Length: 0 Server: Jetty(10.0.9) A 403 ہمیں بتاتا ہے کہ ہمارے ٹوکن کی توثیق ہو چکی ہے اور یہ قابل اعتماد ہے۔ تاہم، صارف کو یہ آپریشن کرنے سے منع کیا گیا ہے۔ دوسرے لفظوں میں، انہیں مقررہ طریقہ تک رسائی حاصل نہیں ہے۔ JWT آئیے اپنے ٹوکنز کے ساتھ تھوڑا سا چھیڑ چھاڑ کریں۔ اگر ہم sendMoney.sh فائل کے کچھ ٹوکن تبدیل کرتے ہیں۔ ہمیں یہ حاصل کرنا چاہئے: Sending money to admin HTTP/1.1 401 Unauthorized X-Powered-By: KumuluzEE/4.1.0 WWW-Authenticate: Bearer realm="MP-JWT" Content-Length: 0 Server: Jetty(10.0.9) فل سکرین موڈ میں داخل ہوں فل سکرین موڈ سے باہر نکلیں۔ اس کا مطلب ہے کہ ہمارے ٹوکن کی توثیق نہیں ہوئی تھی۔ اس کا مطلب ہے کہ وہ عوامی کلید جسے سرور یہ چیک کرنے کے لیے استعمال کرتا ہے کہ آیا ہمارے ٹوکن پر بھروسہ کیا جانا ہے، کوئی مماثلت نہیں ملی۔ اگر عوامی کلید JWT ٹوکن کے دستخط کی جانچ اور توثیق نہیں کر سکتی، تو یہ اسے مسترد کر دے گی۔ 401 ریکیپ کے طور پر، ہیڈر اور "پے لوڈ" کو خفیہ نہیں کیا گیا ہے۔ وہ صرف بیس 64 "انکوڈڈ" ہیں۔ اس کا مطلب یہ ہے کہ "ڈی کوڈنگ" ہمیں ہمیشہ اس کے اندر جھانکنے کی اجازت دیتی ہے کہ پے لوڈ اصل میں کیا ہے۔ اگر ہم اپنے پے لوڈ کو چھپنے سے بچانے کے لیے تلاش کر رہے ہیں، تو ہمیں کسی اور چیز کے لیے ٹوکن کا "پے لوڈ" استعمال نہیں کرنا چاہیے بلکہ شناختی پیرامیٹرز کو منتخب کرنا چاہیے۔ مسئلہ درحقیقت اس وقت ہوتا ہے جب کوئی ٹوکن پر ہاتھ ڈالتا ہے، مثال کے طور پر، جب TLS ٹنل سے سمجھوتہ کیا گیا ہو اور کوئی شخص تبادلہ شدہ پیغامات کے مواد کو پڑھنے کے قابل ہو۔ جب ایسا ہوتا ہے، تب بھی ایک اور تحفظ باقی رہتا ہے۔ اور یہ دستخط ہے۔ صرف ایک ہی جو پیغام میں جانے کی توثیق کر سکتا ہے وہ سرور ہے جس میں عوامی کلید موجود ہے۔ یہ عوامی کلید، اگرچہ عوامی ہے، صرف دستخط اور "ہیڈر + پے لوڈ" کے خلاف چل کر آنے والے پیغام کو درست کرنے کی اجازت دیتی ہے۔ JWT 12. نتیجہ ہم اپنے سیشن کے اختتام پر پہنچ چکے ہیں۔ اس پر عمل کرنے کے لیے آپ کا شکریہ۔ ہم دیکھ سکتے ہیں کہ ٹوکن کس طرح کمپیکٹ ہیں اور ان کے XML ہم منصب، ٹوکنز کے مقابلے میں بہت کم لفظی ہیں۔ ہم نے دیکھا ہے کہ مخصوص طریقوں کے لیے درکار اجازتیں حاصل کرنے کے لیے ٹوکن بنانا اور استعمال کرنا کتنا آسان ہے اور ہم دستخط شدہ ٹوکن کے ذریعے وہاں کیسے پہنچتے ہیں۔ مجھے کیسے کام کرتا ہے اس کا اندازہ حاصل کرنا بہت ضروری ہے۔ امید ہے کہ، اس کے ساتھ، میں نے آپ کو ٹوکنز کے کام کرنے کے بارے میں ایک اچھا تعارف دیا ہے۔ یہ سب کیسے کام کرتا ہے، اس کے بارے میں بہتر اندازہ حاصل کرنے کے لیے، میں آپ کو مشورہ دیتا ہوں کہ لاگو ٹیسٹوں کے ساتھ کھیلیں۔ یہ دیکھنے کا ایک بہترین طریقہ ہے کہ درخواستیں کیسے کی جا رہی ہیں اور ہم کس چیز کی جانچ کر رہے ہیں اور کیا توقع کی جا رہی ہے۔ اس کے بعد آپ کو یہ بھی بہتر اندازہ ہو جائے گا کہ کیوں کچھ صارفین کو کچھ آپریشنز کرنے پڑتے ہیں اور دوسرے کیوں نہیں کرتے۔ میں نے اس ایپلی کیشن کے تمام سورس کوڈ کو پر رکھ دیا ہے، مجھے امید ہے کہ آپ نے اس مضمون کو اتنا ہی لطف اندوز کیا ہو گا جتنا مجھے لکھنے میں آیا۔ پڑھنے کے لیے آپ کا شکریہ! JWT SAML JWT JWT cypress GitHub 13. حوالہ جات Eclipse MicroProfile JWT Authentication API مائیکرو پروفائل JSON ویب ٹوکن (JWT) JSON ویب ٹوکن کے دعوے کمولوز بلاگ kumuluzEE REST API سیکیورٹی آرام دہ API سیکیورٹی ٹیوٹوریل: جاوا میں JWTs بنائیں اور اس کی تصدیق کریں۔ oktadeveloper/okta-java-jwt-example اسپرنگ بوٹ CLI Java EE Security API (JSR 375/Soteria) JWT ٹوکنز کے ساتھ payara/Payara-مثالیں۔ JWT کے ساتھ JAX-RS اینڈ پوائنٹس کو محفوظ کرنا Eclipse MicroProfile JWT Auth کے ساتھ اپنی درخواست کو محفوظ کریں۔ جے ڈبلیو ٹی ڈسپنسر قابل ترتیب ٹوکن ایکسپائریشن 4.0.0 KumuluzEE مائیکرو پروفائل 1.2 کے ساتھ مائیکرو سروسز جے ڈبلیو ٹی کی توثیق: اسے کب اور کیسے استعمال کیا جائے۔ فرنٹ اینڈ کلائنٹس (GraphQL) پر JWTs کو ہینڈل کرنے کے لیے حتمی گائیڈ IANA JSON ویب ٹوکن (JWT) سائبر شیف KumuluzEE سیکیورٹی کا استعمال JSON ویب ٹوکنز (JWT) کا سادہ انگریزی تعارف: یہ کیا ہے اور کیا نہیں انٹرنیٹ انجینئرنگ ٹاسک فورس RFC7519