外部类访问包私有方法
假设我的包 org.jake 中有一个类，并且它有一个具有默认访问权限（无修饰符）的方法。那么该方法仅在包内部可见。
然而，当有人收到我的框架的 jar 时，如何阻止他们编写新类、将其包声明为 org.jake 并使用我所谓的不可见方法？
换句话说，我能做些什么来防止这种情况发生吗？
Suppose I have a class in my package org.jake and it has a method with default access (no modifier). Then the method is visible inside the package only.
However, when someone receives the jar of my framework, what is to stop them from writing a new class, declaring its package as org.jake, and using my supposedly invisible method?
In other words, is there anything I can do to prevent this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可以在 jar 文件中密封包。但它并不是防弹的。
最重要的是，从安全角度来看，一开始就不要依赖访问修饰符等，真的。如果有人以不受限制的权限运行代码，他们将可以访问各种内容。访问修饰符实际上只是有助于防止人们不小心搬起石头砸自己的脚。
如果有人愿意将类放入您的包中以规避您的封装，那么他们显然会忽略您的最佳意图 - 我说让他们继续这样做，但不要为这种情况提供支持。
You could seal the package in your jar file. It's not bullet-proof though.
The main thing is not to rely on access modifiers etc from a security point of view to start with, really. If someone is running the code with unrestricted permissions, they're going to have access to all kinds of things. Access modifiers really just help to stop people from accidentally shooting themselves in the foot.
If someone is willing to put classes in your package to circumvent your encapsulation, they're clearly ignoring your best intentions - I say let 'em get on with it, but don't provide support for that scenario.
您无法阻止这种情况发生。即使是私有成员也可以通过反射来访问。您应该认为 java 中的访问修饰符仅仅是建议性的。
There is nothing you can do to prevent this. Even private members can be accessed via reflection. You should consider the access modifiers in java to be merely suggestive.
首先，这是“DRM”场景：最终，某人有足够的决心可以通过提供时髦的修改运行时或其他类似的东西来击败您设置的任何保护。相反的情况——运行时是可信的，但某些包不可信——可以由 Java 通过使用合适的 ClassLoader 限制来正确处理，但这只能在有可以强制执行限制的情况下起作用以值得信赖的方式；这就是为什么你的情况基本上是注定的。
但是，如果我们假设运行时本身是可信的，那么您可以尝试在超级秘密方法中获取当前执行堆栈的堆栈跟踪（请参阅stackoverflow.com/questions/1069066/… 了解如何）并测试当前方法的调用者是否是一个您信任的访问权限。安全管理器会更合适，但您不能相信环境会安装您喜欢的安全管理器之一（它更明显地处于攻击者的控制之下）。请注意，我还没有尝试过本段中的选项！
另一种选择是将您的秘密放在您控制的服务上，并且仅提供对它们的远程访问。或者不再担心使用技术机制来处理从根本上涉及业务和法律问题的问题（例如，为什么要与您不能信任的人打交道？）
First off, this is the “DRM” scenario: ultimately, someone determined enough can defeat any protections you put in place by supplying a funky modified runtime or other such things. The reverse scenario – where the runtime is trusted but some of the packages are not – is tackled properly by Java through the use of suitable
ClassLoaderrestrictions, but that can only work where there's something that can enforce the restrictions in a trusted fashion; that's why your scenario is basically doomed.However, if we assume that the runtime itself is trustable then you could try, in your super-secret method, getting the stack trace of the currently executing stack (see stackoverflow.com/questions/1069066/… for how) and testing to see whether the caller of the current method is one that you trust to get access. A security manager would be even more suitable, but you can't trust the environment to have one of those installed that you like (it's much more clearly under the control of the attacker). Note that I have not tried the options in this paragraph!
The other alternative is to put your secrets on a service you control and only offer remote access to them. Or stop worrying about using technical mechanisms to deal with a problem that is fundamentally about business and legal issues (e.g., why are you dealing with people you can't trust?)
我想说的是，不要让他们在可以调用你的代码的地方运行代码，即在同一个 JVM 中。您可以考虑只提供他们可以外部调用的（网络）服务。不过，我不太了解实现这一点的最佳方法。
I'd say simply do not allow them to run code where it can call yours, i.e. in the same JVM. You could instead consider offering only a (web)service they can call externally. I'm not very up to date on the best ways to implement this though.