php語言流程控制中的主動與被動

2024-05-04 23:13:28

字體：大中小

來源：轉載

供稿：網友

這一年來,廣大的phper都在辛勤勞作, 比如淘寶改版, 云計算, 騰訊開放平臺, 網游, 這些作品少不了phper的功勞, 相信php語言可以繼續領先行業10年, 我們憧憬未來50年, 100年, php仍然如此叱咤風云. 我們都是渺小的一員, 除了會php, 其它也就不精, 難以為生. 大家都作努力吧.

什么是主動與被動. 舉個例子吧. 你跑去boss辦公室要求要加工資, 這就是主動, 無論是從你自身角度來看, 還是boss角度來看, 你都是主動的, 是積極樂觀的一面. 假如boss讓你去辦公室, 然后讓你把淘寶架構出來, 給你漲20%工資, 這就叫被動. 相信承諾了你就被動. 主動與被動簡單就這樣理解. 而程序流程中也會碰到如此難堪的主動與被動問題. 我們看示例.

A clier
當buy qq購買商品成功后, 通知QQ主服務器. 通過http協議.
file_get_contents('http://www.qq.com/api.php?add_saleinfo=buy_qq&orderid=12345&pay=888&email=a@qq.com');

代碼運行在buy.qq.com上面, 理解上來說是安全的, 但事實呢? 假如某人散發了此接口, 后果將不可估計. 人人都可以偽造訂單信息植入到qq.com. 無論你是如何限制來路, 數據檢查. 退一萬步, 危險的是寫這代碼的人. 那大家都會問, 既然是寫代碼的人, 權限已經很大,怎么防止得了? 這就需要由被動(qq.com) 變主動. ?add_saleinfo=buy_qq修改成不再接收任何的訂單信息. 而是token值. 收到token值后, 接口回調buy.qq的查詢接口, 然后再入庫. 普通用戶再也創造不出token值, 就算知道buy.qq的查詢接口, 也不可能影響到qq.com, 作為主體qq.com 基本上屬于主動, 不會時刻在混亂入庫, 而是主動分析, 思考入庫.

道理相同, 淘寶客玩家也有這個問題. 比如以前暴出來的部分瀏覽器修改網頁中的pid值, 讓用戶損失慘重. 這就是被動的結果. php是這樣寫的, php 請求淘寶api接口,接收到商品信息, 里面就有商品購買鏈接, 正正是這個購買鏈接讓站長變成了被動. 在頁面直接href這個鏈接的用戶都有可能被人采集, 被瀏覽器修改pid. 接下來, 你是懂的, pid代表金錢. 后期有人已經想到了這個問題, 就采取了被動變主動的做法, 防止bug產生. 就是將商品鏈接不直接顯示, 而通過一個php修改. 用戶看到的url類似: ?sid=aaaa333 sid肯定不是pid值, 所有工作都由buy.php來承載, 主動承擔分析及安全檢測工作.

QQ 互聯2.0 目前已經廣泛應用在互聯網站點上, 作為用戶數據主心的graph.qq.com如何保障用戶安全呢? 在保障訪問速度的前提下也要完善安全. QQ登錄目前的流程如下: 首先由appid appkey callbackurl組合成一串鏈接, 然后跳轉到qq.com. 這就是為什么許多站點直接訪問 qqlogin.php就能夠跳轉到qq登錄頁, 因為這參數都是固定的, 安全性還算可以. 登錄過程仍然在qq.com, 這就是phper經常談到的單點登錄. 登錄成功后會直接跳到callbackurl頁上, callbackurl此時得到的信息仍然不足以證明用戶登錄成功了, 僅僅得到了token值, 所以進入第二步, 用token值去qq api接口上查詢用戶openid, 完成登錄. 這樣, QQ就得主動, 查詢結果并不簡單是成功與否, 而是相應的參數及提示信息, 無論后期如何增加, 都可以兼容. 騰訊掌握著主動權, 這對于上億用戶量的企業來說是非常重要的. 內部安全還有判斷域名與appid對應, token過期檢查, ip限制. 技術層面來看騰訊是有的.

這樣例子很多, paypal, 支付寶,都是類似的道理.

上一篇：php中計算程序運行時間的類代碼

下一篇：php從數組中隨機抽取一些元素的代碼