কেন একটি একক পৃষ্ঠার অ্যাপ্লিকেশনটিতে লগইন পৃষ্ঠাটি পৃথক পৃষ্ঠা তৈরি করবেন?


28

আমি ভাবছি যে কেন এসপিএর লগইন পৃষ্ঠাটি আলাদা আলাদা পৃষ্ঠা যা এসপিএর পৃষ্ঠা নয় (যেমন অ্যাজাক্স অনুরোধের মাধ্যমে ডেটা লোড করা এবং প্রেরণ করা) নয়?

আমি কেবল যে বিষয়টিকে আমি সুরক্ষা হিসাবে ভাবতে পারি তা হ'ল তবে আমি সুনির্দিষ্ট সুরক্ষার কারণটি ভাবতে পারি না। আমি মনে করি কেবলমাত্র একটি জিনিস মনে আসবে তা হ'ল এসপিএর অংশে আপনার লগইন পৃষ্ঠাটি, এটি এজাক্সের মাধ্যমে ব্যবহারকারীর নাম / পাসওয়ার্ড প্রেরণ করে যা ফায়ারব্যাগ বা ওয়েব পরিদর্শকের মতো সরঞ্জামগুলি দ্বারা দেখা যেতে পারে তবে আপনি এটি সাধারণ হিসাবে প্রেরণ করলেও অনুরোধ করুন, এমন অন্যান্য সরঞ্জাম রয়েছে যা সহজেই এই ডেটা ক্যাপচার করতে পারে (যেমন ফিজার, httpscop, ইত্যাদি ...)।

আমি কি অনুপস্থিত কিছু আছে?


2
আমি মনে করি না এই ক্ষেত্রে কোনও কারণ আছে বা হওয়া দরকার। আমি তর্ক করব, কেন নয়?
স্টিভেন ইভার্স

1
এর বিপরীতে আমার যুক্তিটি হ'ল লগইন পৃষ্ঠাটি পৃথক এইচটিএমএল পৃষ্ঠা হিসাবে থাকাকালীন বাকী অ্যাপ্লিকেশনটি এসপিএ আর্কিটেকচারের কোনও বাস্তব সুবিধা ছাড়াই অদ্ভুত বলে মনে হয় (যদিও তৈরি পয়েন্ট এমসানফোর্ডের যোগ্যতা নেই)।
রায়ানজেক

@ রিয়ানজেক ধন্যবাদ প্রকৃত উপকার আছে তা বোঝানোর চেষ্টায় আমি একটি উদাহরণ যুক্ত করেছি। প্রথমত, অন্য কোথাও পিছনে থাকা সম্পদ লোডিংয়ের সঞ্চয় তুচ্ছ নয়, বিশেষত ব্যর্থ লগইনের ক্ষেত্রে (বা অ্যাকাউন্ট স্থগিতকরণ ইত্যাদি)। দ্বিতীয়ত, আরও পরিশীলিত অ্যাসিনক্রোনাস নির্ভরতা-ভিত্তিক মডিউল সিস্টেমের তুলনায় এটি প্রয়োগ করা আরও দ্রুত এবং বিকাশ জীবনকাল একটি গুরুত্বপূর্ণ বিবেচ্য বিষয় ( ওপবিটের অফিস মন্ত্র * দেখুন (অশ্লীলতা রয়েছে))।
মিশনফোর্ড

"আপনি যদি এটি একটি সাধারণ পোস্ট অনুরোধ হিসাবে প্রেরণ করেন তবে এমন অন্যান্য সরঞ্জাম রয়েছে যা সহজেই এই ডেটা ক্যাপচার করতে পারে"। অবশ্যই আপনার লগইন ফর্মটি এইচটিটিপিএস দ্বারা সুরক্ষিত ?
আজলানে

@ আজলেন হ্যাঁ, আমার লগইন (এবং আসলে পুরো অ্যাপ্লিকেশন) এইচটিটিপিএসের পিছনে চলতে চলেছে
রায়ানজেক

উত্তর:


18

সম্ভবত এটি কেবলমাত্র অ্যাপ্লিকেশনের জন্য প্রয়োজনীয় ক্লায়েন্ট-সাইড সম্পদগুলির (যেমন ভারী জাভাস্ক্রিপ্ট ফ্রেমওয়ার্ক, চিত্রগুলি ইত্যাদির ) একগুচ্ছ লোড করা সঞ্চয় করা।

অনুরূপ পারফরম্যান্স লক্ষ্য অর্জনের আরও পরিশীলিত উপায় রয়েছে (" মাল্টে ইউবিএল এবং জন এইচেলমস্টাড: একটি উপন্যাস, জাভাস্ক্রিপ্ট লোডিংয়ের কার্যকর পদ্ধতির - জেএসকনফ ইইউ 2012 " দেখুন) তবে এটি কার্যকর করার পক্ষে যথেষ্ট দ্রুত এবং তর্কসাপেক্ষভাবে ঠিক তত দক্ষ, বিশেষত যদি আপনার ওয়েব অ্যাপ্লিকেশন যাইহোক আপনার প্রায় সমস্ত সম্পদ ব্যবহার করে।

আপনি http://infogr.am বিটা এর মতো কোনও সাইটে বুনোতে দেখতে পাবেন :

  1. http://infogr.am/login/ jquery , রাফেল , কাস্টম জেএস এবং 3 সিএসএস ফাইললোডকরে।
  2. http://infogr.am/beta/ (অ্যাপ্লিকেশনটির মূল এসপিআই পৃষ্ঠা) 10 জাভাস্ক্রিপ্ট ফ্রেমওয়ার্ক, 5 বহিরাগত CSS ফাইল এবং প্রায় 60 টি চিত্র লোড করে।

আপডেট: ২০১ 2016 সালে কৌণিক 2 ফ্রন্ট-এন্ড এবং জেবিস ব্যাক-এন্ড সহ আমরা এখনও একই কারণে এটি করি।
মিসানফোর্ড

18

আমি মনে করি এর পক্ষে বা বিপক্ষে কিছু যুক্তিযুক্ত যুক্তি রয়েছে এবং আমি বলব প্রযুক্তিও সিদ্ধান্তে ভূমিকা রাখে।

একটি পৃথক লগইন "পৃষ্ঠা" থাকার কারণে তর্ক হতে পারে "ডিরেক্টরি সুরক্ষা" ব্যবহার সক্ষম করে। সাধারণত যে কেউ লগইন "পৃষ্ঠা" দেখতে পারে তবে কেবল অনুমোদিত ব্যবহারকারীরা "পৃষ্ঠা" এর অ্যাপ্লিকেশনটি দেখতে পাবে এবং এটি "ডিরেক্টরি"। রুটগুলি লকওডও করা যেতে পারে, যেখানে / অ্যাকাউন্ট / / অ্যাপের চেয়ে পৃথক এবং প্রত্যেকটির নিজস্ব সুরক্ষা "প্রোফাইল" থাকে।

এছাড়াও, যদি আপনি একটি এসপিএ পদ্ধতির ব্যবহার করেন এবং আপনি প্রয়োগের অভিজ্ঞতার সাথে প্রমাণীকরণের মিশ্রণ করছেন তবে যুক্তিটি সংশ্লেষিত হতে পারে। ব্যবহারকারীকে "তারা এখানে থাকার কারণে" লগ ইন করা হয়েছে "ধরে নেওয়ার পরিবর্তে, আপনাকে ক্রমাগত তাদের প্রমাণীকরণের স্থিতি পরীক্ষা করতে হবে এবং" এই ব্যবহারকারীর এখানে থাকা উচিত "জিজ্ঞাসা করতে হবে।

এছাড়াও, লগইন পৃষ্ঠাটি সাধারণত ভোক্তাদের মুখোমুখি সাইটে থাকে .. আপনি www.yourapp.com এ যান এবং এতে তথ্য, যোগাযোগ, সমর্থন ইত্যাদি .. এবং একটি "লগইন" পৃষ্ঠা সম্পর্কে আছে .. লগইন পৃষ্ঠা থেকে প্রমাণীকরণ, আপনি লক্ষ্যগুলি সম্পূর্ণ হোস্টে পুনঃনির্দেশ করতে পারে ..

আমি পৃথক লগইন পৃষ্ঠা রাখার কারণ এবং আমার "গ্রাহক মুখোমুখি" সাইটের জন্য আমার কেন সম্পূর্ণ আলাদা অ্যাপ রয়েছে তা কারণ আমি অচিহ্নহীনদের কাছে খুব সামান্যই প্রকাশ করতে পারি। সুযোগমতো কিছু মরন আমার লগইন পৃষ্ঠায় বেজে উঠতে শুরু করে, আমি চাই না যে অ্যাপ্লিকেশনটির দিকটি প্রভাবিত করা হোক .. এমনকি লগইনটি যদি কেবল একটি সাধারণ লেখককে দেখায় তবে .. এটি আমাকে বোজোকে আমার প্রভাবিত করা থেকে বিরত রাখতে সহায়তা করে ব্যবহারকারীদের অভিজ্ঞতা .. সবচেয়ে খারাপ ক্ষেত্রে, আমার ভোক্তা সাইটটি নীচে যায় এবং কেউ লগইন করতে পারে না, তবে কমপক্ষে লগইন করা ব্যবহারকারীরা জানেন না এবং তাদের অভিজ্ঞতা ধীর শুরু করবে না .. আমি বলছি না এটি বুলেট প্রুফ পছন্দ ... তবে কমপক্ষে আমি অস্বীকৃত অঞ্চল থেকে ঝুঁকি বিচ্ছিন্ন করে দিয়েছি ..


1
সুরক্ষা প্রায়শই একটি বড় কারণ।
জাস্টিনসি

1
@ জাস্টিনসি: আরও সুরক্ষিত লগইনের জন্য আমাকে একটি পৃথক পৃষ্ঠায় ব্যাখ্যা করুন?
রায়ানজেক

ফাইল সিস্টেমের অ্যাট্রিবিউটগুলির মাধ্যমে অগত্যা নয় (তবে এটি পরিস্থিতিটি যা বলে তা বোঝায়) তবে ওয়েব অ্যাপ্লিকেশন ধারক / সার্লেট সফটওয়্যার / একটি নির্দিষ্ট সংস্থায় প্রয়োগ করা বা নির্বাচিত প্রমাণীকরণ / অনুমোদনের পদ্ধতি প্রয়োগের মাধ্যমে রানটাইম বা কোনও সংস্থান গোষ্ঠীতে প্রয়োগ করা যেতে পারে সামগ্রিকভাবে (ব্যবহারিক শর্তাবলী, একটি ডিরেক্টরি): লগইন পৃষ্ঠা এবং নির্দিষ্ট স্থিতিশীল সংস্থানগুলির জন্য (চিত্র, স্টাইলশিট, ত্রুটি পৃষ্ঠা), বেনামে অ্যাক্সেস প্রায়শই যথেষ্ট; অন্যান্য পৃষ্ঠাগুলির জন্য, আরও নির্দিষ্ট প্রমাণীকরণ / অনুমোদনের প্রয়োজন হতে পারে।
জাস্টিনসি

2
অ্যাপের বাইরে প্রমাণীকরণ করা প্রমাণীকরণটিকে অ্যাপের উদ্বেগ থেকে দূরে রাখে। প্রকৃত সুরক্ষা বাস্তবায়ন এবং প্রযুক্তির উপর নির্ভর করবে
হাঞ্জোলো

আপডেট 2017: আইডেন্টিটি
সার্ভার

10

এটি করার একটি কারণ হ'ল আপনি তারপরে সাধারণ কুকি ভিত্তিক সেশনগুলি ব্যবহার করতে পারেন। ব্যবহারকারীর লগ ইন, প্রতিক্রিয়া প্রারম্ভিক প্রধান পৃষ্ঠার সাথে কুকি প্রেরণ করে ... এবং তারপরে সমস্ত অ্যাজাক্স কল কুকিকে সার্ভারে ফিরে পাঠায়।


6

আমি এটি করার কয়েকটি কারণ দেখছি:

  1. আমি ওয়েব.এক্সএমএল এ সাধারণ পাথ-ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণের নিয়ম ব্যবহার করতে পারি।
  2. আমি কখনই নিশ্চিত হতে পারি না যে আমি আমার পুরো অ্যাজাক্স অ্যাপ্লিকেশনটি সঠিকভাবে সুরক্ষিত করেছি এবং আত্মবিশ্বাসের জন্য আমার বিস্তৃত পরীক্ষা করা দরকার।
  3. আমি কোনও ফ্রেমওয়ার্কে (যেমন স্প্রিং সিকিউরিটি), একটি তৃতীয় পক্ষের অ্যাপ্লিকেশন, বা এসএসও সমাধান (সিএএস বা জাসসো) এর মতো প্রমাণীকরণ পেশ করতে পারি।
  4. আমি ব্রাউজারটিকে ব্যবহারকারীর নাম এবং (বিকল্পভাবে) ব্যবহারকারীর জন্য পাসওয়ার্ড দিতে পারি।
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.