我處於構建Java EE應用程序的需求階段，該應用程序很可能在GlassFish/JBoss後端（目前無關緊要）上運行。我知道我不應該在需求時間考慮架構，但我們不禁要開始想象如何組件將全部對齊在一起:-)Java客戶端.class文件保護
這裏有一些艱難的，非靈活的要求客戶端：
（1）客戶端應用程序將爲Swing框
（2）客戶端可以自由下載，但將使用訂閱模式（，因此需要具有服務器端認證/授權的登錄機制等等）
（3）是的，Java是最好的平臺解決手頭問題f或本文範圍之外的原因
（4）客戶端.class文件需要防範反編譯
最後（第4個）需求是本文的基礎。
我並不真的擔心有人真正反編譯並獲取我的源代碼：最後，它只是由一些輕量級業務邏輯驅動的Swing控件。
我很擔心有人反編譯我的代碼，修改它來利用/攻擊服務器，重新編譯並啓動它。
我曾經設想過各種討厭的解決方案，但不知道這是否是Java EE開發人員常見解決方案的常見問題。有什麼想法嗎？
對「代碼混淆」技術不感興趣！
感謝您的任何意見！
我在這裏爲你帶來壞消息。你不能阻止這一點。
我深深地深入了一次。在JVM的最低級別，Classloader必須得到一個未加密的字節流，即類文件。你不能改變用你自己的代碼替換JVM。此外，還有一個鉤子允許查看字節流（複製等）。無論你在更高層次上做什麼，JVM都會一直到達這一點，並允許訪問你的類文件。一旦獲得類文件，就可以反編譯。混淆技術和工具可以減慢或者使其變得困難，但是它們也無法阻止它。
我強烈建議您使用久經考驗的真實安全方法來保護您的服務器。不要把祕訣塞進你給客戶的東西里。如果他們有足夠的決心，他們會以某種方式得到它。
我認爲這是一個常見的「強弱」密碼學問題：如果算法的知識足以危及信息（即登錄），那麼密碼學很弱。
如何使用類似OAuth的東西呢？通過與服務器的一次性認證過程，客戶端應用程序被賦予令牌，並且如果有必要的話，服務器總是可以吊銷任何給定客戶端的授權。
另請注意，身份驗證不能代替授權。僅僅因爲你的系統認爲它知道某人是誰並不意味着他們應該被授權做他們想做的任何事情。您還需要部署良好的訪問控制（如JAAS或Spring Security提供的），並將其連接到身份驗證。對來自客戶的任何呼叫的第一次檢查是用於認證，其次是該特定客戶是否被授權首先進行呼叫。
無論你做什麼，你的服務器只需要允許基於授予用戶的授權進行調用。
您必須假定代碼將被反編譯，並將用於利用/攻擊服務器。
只相信服務器正在做什麼。
只需添加：@Zac：您的關注點應該在於**如何在服務器上驗證您的用戶，因爲理論上攻擊者不需要您的應用程序就可以造成傷害。 – Jeremy 2011-01-06 18:52:42
使用一個像樣的服務器認證，不存儲用戶名，密碼或加密密鑰的應用程序，然後爲Rekin意見，我看不出有什麼在你的代碼可能會背叛你的服務器保護。
如果absolutley需要加密通信（看起來並不像一個要求）使用SSL或任何公共密鑰加密。
我爲點數量「的思想開箱即用」的解決方案4.
我假設你的應用程序具有網絡訪問權限，因爲它去網上認證...
這不是一種具體的做事方法，正如我說的那樣。但是，它確實使得竊取你的代碼變得更加困難。但正如其他海報所說的，你不能在客戶端的代碼中隱藏祕密。
我真的不明白......如果認證和授權發生在服務器端比惡意客戶端可以做什麼？ – Rekin 2011-01-06 18:45:32
不要忘記，在一個網絡環境中，「壞人」可以將嗅探器放在他的盡頭，並找出發送的內容。 – Suirtimed 2011-01-06 18:55:10
@Suirtmed：與任何Web瀏覽器客戶端應用程序一樣。解決方案很簡單 - 使用加密通信（SSL）。基本上，我找不到任何理由來證明代碼加密。 – Rekin 2011-01-06 18:58:45