Вне классов, получающих доступ к закрытым методам пакета
Предположим, что у меня есть класс в моем пакете org.jake и это имеет метод с доступом по умолчанию (никакой модификатор). Затем метод видим в пакете только.
Однако, когда кто-то получает банку моей платформы, что должно мешать им писать новый класс, объявляя его пакет как org.jake, и использование моего, предположительно, невидимого метода?
Другими словами, есть ли что-нибудь, что я могу сделать для предотвращения этого?
4 ответа
Вы можете запечатать пакет в своем jar-файле. Однако это не пуленепробиваемое.
Главное - не полагаться на модификаторы доступа и т. Д. С точки зрения безопасности, с самого начала. Если кто-то запускает код с неограниченными разрешениями, у него будет доступ ко всем вещам. Модификаторы доступа на самом деле просто помогают предотвратить случайное ранение себя в ногу.
Если кто-то желает поместить классы в ваш пакет, чтобы обойти вашу инкапсуляцию, он явно игнорирует ваши лучшие намерения - я говорю, позвольте им заняться этим, но не поддерживайте этот сценарий.
Я бы сказал, просто не позволяйте им запускать код там, где он может вызывать ваш, то есть в той же JVM. Вместо этого вы можете рассмотреть возможность предложения только (веб-службы), которую они могут вызывать извне. Однако я не очень осведомлен о лучших способах реализации этого.
Вы ничего не можете сделать, чтобы предотвратить это. Даже частные члены могут быть доступны через отражение. Вы должны рассматривать модификаторы доступа в java просто как наводящие на размышления.
Во-первых, это сценарий «DRM»: в конце концов, кто-то решил достаточно может обойти любую установленную вами защиту, предоставив модную модифицированную среду выполнения или другие подобные вещи. Обратный сценарий - когда среда выполнения является надежной, а некоторые пакеты - нет - должным образом решается Java с помощью подходящих ограничений ClassLoader , но это может работать только там, где есть что-то, что может обеспечить соблюдение ограничений в проверенная мода; вот почему ваш сценарий в основном обречен.
Однако , если мы предполагаем, что сама среда выполнения заслуживает доверия , то вы можете попробовать в своем суперсекретном методе получить трассировку стека текущего выполняющегося стека (см. stackoverflow.com/ questions / 1069066 /… , чтобы узнать, является ли вызывающий текущий метод тем, кому вы доверяете получить доступ. Диспетчер безопасности был бы даже более подходящим, но вы не можете доверять среде, которая установит один из тех, которые вам нравятся (гораздо более очевидно, что это находится под контролем злоумышленника). Обратите внимание, что я не пробовал варианты в этом абзаце!
Другой вариант - поместить свои секреты в службу, которую вы контролируете, и предлагать только удаленный доступ к ним. Или перестаньте беспокоиться об использовании технических механизмов для решения проблемы, которая в основном связана с деловыми и юридическими вопросами (например, почему вы имеете дело с людьми, которым не можете доверять?)