最近在用php寫app的接口，有一些疑問
首先關於token(令牌)
token是用戶登錄的時候生成的
用戶token在服務端保存入庫 客戶端則緩存在本地 大部分接口都要求客戶端發送token 和服務端數據庫中的token進行驗證
每個用戶唯一token 是由 年月 和 客戶端機器碼標識 用戶id 組成的
(年月是做登錄保存期限用的 機器碼是在持保證用戶下次登錄時，快捷識別登錄來源，判斷是否需要重新登錄的重要憑證，用戶id其實是順便加的)
問題來了
=。= 這東西感覺做出來就和session沒什么區別
**如果直接抓一下包
每個用戶通一個平台的客戶端的token都是一樣的 對於防攻擊並沒有什么用**
而且這種token是基於用戶的 所以用戶的登錄 注冊驗證(防機器人)驗證上這種token是幫不了忙的
=。=我還在再設計一個啥 來驗證 (有辦法在這種token思路上 把登錄注冊驗證也做了嗎)
回復內容：
最近在用php寫app的接口，有一些疑問
首先關於token(令牌)
token是用戶登錄的時候生成的
用戶token在服務端保存入庫 客戶端則緩存在本地 大部分接口都要求客戶端發送token 和服務端數據庫中的token進行驗證
每個用戶唯一token 是由 年月 和 客戶端機器碼標識 用戶id 組成的
(年月是做登錄保存期限用的 機器碼是在持保證用戶下次登錄時，快捷識別登錄來源，判斷是否需要重新登錄的重要憑證，用戶id其實是順便加的)
問題來了
=。= 這東西感覺做出來就和session沒什么區別
**如果直接抓一下包
每個用戶通一個平台的客戶端的token都是一樣的 對於防攻擊並沒有什么用**
而且這種token是基於用戶的 所以用戶的登錄 注冊驗證(防機器人)驗證上這種token是幫不了忙的
=。=我還在再設計一個啥 來驗證 (有辦法在這種token思路上 把登錄注冊驗證也做了嗎)
此問題簡單至極，以php舉例。
但和session不一樣，和cookies有點接近，設計這個是為了解決cookies傳值麻煩的問題。
首先在登陸的過程中，用戶向服務端提交數據應有username、password、client_key
php在服務端拿到這些數據之后，用校驗算法獲取校驗值，如md5。
(ps:不加密碼是不行的，否則用戶修改密碼后之前的還是可以快捷登陸，這不坑人嗎)$salt是一個加密key，防止別人猜到加密算法。
$token=md5($username.$password.date('yyyy').date('mm').$client_key.$salt);計算完成后將$token返回到客戶端，作為存儲。以后客戶端只需要向服務端發送此$token和用戶名。
當php收到這個$token就再做一次上面的運算，看是否一致即可快捷判斷。
如果需要防止惡意注冊和登陸，就需要在客戶端對client_key進行加密，然后服務端解密做驗證，然而這並沒有什么卵用，一切客戶端的代碼都是不安全的，可以通過反編譯，反混淆來分析，然后照樣偽造。所以客戶端的加密沒有意義。
另外，服務器通過ip判斷也是一個辦法。
然而，從根源上來講，防止惡意攻擊就需要驗證手機號才能注冊，目前基本上通過此種方法實現。
我也在寫，還沒有實現
1.如果用戶是通過token驗證登陸的,在app上也就是類似cookie的東西,用戶拿來登陸是沒什么問題,如果是當用戶換客戶端登陸,則需要重新登陸,那在驗證的時候再獲取客戶端機器碼匹配一下.
另外客戶端的token也可以做復雜,用js進行加密處理,在php獲取再進行解析.
雖然token在一定程度上是不安全的，但是相比較，比傳遞用戶密碼來的安全。
使用token的場景一般是無狀態無cookies的模式，如果有token充當cookies中的sessionID的作用。
token雖然不安全，但是由一定程度的驗證模式，那么還是可以使其可信的
剛好前不久自己寫了篇博客，雖然沒有涉及到一些技術細節，但思路還是有的，看看對你有沒有幫助吧。
首先你要明確，Token是用於登錄后驗證身份的，所以一開始就否決了你期待用它來做防惡意注冊，這兩者完全不搭嘎。其次，要說Token與Session有什么區別，那區別就在於Token更具有定制型，因為它是由你實現的，就能干很多Session不方便干的事情，比如更好的做設備認證，更方便的控制有效期，更好的跨平台性……最重要的，HTTP協議本身定義就是無狀態的，而Cookie這種東西的存在無疑有損無狀態這個定義，所以幾乎所有的接口都拒絕使用Cookie，棄了Cookie，那Token自然成了驗證的首選。最后，Token的安全性着重於其不會被破解，不會被篡改，而不在於它傳輸時會不會被截取造成中間者攻擊。截取的防護應該是由你加強傳輸過程中的安全性來實現的，比如增加參數簽名，或者直接上HTTPS。