很多朋友對于java課程設計報告摘要和java課程設計摘要不太懂，今天就由小編來為大家分享，希望可以幫助到大家，下面一起來看看吧！
javap和java反編譯有何區別
通過javap反編譯只是得到匯編的指令而已，反編譯過來的，有很多特殊的信息，比如字符之間的+會變為StringBuffer.append()，總之是加工了以后的代碼，不能完全變回來了。
Java開發中有哪些登錄方法
登錄認證幾乎是任何一個系統的標配，web系統、APP、PC客戶端等，好多都需要注冊、登錄、授權認證。場景說明以一個電商系統，假設淘寶為例，如果我們想要下單，首先需要注冊一個賬號。擁有了賬號之后，我們需要輸入用戶名（比如手機號或郵箱）、密碼完成登錄過程。之后如果你在一段時間內再次進入系統，是不需要輸入用戶名和密碼的，只有在連續長時間不登錄的情況下（例如一個月沒登錄過）訪問系統，再次需要輸入用戶名和密碼。如果使用頻率很頻繁，通常是一年都不用再輸一次密碼，所以經常在換了一臺電腦或者一部手機之后，一些經常使用的網站或APP不記得密碼了。
提煉出來整個過程大概就是如下幾步：
首次使用，需要通過郵箱或手機號注冊；注冊完成后，需要提供用戶名和密碼完成登錄；下次再使用，通常不會再次輸入用戶名和密碼即可直接進入系統并使用其功能（除非連續長時間未使用）；常用的認證方式OAuth認證
OAuth認證比較常見的就是微信登錄、微博登錄、qq登錄等，簡單來說就是利用這些比較權威的網站或應用開放的API來實現用戶登錄，用戶可以不用在你的網站或應用上注冊賬號，直接用已有的微信、微博、qq等賬號登錄。
這一樣一來，即省了用戶注冊的時間，又簡化了你的系統的賬號體系。從而既可以提高用戶注冊率可以節省開發時間，同時，安全性也有了保障。
維基百科對它的解釋摘要如下：
OAuth允許用戶提供一個令牌，而不是用戶名和密碼來訪問他們存放在特定服務提供者的數據。每一個令牌授權一個特定的網站（例如，視頻編輯網站)在特定的時段（例如，接下來的2小時內）內訪問特定的資源（例如僅僅是某一相冊中的視頻）。這樣，OAuth讓用戶可以授權第三方網站訪問他們存儲在另外服務提供者的某些特定信息，而非所有內容。假設我們開發了一個電商平臺，并集成了微信登錄，以這個場景為例，說一下OAuth的工作原理。
講之前需要了解其中涉及到的幾個角色：
用戶：即使用我們平臺的用戶用戶終端：即最終用戶使用的APP端或web端應用服務器端：即我們的服務器端授權服務器端：這里就是微信處理授權請求的服務器好的，接下來開始在我們的電商平臺web端實現微信登錄功能。微信網頁授權是授權碼模式（authorizationcode）的OAuth授權模式。
我們電商平臺的用戶過來登錄，常用場景是點擊“微信登錄”按鈕；接下來，用戶終端將用戶引導到微信授權頁面；用戶同意授權，應用服務器重定向到之前設置好的redirect_uri（應用服務器所在的地址），并附帶上授權碼（code）;應用服務器用上一步獲取的code向微信授權服務器發送請求，獲取access_token，也就是上面說的令牌；之后應用服務器用上一步獲取的access_token去請求微信授權服務器獲取用戶的基本信息，例如頭像、昵稱等；Cookie-Session認證
早期互聯網以web為主，客戶端是瀏覽器，所以Cookie-Session方式最那時候最常用的方式，直到現在，一些web網站依然用這種方式做認證。
認證過程大致如下：
用戶輸入用戶名、密碼或者用短信驗證碼方式登錄系統；服務端驗證后，創建一個Session信息，并且將SessionID存到cookie，發送回瀏覽器；下次客戶端再發起請求，自動帶上cookie信息，服務端通過cookie獲取Session信息進行校驗；弊端
只能在web場景下使用，如果是APP中，不能使用cookie的情況下就不能用了；即使能在web場景下使用，也要考慮跨域問題，因為cookie不能跨域；cookie存在CSRF（跨站請求偽造）的風險；如果是分布式服務，需要考慮Session同步問題；Cookie-Session改造版
由于傳統的Cookie-Session認證存在諸多問題，可以把上面的方案改造一下。改動的地方如下：
不用cookie做客戶端存儲，改用其他方式，web下使用localstorage，APP中使用客戶端數據庫，這樣就實現了跨域，并且避免了CSRF;服務端也不存Session了，把Session信息拿出來存到Redis等內存數據庫中，這樣即提高了速度，又避免了Session同步問題；經過改造之后變成了如下的認證過程：
用戶輸入用戶名、密碼或者用短信驗證碼方式登錄系統；服務端經過驗證，將認證信息構造好的數據結構存儲到Redis中，并將key值返回給客戶端；客戶端拿到返回的key，存儲到localstorage或本地數據庫；下次客戶端再次請求，把key值附加到header或者請求體中；服務端根據獲取的key，到Redis中獲取認證信息；基于JWT的Token認證
上面的方案雖然經過了改版，但還是需要客戶端和服務器端維持一個狀態信息，比如用cookie換session,或者用key換Redis的value信息，基于JWT的Token認證方案可以省去這個過程。
JSONWebToken（JWT）是一個非常輕巧的規范。這個規范允許我們使用JWT在用戶和服務器之間傳遞安全可靠的信息。
認證過程
依然是用戶登錄系統；服務端驗證，將認證信息通過指定的算法（例如HS256）進行加密，例如對用戶名和用戶所屬角色進行加密，加密私鑰是保存在服務器端的，將加密后的結果發送給客戶端，加密的字符串格式為三個"."分隔的字符串Token，分別對應頭部、載荷與簽名，頭部和載荷都可以通過base64解碼出來，簽名部分不可以；客戶端拿到返回的Token，存儲到localstorage或本地數據庫；下次客戶端再次發起請求，將Token附加到header中；服務端獲取header中的Token，通過相同的算法對Token中的用戶名和所屬角色進行相同的加密驗證，如果驗證結果相同，則說明這個請求是正常的，沒有被篡改。這個過程可以完全不涉及到查詢Redis或其他存儲；優點
使用json作為數據傳輸，有廣泛的通用型，并且體積小，便于傳輸；不需要在服務器端保存相關信息；jwt載荷部分可以存儲業務相關的信息（非敏感的），例如用戶信息、角色等；總結綜上所述，JWT可以作為首選的認證方案。當然，具體的情況具體分析，還要看是不是適合真實的應用場景。除了上述的這些，涉及到信息安全的，建議全部采用https方式部署，采用https方式，信息很難被嗅探破解，對應用的安全性很重要。
關于java課程設計報告摘要，java課程設計摘要的介紹到此結束，希望對大家有所幫助。
