安全優化--秒殺介面地址的隱藏
秒殺介面地址隱藏:每次點選秒殺按鈕,才會生成秒殺地址,之前是不知道秒殺地址的。不是寫死的,是從服務端獲取,動態拼接而成的地址。(Http協議是明文傳輸,透明的,前端無法控制惡意使用者進行攻擊)安全校驗還是要放在服務端,禁止掉這些惡意服務。
思路:
1.在進行秒殺之前,先請求一個服務端地址,/getmiaoshaPath 這個地址,用來獲取秒殺地址,傳參為 商品id,在服務端生成隨機數(MD5)作為pathId存入快取,(快取過期時間60s),然後將這個隨機數返回給前端.
2.獲得該pathid,後 前端在用這個pathid拼接在Url上作為引數,去請求domiaosha服務
3.後端接收到這個pathid 引數,並且與 快取中的pathid 比較。
如果通過比較,進行秒殺邏輯,如果不通過,丟擲業務異常,非法請求。
/*點選秒殺之後 就訪問後端 獲取一個秒殺地址pathId*/ function getMiaoshaPath() { $.ajax({ url :"/miaosha/getPath", type : "GET", data:{ goodsId :$("#goodsId").val(), verifyCode : $("#verifyCode").val() }, success:function(data){ if (data.code ==0) {// var path = data.data domiaosha(path) }else { layer.msg(data.message) } }, error :function () { layer.msg("客戶端錯誤") } }) } function domiaosha(path){ $.ajax({ url :"/miaosha/"+path+"/do_miaosha",//安全優化,帶著這個path去訪問 type : "POST", data:{ goodsId :$("#goodsId").val() }, success:function(data){ if (data.code ==0) {//成功 就跳轉 訂單頁面 並傳入 orderid // window.location.href= "/order_detail.htm?orderId="+data.data.id; //若果返回成功,即表示收到請求,等待中 getMiaoshaResult($("#goodsId").val()); }else { layer.msg(data.message) } }, error :function () { layer.msg("客戶端錯誤") } }) } /** * 安全優化之 ---介面地址隨機化(隱藏) * 1.點選秒殺之後,先訪問該介面生成一個pathId,並存入redis 返回前端 * 2.前端帶著這個pathId去訪問秒殺介面,如果傳入的path和從redis取出的不一致,就認為 非法請求 */ @AccessLimit(seconds = 5,maxCount = 5,needLogin = true) @RequestMapping(value = "/getPath", method = RequestMethod.GET) @ResponseBody public Result<String> getPath(HttpServletRequest request,MiaoshaUser user, Model model, @RequestParam("goodsId") long goodsId, @RequestParam(value = "verifyCode")String verifyCode) { if (user == null) { return Result.error(CodeMsg.SESSION_ERROR); } String str = UUIDUtill.uuid(); /*隨機生成 一個 pathId 返回給前端*/ String pathId = Md5Util.md5(str + "1111"); redisService.set(MiaoshaKey.getMiaoshaPath, "" + user.getId() + goodsId, pathId);
該操作:可以為了防止,惡意使用者登陸之後,獲取token的情況下,通過不斷呼叫秒殺地址介面,來達到刷單的惡意請求。
每次的url都不一樣,只有真正點選秒殺按鈕,才會根據商品和使用者id生成對應的秒殺介面地址。
但是,這種情況仍然不能解決 利用 按鍵精靈或者 機器人 頻繁點選按鈕的操作,為了降低點選按鈕的次數,以及高併發下,防止多個使用者在同一時間內,併發出大量請求,加入數學公式圖形驗證碼等防高併發優化。
相關推薦
安全優化--秒殺介面地址的隱藏
秒殺介面地址隱藏:每次點選秒殺按鈕,才會生成秒殺地址,之前是不知道秒殺地址的。不是寫死的,是從服務端獲取,動態拼接而成的地址。(Http協議是明文傳輸,透明的,前端無法控制惡意使用者進行攻擊)安全校驗還是要放在服務端,禁止掉這些惡意服務。 思路: 1.在進行秒殺之前,先請
SpringBoot(20)之高併發介面優化-------秒殺介面地址隱藏 + 驗證碼驗證 +介面限流防刷
SpringBoot學習之高併發介面優化—–秒殺介面地址隱藏(驗證碼)+介面限流防刷 秒殺介面地址隱藏 思路:秒殺開始之前,先去請求介面獲取秒殺地址。 - 介面改造,帶上PathVariable引數 - 新增生成地址的介面 - 秒殺收到請求,先驗證
隱藏秒殺介面地址
<script>function getMiaoshaPath(){$.ajax({url: '/miaosha/generate_path', //呼叫後臺介面獲取秒殺介面的入口地址type: "GET",data: {//post提交表單的時候,url引數可以
java秒殺高併發------秒殺介面高併發秒殺優化 RabbitMQ模式
RabbitMQ 我在windows平臺下安裝 整合RabbitMQ 要先安裝 erlang,要依賴他 啟動: 安裝了管理介面後 rabbitmq-plugins enable rabbitmq_management Sprin
Java秒殺實戰 (六) 服務級高併發秒殺優化(RabbitMQ+介面優化)
一、思路:減少資料庫訪問 1.系統初始化,把商品庫存數量載入到Redis 2.收到請求,Redis預減庫存,庫存不足,直接返回,否則進入3 3.請求入隊,立即返回排隊中 4.請求出隊,生成訂單,減少庫存 5.客戶端輪詢,是否秒殺成功 二、安裝RabbitMQ及其相
秒殺系統架構優化思路
沒有 bsp 認證 mis red src 系統 如果 所有 一、為什麽難 秒殺系統難做的原因:庫存只有一份,所有人會在集中的時間讀和寫這些數據。 例如小米手機每周二的秒殺,可能手機只有1萬部,但瞬時進入的流量可能是幾百幾千萬。 又例如12306搶票,亦與秒殺類似,瞬時流量
秒殺系統優化思路
按鈕 clas 繼續 -i 火車票 時間 有意 用戶 頁面 一、秒殺業務為什麽這麽難做 秒殺系統,庫存只有一份,所有人會在集中的時間讀和寫這些數據。 例如: 小米手機每周二的秒殺,可能手機只有1萬部,但瞬間進入的流量可能是幾百幾千萬。 12306搶票,票是有限的,但是搶票
秒殺系統前端優化
輪詢 限流 長連接 開始 pos 模擬 例如 使用 隨機 在秒殺系統中,前端能進行的優化點: 1. 限流,點擊提交按鈕後按鈕置灰,顯示為正在排隊中,能處理結束或若幹秒後,才允許用戶點擊2. 頁面靜態化,將頁面做成靜態頁面,不經過webserver的處理,直接返回3. CDN
PK2244-Java秒殺系統方案優化 高性能高並發實戰
高並發 並發 提升自己 filter container 秒殺 containe -c 提升 PK2244-Java秒殺系統方案優化 高性能高並發實戰 新年伊始,學習要趁早,點滴記錄,學習就是進步! 隨筆背景:在很多時候,很多入門不久的朋友都會問我:我是從其他語言轉到
Java秒殺系統方案優化---高性能高並發實戰
http 大並發 並發實戰 -- share 系統 消息 java com Java秒殺系統方案優化---高性能高並發實戰網盤地址:https://pan.baidu.com/s/1htNv2zq 密碼: ssyt備用地址(騰訊微雲):https://share.weiyu
Java秒殺系統方案優化視頻教程 Java高性能高並發實戰教程
Java 第1章 課程介紹及項目框架搭建技術選型思路分析,基於Maven的Spring-Boot工程框架的搭建,集成Thymeleaf,集成Mybatis,安裝Redis,集成Redis等等。第2章 實現用戶登錄以及分布式session功能實現用戶登錄功能,實現密碼兩次MD5入庫以及分布式Session。一則
阿裏秒殺系統架構優化思路
Java 架構師 程序員 秒殺系統 架構 秒殺業務為什麽難做 im系統,例如qq或者微博,每個人都讀自己的數據(好友列表、群列表、個人信息) 微博系統,每個人讀你關註的人的數據,一個人讀多個人的數據 秒殺系統,庫存只有一份,所有人會在集中的時間讀和寫這些數據,多個人讀一個數據例如:小米手
秒殺——接口優化
enable ble 異步 head 用戶名 消息 排隊 host 進行 1.Redis預減庫存減少數據庫訪問 2.內存標記減少Redis訪問 3.請求先入隊緩沖,異步下單,增強用戶體驗 4. Nginx水平擴展 5.數據庫分庫分表(阿裏中間件mycat) 減少數據庫訪
Apache網頁優化與安全優化(網頁壓縮;網頁緩存;網頁防盜鏈;隱藏版本信息)
信任站點 響應 win ef6 生效 傳輸 window 重要 move 1,網頁壓縮網站的訪問速度是由多個因素所共同決定的包括:1)應用程序的響應速度2)網絡帶寬3)服務器性能4)與客戶端之間的網絡傳輸速度等等其中最重要的就是Apache本身的響應速度,因此提升網站性能第
Apache安全優化:設置防盜鏈,隱藏版本信息 (內含Apache源碼包和抓包工具)
http 末尾 註意 包含 設定 情況 服務器 發現 for 防盜鏈:一些不良網站有時為了不增加成本又想擴充自己站點的內容,經常盜用其他網站的鏈接,一方面損害了原網站的合法利益,另一方面又加重了服務器的負擔隱藏版本信息:一般情況下,軟件的漏洞信息和特定版本是相關的如果×××
Java秒殺系統方案優化 高性能高並發實戰
www. 數據庫 存儲 redis服務器 live 框架搭建 入門 服務 dea 第1章 課程介紹(講師參與學習討論)本章將為大家介紹課程目標,課程技術棧,課程收獲,以及課程安排,讓大家更好的了解這門課程具體能幫助大家學習到哪些內容,能有哪些提高,希望本課程能很好的幫助大家
php 介面安全檢查--防止url連結或者介面地址暴露後,網站被惡意攻擊
網站安全問題: 1.Session檢查防止攻擊: function checkusersession(){ $sid = cookie('sid'); if($sid === null) &
SpringBoot實現Java高併發秒殺系統之併發優化
秒殺系統架構的設計和優化分析,以我一個小菜雞,目前是說不出來的o(╥﹏╥)o。 因此呢,我這裡僅從本專案已經實現的優化來介紹一下: 本專案中做到了以下優化: 秒殺介面採用md5加密方式防刷。 訂單表使用聯合主鍵方式,限制一個使用者只能購買該商品一次。 配合Spring事務
Java秒殺系統方案優化 2 --第2章 實現使用者登入以及分散式session功能
第2章 實現使用者登入以及分散式session功能 1. 明文密碼兩次md5入庫 分別使用簽名如1a2b3c4d,分別用簽名和密碼使用MD5加密兩次後(一次是最原始密碼加密,一次是加密後再使用MD5和簽名加密)才存入資料庫,每個使用者對應都有一個欄位,例如本案例中的sa
學習yijun zhang 老師的商品秒殺專案所得(1)——使用Redis做快取優化的簡單實現
主要使用的功能: 1.基於java的redis工具——Jedis 2.JDK本身提供的序列化方式——實現Serializable 3.實現序列化要用到的IO流——ByteArrayInputStream,ByteArrayOutputStream,ObjectI