如何獲取@PathVariable的值

一、地址：**/{id}

@RequestMapping(value = "/del/{id}", method = RequestMethod.GET)
public void del(HttpServletRequest request, @PathVariable("id") Long id){
   System.out.println(id);
}

二、方式

1、直接通過@PathVariable注解獲取

    @RequestMapping(value = "/del/{id}", method = RequestMethod.GET)
    public void del(HttpServletRequest request, @PathVariable("id") Long id){
       System.out.println(id);
    }

2、通用@PathVariable注解批量獲取, 只有注解的參數(shù)才能得到

@RequestMapping(value = "/del/{id}", method = RequestMethod.GET)
   public void del(HttpServletRequest request, @PathVariable("id") Long id){
        NativeWebRequest webRequest = new ServletWebRequest(request);
        Map<String, Object> map = (Map<String, Object>) webRequest.getAttribute(View.PATH_VARIABLES, RequestAttributes.SCOPE_REQUEST);
        System.out.println(map.get("id"));
  }

3、批量獲取，不需要任何注解

@RequestMapping(value = "/del/{id}", method = RequestMethod.GET)
  public void del(HttpServletRequest request){
       NativeWebRequest webRequest = new ServletWebRequest(request);
       Map<String, String> map = (Map<String, String>) webRequest.getAttribute(HandlerMapping.URI_TEMPLATE_VARIABLES_ATTRIBUTE, RequestAttributes.SCOPE_REQUEST);
       System.out.println(map.get("id"));
  }

springmvc 使用@PathVariable時(shí)，應(yīng)該注意點(diǎn)什么？

近來在做庫存調(diào)劑系統(tǒng)時(shí)，我從前臺(tái)到后臺(tái)的傳值方式，主要包括：1個(gè)，用@PathVariable或者@RequestParam從路徑?。淮笥谝粋€(gè)，用于更新或者添加操作的，我用的是表單實(shí)體傳到后臺(tái)；大于一個(gè)，用于查詢的，我用的@RequestBody（好吧，我承認(rèn)這個(gè)只是我覺得好玩，但沒有多少人愿意在后臺(tái)一行又一行的寫：String test=request.getParameter("test");吧？？？？？）

現(xiàn)在，主要就是想說一個(gè)從路徑取值的“坑”，而重中之重，就想說一下我更偏愛的@PathVariable（別問我為什么，/{param}/fn.do，簡單啊）

一、使用@PathVariable的轉(zhuǎn)變過程

首先：

在盤古開天辟地時(shí)，就是一切還很混沌時(shí)，姑娘我連用@PathVariable取值都沒有取過來，還蒙圈蒙了一小會(huì)兒，完全不明白發(fā)生了什么，因?yàn)槲铱粗业恼Z法和格式，哪兒哪兒都對(duì)，但就是沒有傳過來值。我一想我原來寫/{param}/fn.do這種方式傳值的時(shí)候，也沒有問題呀，怎么今天是見鬼了？？？？ 蒙圈完了之后，就發(fā)現(xiàn)端倪了。

請(qǐng)看看我怎么寫的哈：

@RequestMapping("/dealerStock/swapOrder/{orderID}/cancelAuditThisOrder.do")
public @ResponseBody String cancelAuditThisOrder(@PathVariable("OrderID") String strOrderID）){
...
...
}

然后的然后，我就一直沒有請(qǐng)求到這個(gè)方法，更別談什么有沒有取到值的問題！后來解決的時(shí)候，真想一掌拍自己腦門上！

然后：

當(dāng)代碼規(guī)范審查通過后，也經(jīng)過了測試部的一級(jí)功能業(yè)務(wù)測試以及業(yè)務(wù)部的二級(jí)業(yè)務(wù)流程測試。文檔之類的，都準(zhǔn)備好了（我還能再說什么呢，無聲的兩個(gè)呵 呵） 正要布上去生產(chǎn)線的時(shí)候，老大再次審查了一遍代碼，審查到最后也沒個(gè)啥結(jié)果，但是，突然間看到那個(gè)@PathVariable就問了我兩個(gè)問題：

• 一、如果我的ID是不連續(xù)的，這種方法還能好使嗎？比如說：HC 782981；
• 二、是不是只要我拿到這個(gè)請(qǐng)求路徑，而我隨便推測一個(gè)ID號(hào)，就能避過用戶操作別人的數(shù)據(jù)？

姑娘我再次被雷擊倒，無言以對(duì)，馬上實(shí)際驗(yàn)證。結(jié)果：Yes！ 你說第一個(gè)的結(jié)果是Yes，這個(gè)我很滿意，但第二個(gè)是Yes，就很想哭了。 測試出結(jié)果后，就請(qǐng)命去干掉這個(gè)問題了。

我的第一步嘗試：

添加method=RequestMethod.post，也就是說用戶不能輸入U(xiǎn)rl地址以get的形式獲取數(shù)據(jù)，只能通過系統(tǒng)內(nèi)部請(qǐng)求。

• 組長：你自己說，就算咱們改成了Post請(qǐng)求，你能不能訪問到？
• 姑娘：我能，就自己寫一個(gè)按鈕，再用post請(qǐng)求就行了。如果用戶里面有懂點(diǎn)程序編碼的，輕而易舉就能破掉。我再去改
• 組長：其實(shí)，我們只能防君子，哪個(gè)系統(tǒng)都有漏洞，沒有絕對(duì)的權(quán)限控制和安全，但咱們盡量的給做好。

我的第二步嘗試：

在第二步嘗試前，我想了一會(huì)兒。我發(fā)現(xiàn)這個(gè)事件有以下幾個(gè)突破口：

• 一、像訂單編號(hào)這個(gè)敏感的數(shù)據(jù)，能不能做到不被推測出來？
• 二、用戶是根據(jù)訪問路徑，然后加上一個(gè)ID號(hào)去請(qǐng)求，如果用戶拿不到訪問路徑呢？
• 三、要點(diǎn)就是用戶只能操作自己的數(shù)據(jù)，我可以在敏感操作的時(shí)候，同時(shí)校驗(yàn)當(dāng)前用戶。
• 四、既然都是@PathVariable這種方式帶來的一些問題，那我可以把相應(yīng)的方法，換掉這種傳值方式。
• 五、用戶看到的是一個(gè)請(qǐng)求方法路徑，我可不可以在路徑中加入隨機(jī)密碼鹽，進(jìn)一步的控制關(guān)鍵操作的訪問。

好吧，為了方便迅速，我直接把這種傳值方式給改了。當(dāng)然也沒有改完，時(shí)間關(guān)系，像一些本來就屬于公開數(shù)據(jù)的內(nèi)容，還是沒改。

我的第三步嘗試：

在第二步的時(shí)候，就已經(jīng)改完代碼了。然后，我覺得我是一個(gè)很較真的人。忙里偷閑，我把我在第二步嘗試中想到了幾個(gè)點(diǎn)，都寫代碼測了測。最先測出來的是第三種（同時(shí)檢驗(yàn)當(dāng)前用戶，也就簡單類似于where orderID=? and userID=? ） 其次，還測了測那個(gè)密碼鹽值，也確實(shí)能夠控制住，但是，想了想系統(tǒng)的性質(zhì)和資源的最終走向，沒改。然后，去禁止用戶打開開發(fā)者工具或者查看源代碼，然而，這根本不是我能控制住的。我也最多就是能控制住快捷鍵打開，但人家還有鼠標(biāo)?。?？？？？？瀏覽器提供的功能，不是我想干掉就干掉滴滴滴滴。

我的第一個(gè)方案，就是改造訂單生成的方式，然后我覺得吧，這個(gè)好像不怎么靠譜。但毫無疑問比當(dāng)前的生成方式要靠譜得太多，但這要改動(dòng)下來，呃，原諒我很慫。

二、個(gè)人總結(jié)

我最大的問題，不是我后來想不出更為優(yōu)雅的方案去解決，而是，我從根本上，對(duì)這是個(gè)問題的問題毫無知覺。我甚至都不覺得那樣有什么問題，這才是我最該考慮的點(diǎn)。

其實(shí)，我用@PathVariable或者什么別的方式去傳值，這都無可厚非。但我也應(yīng)該更進(jìn)一步的考慮到它的應(yīng)用場景和系統(tǒng)功能鎖涉及到的數(shù)據(jù)，以及可能帶來的后果。就比如說我這個(gè)@PathVariable的問題，在別的查詢一些區(qū)域信息（公共展示數(shù)據(jù)）的時(shí)候，我也這么用了，組長也看見了，但為什么他著重說了訂單這一塊，還要求這一塊必須改。反正，我就是欠思考。。。。。。

很多很多的東西，都是建立在日常生活體驗(yàn)上的。我以前就很崇拜架構(gòu)師，現(xiàn)在也很崇拜。但是，我突然明白，架構(gòu)師也不是光有空架子的。就比如說我自己吧，我還算是亂七八糟的想法挺多的那種（雖然并不是每個(gè)都靠譜）但是，做事情不能光憑想象，要實(shí)際操作的。

感覺最近做得比較好一點(diǎn)的就是：

1，因?yàn)橛幸粋€(gè)地方查詢的數(shù)據(jù)有很多，那天我跟組長提出，我要換一種查詢方法，提升查詢效率。然后組長就問我究竟想怎么換？我就直接同時(shí)運(yùn)行了兩套代碼干同樣的事兒給他看，結(jié)果，就很so easy的換成了我想換的那種方式，我想說的話，全都在代碼里。后來弄完了，閑下來，我解釋了一下不同點(diǎn)，關(guān)鍵點(diǎn)。

2，因?yàn)閺?qiáng)調(diào)代碼規(guī)范和效率嘛。我就在自己私下寫代碼的時(shí)候，旁邊就放著一本代碼整潔之道，還有阿里代碼規(guī)范手冊(cè)，然后還有我閑下來的時(shí)候，去官網(wǎng)找的一些常用數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)類型的應(yīng)用對(duì)比。我是一邊寫，一邊看。有不知道怎么寫的，就干脆先看一眼，照著書寫。剛開始挺痛苦的，因?yàn)閷懸痪渚湾e(cuò)一句，也不能說錯(cuò)，就是不夠優(yōu)美。但是，感覺現(xiàn)在慢慢變得好了特別特別多。

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論