⑴ 請教大神幫我解決下微信JSSDk介面簽名錯誤的問題
一般是代碼問題或者介面不兼容引起的。如果簽名和驗證工具簽名一致，只能說明你簽名時的url和wx校驗時的url不一致，可能是參數導致的，在打開頁面前，先對參數進行encode，同樣在你簽名的時候對url的參數進行encode。注意，是url的參數，不是整個url。
⑵ 如何寫出安全的API介面
1.完全開放的介面
有沒有這樣的介面，誰都可以調用，誰都可以訪問，不受時間空間限制，只要能連上互聯網就能調用，毫無安全可言。
實話說，這樣的介面我們天天都在接觸，你查快遞，你查天氣預報，你查飛機，火車班次等，這些都是有公共的介面。
我把這稱之為裸奔時代。代碼如下：
/// <summary>
/// 介面對外公開
/// </summary>
/// <returns></returns>
[HttpGet]
[Route("NoSecure")]
public HttpResponseMessage NoSecure(int age)
{
var result = new ResultModel<object>()
{
ReturnCode = 0,
Message = string.Empty,
Result = string.Empty
};
var dataResult = stulist.Where(T => T.Age == age).ToList();
result.Result = dataResult;
return GetHttpResponseMessage(result);
}
2.介面參數加密（基礎加密）
你寫個介面，你只想讓特定的調用方使用，你把這些調用的人叫到一個小屋子，給他們宣布說我這里有個介面只打算給你們用，我給你們每人一把鑰匙，你們用的時候拿著這把鑰匙即可。
這把鑰匙就是我上文說到的參數加密規則，有了這個規則就能調用。
這有安全問題啊，這裡面的某個成員如果哪個不小心丟了鑰匙或者被人竊取，掌握鑰匙的人是不是也可以來掉用介面了呢？而且他可以復制很多鑰匙給不明不白的人用。
相當於有人拿到了你的請求鏈接，如果業務沒有對鏈接唯一性做判斷（實際上業務邏輯通常不會把每次請求的加密簽名記錄下來，所以不會做唯一性判斷），就會被重復調用，有一定安全漏洞，怎麼破？先看這個場景的代碼，然後繼續往下看！
/// <summary>
/// 介面加密
/// </summary>
/// <returns></returns>
[HttpGet]
[Route("SecureBySign")]
public HttpResponseMessage SecureBySign([FromUri]int age, long _timestamp, string appKey, string _sign)
{
var result = new ResultModel<object>()
{
ReturnCode = 0,
Message = string.Empty,
Result = string.Empty
};
#region 校驗簽名是否合法
var param = new SortedDictionary<string, string>(new AsciiComparer());
param.Add("age", age.ToString());
param.Add("appKey", appKey);
param.Add("_timestamp", _timestamp.ToString());
string currentSign = SignHelper.GetSign(param, appKey);
if (_sign != currentSign)
{
result.ReturnCode = -2;
result.Message = "簽名不合法";
return GetHttpResponseMessage(result);
}
#endregion
var dataResult = stulist.Where(T => T.Age == age).ToList();
result.Result = dataResult;
return GetHttpResponseMessage(result);
}
3.介面參數加密+介面時效性驗證（一般達到這個級別已經非常安全了）
繼上一步，你發現有不明不白的人調用你的介面，你很不爽，隨即把真正需要調用介面的人又叫來，告訴他們每天給他們換一把鑰匙。和往常一樣，有個別夥伴的鑰匙被小偷偷走了，小偷煞費苦心，經過數天的踩點觀察，准備在一個月黑風高的夜晚動手。拿出鑰匙，搗鼓了半天也無法開啟你的神聖之門，因為小偷不知道你天天都在換新鑰匙。
小偷不服，經過一段時間琢磨，小偷發現了你們換鑰匙的規律。在一次獲得鑰匙之後，不加思索，當天就動手了，因為他知道他手裡的鑰匙在第二天你更換鑰匙後就失效了。
結果，小偷如願。怎麼破？先看這個場景的代碼，然後繼續往下看！
/// <summary>
/// 介面加密並根據時間戳判斷有效性
/// </summary>
/// <returns></returns>
[HttpGet]
[Route("SecureBySign/Expired")]
public HttpResponseMessage SecureBySign_Expired([FromUri]int age, long _timestamp, string appKey, string _sign)
{
var result = new ResultModel<object>()
{
ReturnCode = 0,
Message = string.Empty,
Result = string.Empty
};
#region 判斷請求是否過期---假設過期時間是20秒
DateTime requestTime = GetDateTimeByTicks(_timestamp);
if (requestTime.AddSeconds(20) < DateTime.Now)
{
result.ReturnCode = -1;
result.Message = "介面過期";
return GetHttpResponseMessage(result);
}
#endregion
#region 校驗簽名是否合法
var param = new SortedDictionary<string, string>(new AsciiComparer());
param.Add("age", age.ToString());
param.Add("appKey", appKey);
param.Add("_timestamp", _timestamp.ToString());
string currentSign = SignHelper.GetSign(param, appKey);
if (_sign != currentSign)
{
result.ReturnCode = -2;
result.Message = "簽名不合法";
return GetHttpResponseMessage(result);
}
#endregion
var dataResult = stulist.Where(T => T.Age == age).ToList();
result.Result = dataResult;
return GetHttpResponseMessage(result);
}
4.介面參數加密+時效性驗證+私鑰（達到這個級別安全性固若金湯）
繼上一步，你發現道高一尺魔高一丈，仍然有偷盜事情發生。咋辦呢？你打算下血本，給每個人配一把鑰匙的基礎上，再給每個人發個暗號，即使鑰匙被小偷弄去了，小偷沒有暗號，任然無法如願，而且這樣很容易定位是誰的暗號泄漏問題，找到問題根源，只需要給當前這個人換下鑰匙就行了，不用大動干戈。
但這個並不是萬無一失的，因為鑰匙畢竟還有可能被小偷搞到。代碼如下：
/// <summary>
/// 介面加密並根據時間戳判斷有效性而且帶著私有key校驗
/// </summary>
/// <returns></returns>
[HttpGet]
[Route("SecureBySign/Expired/KeySecret")]
public HttpResponseMessage SecureBySign_Expired_KeySecret([FromUri]int age, long _timestamp, string appKey, string _sign)
{
//key集合，這里隨便弄兩個測試數據
//如果調用方比較多，需要審核授權，根據一定的規則生成key把這些數據存放在資料庫中，如果功能擴展開來，可以針對不同的調用方做不同的功能許可權管理
//在調用介面時動態從庫里取，每個調用方在調用時帶上他的key，調用方一般把自己的key放到網站配置中
Dictionary<string, string> keySecretDic = new Dictionary<string, string>();
keySecretDic.Add("key_zhangsan", "");//張三的key,
keySecretDic.Add("key_lisi", "");//李四的key
var result = new ResultModel<object>()
{
ReturnCode = 0,
Message = string.Empty,
Result = string.Empty
};
#region 判斷請求是否過期---假設過期時間是20秒
DateTime requestTime = GetDateTimeByTicks(_timestamp);
if (requestTime.AddSeconds(20) < DateTime.Now)
{
result.ReturnCode = -1;
result.Message = "介面過期";
return GetHttpResponseMessage(result);
}
#endregion
#region 根據appkey獲取key值
string secret = keySecretDic.Where(T => T.Key == appKey).FirstOrDefault().Value;
#endregion
#region 校驗簽名是否合法
var param = new SortedDictionary<string, string>(new AsciiComparer());
param.Add("age", age.ToString());
param.Add("appKey", appKey);
param.Add("appSecret", secret);//把secret加入進行加密
param.Add("_timestamp", _timestamp.ToString());
string currentSign = SignHelper.GetSign(param, appKey);
if (_sign != currentSign)
{
result.ReturnCode = -2;
result.Message = "簽名不合法";
return GetHttpResponseMessage(result);
}
#endregion
var dataResult = stulist.Where(T => T.Age == age).ToList();
result.Result = dataResult;
return GetHttpResponseMessage(result);
}
⑶ 介紹下代碼簽名證書的功能是怎樣給軟體代碼進行數字簽名
代碼簽名的基礎是PKI安全體系。代碼簽名證書由簽名證書私鑰和公鑰證書兩部分組成。私鑰用於代碼的簽名，公鑰用於私鑰簽名的驗證和證書持有者的身份識別。
1. 發布者從CA機構申請數字證書；
2. 發布者開發出代碼；藉助代碼簽名工具，發布者將使用MD5或SHA演算法產生代碼的哈希值，然後用代碼簽名證書私鑰對該哈希值簽名，從而產生一個包含代碼簽名和軟體發布者的簽名證書的軟體包；
3. 用戶的運行環境訪問到該軟體包，並檢驗軟體發布者的代碼簽名數字證書的有效性。操作系統或瀏覽器通過可信根證書列表驗證代碼簽名證書的有效性，確認發布者身份可信，軟體未被篡改。
4. 用戶的運行環境使用代碼簽名數字證書中含有的公鑰解密被簽名的哈希值；
5. 用戶的運行環境使用同樣的演算法新產生一個原代碼的哈希值；
6. 用戶的運行環境比較兩個哈希值。如果相同，將發出通知聲明代碼已驗證通過。所以用戶可以相信該代碼確實由證書擁有者發布，並且未經篡改。
整個過程對用戶完全透明，用戶將可以看到軟體發布者提示信息，並可以選擇是否信任該軟體發布者。在選擇信任軟體發布者之後，運行所有該軟體發布者簽名的程序時將可以不再收到任何提示信息。
⑷ java中怎麼用jsp調用已有的介面,加密拼接參數
主要通過簽名驗證的方式來實現介面加密，前端給後端介面傳參數時先用aes加密，生成一個sign簽名，後端寫一個攔截器對其進行簽名驗證，後端接收到參數後，也通過同樣的方法對其參數加密生成一個sign，兩者相對比，如何相同則簽名成功！ 自己在加密生成簽名時，自己也可以定義一系列規則
⑸ 如何處理restful對介面安全性問題
REST (REpresentation State Transfer) 描述了一個架構樣式的網路系統，比如 web 應用程序。它首次出現在 2000 年 Roy Fielding 的博士論文中，他是 HTTP 規范的主要編寫者之一。REST 指的是一組架構約束條件和原則。滿足這些約束條件和原則的應用程序或設計就是 RESTful。Web 應用程序最重要的 REST 原則是，客戶端和伺服器之間的交互在請求之間是無狀態的。從客戶端到伺服器的每個請求都必須包含理解請求所必需的信息。如果伺服器在請求之間的任何時間點重啟，客戶端不會得到通知。此外，無狀態請求可以由任何可用伺服器回答，這十分適合雲計算之類的環境。客戶端可以緩存數據以改進性能。在伺服器端，應用程序狀態和功能可以分為各種資源。資源是一個有趣的概念實體，它向客戶端公開。資源的例子有:應用程序對象、資料庫記錄、演算法等等。每個資源都使用 URI (Universal Resource Identifier) 得到一個惟一的地址。所有資源都共享統一的界面，以便在客戶端和伺服器之間傳輸狀態。使用的是標準的 HTTP 方法，比如 GET、PUT、POST 和 DELETE。Hypermedia 是應用程序狀態的引擎，資源表示通過超鏈接互聯。另一個重要的 REST 原則是分層系統，這表示組件無法了解它與之交互的中間層以外的組件。通過將系統知識限制在單個層，可以限制整個系統的復雜性，促進了底層的獨立性。當REST 架構的約束條件作為一個整體應用時，將生成一個可以擴展到大量客戶端的應用程序。它還降低了客戶端和伺服器之間的交互延遲。統一界面簡化了整個系統架構，改進了子系統之間交互的可見性。REST 簡化了客戶端和伺服器的實現。RESTful的實現:RESTful Web 服務與 RPC 樣式的 Web 服務了解了什麼是什麼是REST，我們再看看RESTful的實現。最近，使用 RPC 樣式架構構建的基於 SOAP 的 Web 服務成為實現 SOA 最常用的方法。RPC 樣式的 Web 服務客戶端將一個裝滿數據的信封(包括方法和參數信息)通過 HTTP 發送到伺服器。伺服器打開信封並使用傳入參數執行指定的方法。方法的結果打包到一個信封並作為響應發回客戶端。客戶端收到響應並打開信封。每個對象都有自己獨特的方法以及僅公開一個 URI 的 RPC 樣式 Web 服務，URI 表示單個端點。它忽略 HTTP 的大部分特性且僅支持 POST 方法。由於輕量級以及通過 HTTP 直接傳輸數據的特性，Web 服務的 RESTful 方法已經成為最常見的替代方法。可以使用各種語言(比如 Java 程序、Perl、Ruby、Python、PHP 和 Javascript[包括 Ajax])實現客戶端。RESTful Web 服務通常可以通過自動客戶端或代表用戶的應用程序訪問。但是，這種服務的簡便性讓用戶能夠與之直接交互，使用它們的 Web 瀏覽器構建一個 GET URL 並讀取返回的內容。在REST 樣式的 Web 服務中，每個資源都有一個地址。資源本身都是方法調用的目標，方法列表對所有資源都是一樣的。這些方法都是標准方法，包括 HTTP GET、POST、PUT、DELETE，還可能包括 HEADER 和 OPTIONS。在RPC 樣式的架構中，關注點在於方法，而在 REST 樣式的架構中，關注點在於資源 -- 將使用標准方法檢索並操作信息片段(使用表示的形式)。資源表示形式在表示形式中使用超鏈接互聯。Leonard Richardson 和 Sam Ruby 在他們的著作 RESTful Web Services 中引入了術語 REST-RPC 混合架構。REST-RPC 混合 Web 服務不使用信封包裝方法、參數和數據，而是直接通過 HTTP 傳輸數據，這與 REST 樣式的 Web 服務是類似的。但是它不使用標準的 HTTP 方法操作資源。它在 HTTP 請求的 URI 部分存儲方法信息。好幾個知名的 Web 服務，比如 Yahoo 的 Flickr API 和 del.icio.us API 都使用這種混合架構。RESTful的實現:RESTful Web 服務的 Java 框架有兩個 Java 框架可以幫助構建 RESTful Web 服務。erome Louvel 和 Dave Pawson 開發的 Restlet(見 參考資料)是輕量級的。它實現針對各種 RESTful 系統的資源、表示、連接器和媒體類型之類的概念，包括 Web 服務。在 Restlet 框架中，客戶端和伺服器都是組件。組件通過連接器互相通信。該框架最重要的類是抽象類 Uniform 及其具體的子類 Restlet，該類的子類是專用類，比如 Application、Filter、Finder、Router 和 Route。這些子類能夠一起處理驗證、過濾、安全、數據轉換以及將傳入請求路由到相應資源等操作。Resource 類生成客戶端的表示形式。JSR-311是 Sun Microsystems 的規范，可以為開發 RESTful Web 服務定義一組 Java API。Jersey是對 JSR-311 的參考實現。JSR-311 提供一組注釋，相關類和介面都可以用來將 Java 對象作為 Web 資源展示。該規范假定 HTTP 是底層網路協議。它使用注釋提供 URI 和相應資源類之間的清晰映射，以及 HTTP 方法與 Java 對象方法之間的映射。API 支持廣泛的 HTTP 實體內容類型，包括 HTML、XML、JSON、GIF、JPG 等。它還將提供所需的插件功能，以允許使用標准方法通過應用程序添加其他類型。RESTful的實現:構建 RESTful Web 服務的多層架構RESTful Web 服務和動態 Web 應用程序在許多方面都是類似的。有時它們提供相同或非常類似的數據和函數，盡管客戶端的種類不同。例如，在線電子商務分類網站為用戶提供一個瀏覽器界面，用於搜索、查看和訂購產品。如果還提供 Web 服務供公司、零售商甚至個人能夠自動訂購產品，它將非常有用。與大部分動態 Web 應用程序一樣，Web 服務可以從多層架構的關注點分離中受益。業務邏輯和數據可以由自動客戶端和 GUI 客戶端共享。惟一的不同點在於客戶端的本質和中間層的表示層。此外，從數據訪問中分離業務邏輯可實現資料庫獨立性，並為各種類型的數據存儲提供插件能力。圖1 展示了自動化客戶端，包括 Java 和各種語言編寫的腳本，這些語言包括 Python、Perl、Ruby、PHP 或命令行工具，比如 curl。在瀏覽器中運行且作為 RESTful Web 服務消費者運行的 Ajax、Flash、JavaFX、GWT、博客和 wiki 都屬於此列，因為它們都代表用戶以自動化樣式運行。自動化 Web 服務客戶端在 Web 層向 Resource Request Handler 發送 HTTP 響應。客戶端的無狀態請求在頭部包含方法信息，即 POST、GET、PUT 和 DELETE，這又將映射到 Resource Request Handler 中資源的相應操作。每個請求都包含所有必需的信息，包括 Resource Request Handler 用來處理請求的憑據。從Web 服務客戶端收到請求之後，Resource Request Handler 從業務邏輯層請求服務。Resource Request Handler 確定所有概念性的實體，系統將這些實體作為資源公開，並為每個資源分配一個惟一的 URI。但是，概念性的實體在該層是不存在的。它們存在於業務邏輯層。可以使用 Jersey 或其他框架(比如 Restlet)實現 Resource Request Handler，它應該是輕量級的，將大量職責工作委託給業務層。Ajax 和 RESTful Web 服務本質上是互為補充的。它們都可以利用大量 Web 技術和標准，比如 HTML、JavaScript、瀏覽器對象、XML/JSON 和 HTTP。當然也不需要購買、安裝或配置任何主要組件來支持 Ajax 前端和 RESTful Web 服務之間的交互。RESTful Web 服務為 Ajax 提供了非常簡單的 API 來處理伺服器上資源之間的交互。圖1 中的 Web 瀏覽器客戶端作為 GUI 的前端，使用表示層中的 Browser Request Handler 生成的 HTML 提供顯示功能。Browser Requester Handler 可以使用 MVC 模型(JSF、Struts 或 Spring 都是 Java 的例子)。它從瀏覽器接受請求，從業務邏輯層請求服務，生成表示並對瀏覽器做出響應。表示供用戶在瀏覽器中顯示使用。表示不僅包含內容，還包含顯示的屬性，比如 HTML 和 CSS。 業務規則可以集中到業務邏輯層，該層充當表示層和數據訪問層之間的數據交換的中間層。數據以域對象或值對象的形式提供給表示層。從業務邏輯層中解耦 Browser Request Handler 和 Resource Request Handler 有助於促進代碼重用，並能實現靈活和可擴展的架構。此外，由於將來可以使用新的 REST 和 MVC 框架，實現它們變得更加容易，無需重寫業務邏輯層。數據訪問層提供與數據存儲層的交互，可以使用 DAO 設計模式或者對象-關系映射解決方案(如 Hibernate、OJB 或 iBATIS)實現。作為替代方案，業務層和數據訪問層中的組件可以實現為 EJB 組件，並取得 EJB 容器的支持，該容器可以為組件生命周期提供便利，管理持久性、事務和資源配置。但是，這需要一個遵從 Java EE 的應用伺服器(比如 JBoss)，並且可能無法處理 Tomcat。該層的作用在於針對不同的數據存儲技術，從業務邏輯中分離數據訪問代碼。數據訪問層還可以作為連接其他系統的集成點，可以成為其他 Web 服務的客戶端。數據存儲層包括資料庫系統、LDAP 伺服器、文件系統和企業信息系統(包括遺留系統、事務處理系統和企業資源規劃系統)。使用該架構，您可以開始看到 RESTful Web 服務的力量，它可以靈活地成為任何企業數據存儲的統一 API，從而向以用戶為中心的 Web 應用程序公開垂直數據，並自動化批量報告腳本。什麼是REST:結束語REST 描述了一個架構樣式的互聯系統(如 Web 應用程序)。REST 約束條件作為一個整體應用時，將生成一個簡單、可擴展、有效、安全、可靠的架構。由於它簡便、輕量級以及通過 HTTP 直接傳輸數據的特性，RESTful Web 服務成為基於 SOAP 服務的一個最有前途的替代方案。用於 web 服務和動態 Web 應用程序的多層架構可以實現可重用性、簡單性、可擴展性和組件可響應性的清晰分離。Ajax 和 RESTful Web 服務本質上是互為補充的。
⑹ 前後端分離，關於介面文檔，後端是要先寫好介面文檔，再進行寫代碼開發，還是寫完代碼後再編寫介面文檔
1、先理清業務流程
2、定義前後端開發的介面規范。比如json的格式，url的格式
3、定義介面文檔，這里的介面文檔一般就是對應後台的實體reqVo（調用後台介面<控制器>訪問的實體）和返回給前台的respVo（前台調用介面的返回的實體）。注意一般respVo都會有在後台做一個統一的處理為ResultVo（這個規范在2中要定義好，比如：錯誤碼，錯誤描述，請求的url，請求時間，以及實體T<這個實體才是真正的respVo和業務相關,這個一般都是實體>）
4、定義介面文檔是在了解業務流、數據流基礎之上完成的。有了這個介面文檔（其實就是定義實體的過程和對應的json）前後端的開發基本按照這個文檔去開發。介面文檔會有版本迭代，一般放到svn上，供所有開發人員閱覽
5、現在一般系統用到的資料庫都不會是單純mysql了。還有redis，mongo、es等。這些個人感覺都是在十分了解業務的情況和系統架構下去設計的。後台運用這些工具去完成介面功能的實現已經系統功能和性能的實現。這個和介面文檔先後順序還真不好說，個人覺得都可以。
6、業務流-數據流-資金流。去了解和設計系統。
⑺ 什麼是簽名伺服器和APP之間的API介面和數據怎麼保證安全
apk簽名相當於程序的身份識別代碼。
apk簽名用於程序編譯打包之後，手機在運行程序之前會先去驗證程序的簽名（可以看作類似於我們電腦上常說的md5）是否合法，只有通過了驗證的文件才會被運行，所以簽名軟體的作用的讓文件通過手機的驗證為合法，不同的手機、系統是對應不同的簽名的。
進行加密通訊防止API外部調用
伺服器端與客戶端各自會存儲一個TOKEN,這個TOKEN我們為了防止反編譯是用C語言來寫的一個文件並做了加殼和混淆處理。
在客戶端訪問伺服器API任何一個介面的時候，客戶端需要帶上一個特殊欄位，這個欄位就是簽名signature，簽名的生成方式為：
訪問的介面名+時間戳+加密TOKEN 進行整體MD5,並且客戶端將本地的時間戳作為明文參數提交到伺服器
伺服器首先會驗證這兩個參數：驗證時間戳，如果時間誤差與伺服器超過正負一分鍾，伺服器會拒絕訪問(防止被抓包重復請求伺服器，正負一分鍾是防止時間誤差，參數可調整)，
然後伺服器會根據請求的API地址和提交過來的時間戳再加上本地存儲的token按照MD5重新生成一個簽名，並比對簽名，簽名一致才會通過伺服器的驗證，進入到下一步的API邏輯
⑻ java給別人提供介面，介面安全怎麼保證
我們在開發過程中，肯定會有和第三方或者app端的介面調用。在調用的時候，下面的方法可以來防止非法鏈接或者惡意攻擊。
一、簽名
根據用戶名或者用戶id，結合用戶的ip或者設備號，生成一個token。在請求後台，後台獲取http的head中的token，校驗是否合法（和資料庫或者Redis中記錄的是否一致，在登錄或者初始化的時候，存入資料庫/redis）
在使用Base64方式的編碼後，Token字元串還是有20多位，有的時候還是嫌它長了。由於GUID本身就有128bit，在要求有良好的可讀性的前提下，很難進一步改進了。那我們如何產生更短的字元串呢？還有一種方式就是較少Token的長度，不用GUID，而採用一定長度的隨機數，例如64bit，再用Base64編碼表示：
varrnd =newRandom();
vartokenData =userIp+userId;
rnd.NextBytes(tokenData);
vartoken =Convert.ToBase64String(tokenData).TrimEnd('=');
由於這里只用了64bit，此時得到的字元串為Onh0h95n7nw的形式，長度要短一半。這樣就方便攜帶多了。但是這種方式是沒有唯一性保證的。不過用來作為身份認證的方式還是可以的（如網盤的提取碼）。
二、加密
客戶端和伺服器都保存一個秘鑰，每次傳輸都加密，服務端根據秘鑰解密。
客戶端：
1、設置一個key（和伺服器端相同）
2、根據上述key對請求進行某種加密（加密必須是可逆的，以便伺服器端解密）
3、發送請求給伺服器
伺服器端：
1、設置一個key
2、根據上述的key對請求進行解密（校驗成功就是「信任」的客戶端發來的數據，否則拒絕響應）
3、處理業務邏輯並產生結果
4、將結果反饋給客戶端
三、第三方支持
比如springsecurity－oauth
⑼ 如何將html中form表單數字簽名以保證其安全性
可以用struts中的信牌。DEMO: DocumentTypeDataBean documentTypeDataBean = ctrl.setDataBean( documentTypeForm, "insert");
String oldkey = documentTypeForm.getType_task_id().toString();
String result = ctrl.copeAddDocumentType(documentTypeDataBean,oldkey);//增加操作
List documentTypeList = ctrl.getAllDocumentType(request, null);
request.setAttribute("documentTypeList", documentTypeList);
request.setAttribute("documentTypeForm", null);
this.saveToken(request);//保存信牌
return mapping.findForward("list.documenttype");
也可以不用， 原理是一樣的。傳個唯一的值 ， 在後台中作判斷。