কেবলমাত্র "বৈধ" ব্যবহারের ক্ষেত্রে কীভাবে সেটকে সীমাবদ্ধ করবেন?


100

এর শক্তি সম্পর্কে আমি যত বেশি শিখি java.lang.reflect.AccessibleObject.setAccessible, ততই আমি আশ্চর্য হয়ে যাই যে এটি কী করতে পারে। এটি আমার প্রশ্নের উত্তর থেকে অভিযোজিত হয়েছে ( ইউনিট পরীক্ষার জন্য স্থির চূড়ান্ত ফাইল.সেস্পোর্টরচার পরিবর্তন করার প্রতিচ্ছবি ব্যবহার করে )।

import java.lang.reflect.*;

public class EverythingIsTrue {
   static void setFinalStatic(Field field, Object newValue) throws Exception {
      field.setAccessible(true);

      Field modifiersField = Field.class.getDeclaredField("modifiers");
      modifiersField.setAccessible(true);
      modifiersField.setInt(field, field.getModifiers() & ~Modifier.FINAL);

      field.set(null, newValue);
   }
   public static void main(String args[]) throws Exception {      
      setFinalStatic(Boolean.class.getField("FALSE"), true);

      System.out.format("Everything is %s", false); // "Everything is true"
   }
}

আপনি সত্যই আপত্তিকর জিনিস করতে পারেন:

public class UltimateAnswerToEverything {
   static Integer[] ultimateAnswer() {
      Integer[] ret = new Integer[256];
      java.util.Arrays.fill(ret, 42);
      return ret;
   }   
   public static void main(String args[]) throws Exception {
      EverythingIsTrue.setFinalStatic(
         Class.forName("java.lang.Integer$IntegerCache")
            .getDeclaredField("cache"),
         ultimateAnswer()
      );
      System.out.format("6 * 9 = %d", 6 * 9); // "6 * 9 = 42"
   }
}

সম্ভবত এপিআই ডিজাইনাররা বুঝতে পারে যে কীভাবে আপত্তিজনক setAccessibleহতে পারে তবে এটি অবশ্যই স্বীকার করে নিয়েছিল যে এটি সরবরাহ করার বৈধ ব্যবহার রয়েছে। সুতরাং আমার প্রশ্নগুলি হ'ল:

  • সত্যিকারের বৈধ ব্যবহারগুলি কী কী setAccessible?
    • প্রথমদিকে এই প্রয়োজনটি না থাকার জন্য কি জাভা তৈরি করা যেতে পারে?
    • এই ধরনের নকশার নেতিবাচক পরিণতি (যদি থাকে) কী হবে?
  • আপনি কি setAccessibleবৈধ ব্যবহারের জন্য সীমাবদ্ধ রাখতে পারেন ?
    • এর মাধ্যমেই কি হয় SecurityManager?
      • এটা কিভাবে কাজ করে? হোয়াইটলিস্ট / ব্ল্যাকলিস্ট, গ্রানুলারিটি ইত্যাদি?
      • আপনার অ্যাপ্লিকেশনগুলিতে এটি কনফিগার করা কি সাধারণ?
    • কনফিগারেশন setAccessibleনির্বিশেষে আমি কি আমার ক্লাসগুলিকে নিরর্থক হতে লিখতে পারি SecurityManager?
      • বা আমি যে কনফিগারেশন পরিচালনা করে তার করুণায়?

আমি আরও একটি গুরুত্বপূর্ণ প্রশ্ন অনুমান করি: আমি কি এই সম্পর্কে খুব বেশি প্রয়োজন?

আমার ক্লাসগুলির কোনওটিরই প্রয়োগযোগ্য গোপনীয়তার কোনও নজির নেই what সিঙ্গলটন প্যাটার্ন (এর গুণাগুণ সম্পর্কে সন্দেহ রেখে) এখন কার্যকর করা অসম্ভব। আমার উপরের স্নিপেটগুলি যেমন দেখায়, জাভা মৌলিক কাজগুলি কীভাবে গ্যারান্টিযুক্ত হওয়ার কাছাকাছি নয় তার কিছু প্রাথমিক ধারণাও।

এই সমস্যাগুলি কি বাস্তব নয় ???


ঠিক আছে, আমি কেবল নিশ্চিত করেছি: ধন্যবাদ setAccessible, জাভা স্ট্রিংগুলি পরিবর্তনযোগ্য নয়

import java.lang.reflect.*;

public class MutableStrings {
   static void mutate(String s) throws Exception {
      Field value = String.class.getDeclaredField("value");
      value.setAccessible(true);
      value.set(s, s.toUpperCase().toCharArray());
   }   
   public static void main(String args[]) throws Exception {
      final String s = "Hello world!";
      System.out.println(s); // "Hello world!"
      mutate(s);
      System.out.println(s); // "HELLO WORLD!"
   }
}

আমি কি কেবলমাত্র এই ব্যক্তিটিকেই একটি বিশাল উদ্বেগ বলে মনে করি?


30
তারা দেখতে হবে যে তারা সি ++ এ কী করতে পারে! (ওহ, এবং সম্ভবত সি #।)
টম হাটিন -

উত্তর:


105

আমি কি এই সম্পর্কে খুব বেশি প্রয়োজন?

এটি সম্পূর্ণরূপে নির্ভর করে আপনি কী ধরণের প্রোগ্রাম লিখছেন এবং কোন ধরণের আর্কিটেকচারের জন্য।

যদি আপনি foo.jar নামক একটি সফ্টওয়্যার উপাদান বিশ্বব্যাপী বিতরণ করে থাকেন তবে আপনি যেভাবেই হোক তাদের সম্পূর্ণ করুণায় রয়েছেন। তারা আপনার .জারের ভিতরে শ্রেণি সংজ্ঞা সংশোধন করতে পারে (বিপরীত প্রকৌশল বা সরাসরি বাইটকোড ম্যানিপুলেশন মাধ্যমে)। তারা আপনার নিজস্ব জেভিএম ইত্যাদিতে আপনার কোডটি চালাতে পারে this এই ক্ষেত্রে উদ্বেগজনক হওয়ার কারণে আপনার কোনও উপকার হবে না।

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

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

আপনি যদি জাভা অ্যাপলেটগুলি লিখতে চলেছেন তবে সুরক্ষা কাঠামো এমন একটি বিষয় যা আপনার সচেতন হওয়া উচিত। আপনি দেখতে পাবেন যে সেট-অ্যাক্সেসেবল কল করার চেষ্টা করছে এমন স্বাক্ষরযুক্ত অ্যাপলেটগুলি কেবলমাত্র একটি সিকিউরিটি এক্সসেপশনের ফলাফল করবে।

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

একটি স্যান্ডবক্সযুক্ত পরিবেশে (উদাহরণস্বরূপ জাভা অ্যাপলেটস, জাভাএফএক্স), প্রতিটি শ্রেণীর অনুমতি এবং অনিরাফায় অ্যাক্সেসের সেট থাকে, সেট অ্যাক্সেসযোগ্য এবং সংজ্ঞায়িত দেশীয় বাস্তবায়ন সিকিউরিটি ম্যানেজার দ্বারা নিয়ন্ত্রিত হয়।

"জাভা অ্যাক্সেস মডিফায়ারগুলির উদ্দেশ্য সুরক্ষা ব্যবস্থা নয় not"

এটি জাভা কোডটি কোথায় চালানো হচ্ছে তার উপর নির্ভর করে। মূল জাভা ক্লাসগুলি স্যান্ডবক্স প্রয়োগের জন্য সুরক্ষা ব্যবস্থা হিসাবে অ্যাক্সেস মডিফায়ার ব্যবহার করে।

সেট অ্যাক্সেসেবলের জন্য সত্যিকারের বৈধ ব্যবহারগুলি কী কী?

জাভা কোর ক্লাসগুলি সুরক্ষার কারণে ব্যক্তিগত থাকতে হবে এমন স্টাফ অ্যাক্সেসের সহজ উপায় হিসাবে এটি ব্যবহার করে। উদাহরণস্বরূপ, জাভা সিরিয়ালাইজেশনের কাঠামো ব্যক্তিগত অবজেক্ট কনস্ট্রাক্টরদের অনুরোধ করতে ব্যবহার করে যখন অবজেক্টগুলি ডিসরিয়ালাইজ করা হয়। কেউ System.setErr উল্লেখ করেছেন, এবং এটি একটি ভাল উদাহরণ হতে পারে তবে কৌতূহলতার সাথে সিস্টেম শ্রেণির পদ্ধতিগুলি setOut / setErr / setIn চূড়ান্ত ক্ষেত্রের মান নির্ধারণের জন্য সমস্ত নেটিভ কোড ব্যবহার করে।

আর একটি সুস্পষ্ট বৈধ ব্যবহার ফ্রেমওয়ার্ক (অধ্যবসায়, ওয়েব ফ্রেমওয়ার্ক, ইনজেকশন) যা বস্তুর অভ্যন্তরে উঁকি দেওয়া দরকার।

ডিবাগাররা, আমার মতে, এই বিভাগে পড়বেন না, কারণ তারা সাধারণত একই জেভিএম প্রক্রিয়াতে চলে না, বরং পরিবর্তে অন্য উপায় (জেপিডিএ) ব্যবহার করে জেভিএমের সাথে ইন্টারফেস করে।

প্রথমদিকে এই প্রয়োজনটি না থাকার জন্য কি জাভা তৈরি করা যেতে পারে?

ভাল উত্তর দেওয়ার জন্য এটি বেশ গভীর প্রশ্ন। আমি হ্যাঁ ভাবছি, তবে আপনাকে এমন কিছু মেকানিজম যুক্ত করতে হবে যা পছন্দসই নয়।

আপনি কি বৈধ ব্যবহারের জন্য সেটকে অ্যাক্সেসযোগ্যকে সীমাবদ্ধ রাখতে পারবেন?

আপনি সর্বাধিক সোজা-ফরোয়ার্ড ওওটিবি নিষেধাজ্ঞার আবেদন করতে পারেন হ'ল সিকিউরিটি ম্যানেজার রাখা এবং নির্দিষ্ট উত্স থেকে আসা কোডগুলিতে সেট অ্যাক্সেসযোগ্যকে মঞ্জুরি দেওয়া। জাভা এটি ইতিমধ্যে করে - আপনার জাভাআহোম থেকে আসা স্ট্যান্ডার্ড জাভা ক্লাসগুলিকে সেটঅ্যাক্সেসযোগ্য করার অনুমতি দেওয়া হয়, যখন foo.com থেকে স্বাক্ষরযুক্ত অ্যাপলেট ক্লাসগুলি সেট-অ্যাক্সেসযোগ্য করার অনুমতি দেয় না। যেমনটি আগেই বলা হয়েছিল, এই অনুমতিটি বাইনারি, এই অর্থে যে কারও কাছে তা আছে বা নেই। সেটকে অ্যাক্সেসযোগ্যকে নির্দিষ্ট ক্ষেত্র / পদ্ধতিগুলি অন্যকে বারণ করার সময় মঞ্জুরি দেওয়ার অনুমতি দেওয়ার কোনও সুস্পষ্ট উপায় নেই। সিকিউরিটি ম্যানেজার ব্যবহার করে আপনি ক্লাসগুলি নির্দিষ্ট প্যাকেজগুলি সম্পূর্ণরূপে, প্রতিফলনের সাথে বা ছাড়াই রেফারেন্স থেকে বঞ্চিত করতে পারেন।

সিকিউরিটি ম্যানেজার কনফিগারেশন নির্বিশেষে আমি কি আমার ক্লাসগুলি সেট-অ্যাক্সেসযোগ্য-প্রমাণ হিসাবে লিখতে পারি? ... বা আমি যে কনফিগারেশন পরিচালনা করে তার রহমতে আমি আছি?

আপনি পারবেন না এবং আপনি অবশ্যই।


"আপনি যদি বিশ্বের মানুষের কাছে foo.jar নামক একটি সফ্টওয়্যার উপাদান বিতরণ করে থাকেন তবে আপনি যেভাবেই হোক সম্পূর্ণরূপে তাদের করুণায় They আপনার কোডটি তাদের নিজের জেভিএম ইত্যাদিতে চালাতে পারে this এটা কি এখনও আছে? সফ্টওয়্যারকে আরও শক্তভাবে টেম্পার করার বিষয়ে কোনও পরামর্শ (আশা করি উল্লেখযোগ্যভাবে)? এজন্য কেবল জাভা ডেস্কটপ অ্যাপ্লিকেশনগুলি উইন্ডো থেকে ফেলে দেওয়া কঠিন।
সেরো

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

ডানুভো কেমন?
সেরো

15
  • সত্যিকারের বৈধ ব্যবহারগুলি কী কী setAccessible?

ইউনিট টেস্টিং, জেভিএমের অভ্যন্তরীণ (যেমন প্রয়োগ করা System.setError(...)) এবং আরও অনেক কিছু।

  • প্রথমদিকে এই প্রয়োজনটি না থাকার জন্য কি জাভা তৈরি করা যেতে পারে?
  • এই ধরনের নকশার নেতিবাচক পরিণতি (যদি থাকে) কী হবে?

প্রচুর জিনিস অপরিহার্য হবে। উদাহরণস্বরূপ, বিভিন্ন জাভা অধ্যবসায়, সিরিয়ালাইজেশন এবং নির্ভরতা ইনজেকশনগুলি প্রতিফলনের উপর নির্ভরশীল। এবং রানটাইমের সময় জাভাবিয়ান কনভেনশনগুলির উপর নির্ভর করে এমন অনেক কিছুই।

  • আপনি কি setAccessibleবৈধ ব্যবহারের জন্য সীমাবদ্ধ রাখতে পারেন ?
  • এর মাধ্যমেই কি হয় SecurityManager?

হ্যাঁ.

  • এটা কিভাবে কাজ করে? হোয়াইটলিস্ট / ব্ল্যাকলিস্ট, গ্রানুলারিটি ইত্যাদি?

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

  • আপনার অ্যাপ্লিকেশনগুলিতে এটি কনফিগার করা কি সাধারণ?

না

  • কনফিগারেশন setAccessibleনির্বিশেষে আমি কি আমার ক্লাসগুলিকে নিরর্থক হতে লিখতে পারি SecurityManager?
    • বা আমি যে কনফিগারেশন পরিচালনা করে তার করুণায়?

না আপনি পারবেন না, এবং হ্যাঁ আপনি আছেন।

অন্য বিকল্পটি উত্স-কোড বিশ্লেষণ সরঞ্জামগুলির মাধ্যমে এটিকে "প্রয়োগ" করা; যেমন কাস্টম pmdবা findbugsবিধি। অথবা কোড দ্বারা নির্বাচিত কোড পর্যালোচনা (বলে) দ্বারা চিহ্নিত grep setAccessible ...

ফলোআপের জবাবে

আমার ক্লাসগুলির কোনওটিরই প্রয়োগযোগ্য গোপনীয়তার কোনও নজির নেই what সিঙ্গলটন প্যাটার্ন (এর গুণাগুণ সম্পর্কে সন্দেহ রেখে) এখন কার্যকর করা অসম্ভব।

যদি এটি আপনাকে চিন্তিত করে, তবে আমি মনে করি আপনার চিন্তা করা দরকার। তবে সত্যই আপনার অন্য প্রোগ্রামারদের আপনার নকশার সিদ্ধান্তগুলিকে সম্মান করতে বাধ্য করার চেষ্টা করা উচিত নয় । লোকেরা যদি আপনার সিঙ্গলটনের একাধিক উদাহরণ তৈরি করতে (যেমন উদাহরণস্বরূপ) প্রতিফলনটি ব্যবহার করতে যথেষ্ট বোকা হয় তবে তারা পরিণতি নিয়ে বেঁচে থাকতে পারে।

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

<স্ট্রিং এর উদাহরণ> - আমি একমাত্র এই ব্যক্তি যাকে মনে হয় এটি একটি বিশাল উদ্বেগ?

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

আপনার বিকাশ বা অপারেশন দলে কোনও "খারাপ অভিনেতা" সমস্যাটি মোকাবেলার (বা প্রশমিত) উপায় রয়েছে। তবে এগুলি ব্যয়বহুল এবং সীমাবদ্ধ ... এবং বেশিরভাগ ব্যবহারের ক্ষেত্রে ওভারকিল।


4
অধ্যবসায় বাস্তবায়নের মতো বিষয়গুলির জন্যও দরকারী। প্রতিচ্ছবি সত্যই ডিবাগারদের জন্য কার্যকর নয় (যদিও এটি মূলত উদ্দিষ্ট ছিল)। আপনি এর জন্য কার্যকরভাবে (সাবক্লাস) পরিবর্তন করতে পারবেন না SecurityManager, কারণ যা যা পান তা কেবল অনুমতি চেক - আপনি যা করতে পারেন তা হ'ল এ্যাকটি দেখুন এবং সম্ভবত স্ট্যাকটি বর্তমান থ্রেডটি চেক করা উচিত)। grep java.lang.reflect.
টম হাটিন -

@ স্টেফেন সি: ইতিমধ্যে +1, তবে আমি আরও যুক্ত করা আরও একটি প্রশ্নে আপনার ইনপুটটিরও প্রশংসা করব। আগাম ধন্যবাদ.
বহুবিশ্লেষকরা

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

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

@ জুলস - বেশিরভাগ জাভা বিশেষজ্ঞরা এর সাথে একমত নন; উদাহরণস্বরূপ stackoverflow.com/questions/9201603/…
স্টিফেন সি

11

প্রতিবিম্ব প্রকৃতপক্ষে এই দৃষ্টিভঙ্গির অধীনে সুরক্ষা / সুরক্ষার জন্য অর্থেগোনাল।

আমরা প্রতিবিম্বকে কীভাবে সীমাবদ্ধ রাখতে পারি?

জাভাতে সুরক্ষা পরিচালক এবং ClassLoaderএর সুরক্ষা মডেলের ভিত্তি হিসাবে রয়েছে। আপনার ক্ষেত্রে, আমার ধারণা আপনার দিকে নজর দেওয়া দরকার java.lang.reflect.ReflectPermission

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

ভবিষ্যতে মূলধারার হয়ে উঠতে পারে এমন একটি পদ্ধতির নাম ক্লাস থেকে প্রতিবিম্বিত ক্ষমতা পৃথক করার জন্য তথাকথিত মিরর ব্যবহার । মিররগুলি দেখুন : মেটা-স্তরের সুবিধার্থে ডিজাইনের নীতিগুলি । এই সমস্যাটি মোকাবেলা করে এমন আরও বিভিন্ন গবেষণা রয়েছে । তবে আমি একমত যে স্থির ভাষাগুলির চেয়ে গতিময় ভাষার জন্য সমস্যাটি আরও গুরুতর।

প্রতিবিম্ব যে প্রতিফলন দেয় তা কি আমাদের চিন্তিত হওয়া উচিত? হ্যা এবং না.

হ্যাঁ এই বিবেচনায় যে জাভা প্ল্যাটফর্মটি সুরক্ষিত করা উচিত Classloaderএবং সুরক্ষার ব্যবস্থাপক। প্রতিবিম্বের সাথে গোলযোগ করার ক্ষমতাটি লঙ্ঘন হিসাবে দেখা যেতে পারে।

কোন অর্থে সম্পূর্ণরূপে নিরাপদ নয় যে অধিকাংশ সিস্টেমের যাহাই হউক না কেন আছে। প্রচুর ক্লাস প্রায়শই সাবক্ল্যাস করা যেতে পারে এবং আপনি সম্ভবত এটি ইতিমধ্যে সিস্টেমটির অপব্যবহার করতে পারেন। অবশ্যই ক্লাসগুলি তৈরি করা যায় final, বা সিল করা যায় যাতে সেগুলি অন্যান্য জারে সাবক্ল্যাস করা যায় না। তবে কেবলমাত্র কয়েকটি ক্লাসই সঠিকভাবে সুরক্ষিত (যেমন স্ট্রিং)।

একটি দুর্দান্ত ব্যাখ্যার জন্য চূড়ান্ত শ্রেণি সম্পর্কে এই উত্তরটি দেখুন । আরও দেখুন থেকে ব্লগটিকে সামি Koivu আরো জাভা নিরাপত্তা প্রায় ফাটান জন্য।

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

সুরক্ষা যে কোনওভাবে আপেক্ষিক তা লক্ষ করাও গুরুত্বপূর্ণ । ভাষা স্তরে, আপনি উদাহরণস্বরূপ কোনও মডিউল ফর্ম 100% সিপিইউ গ্রহণ করে বা একটি পর্যন্ত সমস্ত মেমরি গ্রাস করতে বাধা দিতে পারবেন না OutOfMemoryException। এই জাতীয় উদ্বেগের সমাধান অন্যান্য উপায়ে করা উচিত। আমরা সম্ভবত ভবিষ্যতে জাভা রিসোর্স ব্যবহারের কোটা দিয়ে প্রসারিত দেখতে পাব, তবে এটি কালকের জন্য নয় :)

আমি এই বিষয়ে আরও প্রসারিত করতে পারি, তবে আমি মনে করি আমি আমার বক্তব্য রেখেছি।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.