回顧：之前我們進行了刪除的功能，以及對message消息的增刪，下面實現添加好友的功能

我們先在數據庫中，在message這個字段的list裏面，添加上測試號的id，就是模擬這個兩個測試號要加我主號的效果“

 

 

 

就可以達到這個效果了

 

下面我們正式開始實現

1、在removeList的wxml的昵稱結構處添加一個點擊事件handleAddFriend

2、在removeList.js中來實現這個點擊事件即可的，並且它也是要提示（讓用戶選擇確認的這種，所以就可以直接copy前面的刪除按鈕的代碼

 直接把hanleDelMessage函數裏面的：

   wx.showModal({
        title: '提示信息',
        content: '刪除消息',
        confirmText: "刪除",
        success: (res) => {
          if (res.confirm) {
            
          } else if (res.cancel) {
            console.log('用戶點擊取消')
          }
        }
      })
    }

也就是只用設計在點擊了確定之後的一些列操作即可了

3、因為要構建好友之間的關係，所以要在user裏面加一個friendlist字段才行了，並且這個字段的數據類型是數組的，因為好友肯定不只是一個

4、在數據庫中給每個人都添加一個friendList字段

 

 但是不要忘記了在原來的程序中 初始化 用戶的時候也要加上讀i這個字段的初始化才行的

打開user.js：

 

5、後面的事情大概的邏輯就是：同意了好友申請的話，這個用戶的id就會出現在這個用戶的friendList數組裡面了

所以就可以回到removeList.js文件中去了

6、通過在開頭的時候 設置 const _ = db.command 就可以讓這個文件有了運算的能力了

handleAddFriend(){
      wx.showModal({
        title: '提示信息',
        content: '申請好友',
        confirmText: "同意",
        success: (res) => {
          if (res.confirm) {
              db.collection('users').doc(app.userInfo._id).update({
                data:{
                    friendList : _.unshift(this.data.messageId)
                }
              }).then((res)=>{});
          } else if (res.cancel) {
            console.log('用戶點擊取消')
          }
        }
      })
    }
  }

 

 

在點擊消息之後，就可以選擇“確定”，點擊了之後，就可以在數據庫上面看到添加的用戶好友了

（以上就是第一步，把要申請的用戶的id給添加過來了）—-但是問題來了，我的主號裏面的friendList裏面有了這個申請人的id，但是這個申請人在我

同意了之後，它的friendList字段裏面也應該有我的主號的id才對的—也就是同時添加他們兩個的好友關係即可

 

 但是能不能通過上面的這種方式，把兩個變量之間的值作為交換就可以的，普通的數據庫裏面是可以這樣的。但是在小程序中式不可以這樣進行操作的

（因為在小程序裏面對數據庫的訪問式有權限的，在客戶端是組偶到這樣的操作

（也就是對其他的賬號進行更新操作的話在客戶端裏面是不允許的—同理也是要在服務端裏面來實現的））

–也就是要用雲函數來實現了

7、如果要像的客戶端中調用unshift一樣的話在服務端裏面進行調用的話，之前也搞過就是用一個模板字符串的寫法 用Esc下面的那個 “類單引號”的符號

來進行包裹就好了

 wx.cloud.callFunction({
            name : 'update',
            data : {
              collection : 'users',
              doc : this.data.messageId,
              data : {
                friendList: ` _.unshift('${app.userInfo._id}')`
              }
            }
          });

 

 出現的錯誤就是，我們把unshift也一起搞過來了，也就是我們傳過去的字符串沒有解析成功

 主要就是下面這裏寫錯了

 data : `{ friendList:  _.unshift('${app.userInfo._id}')}`

是把後面整個的串都用一個`   ….   `來圍住的（也就是後面整個的json對象都直接被這個符號扣住的）

 

修改了之後就成功了

 

8、新建一個removeMessage 函數，可以直接copy上面的handledelMessage方法裏面的：這個函數主要是為了點擊這個消息加好友的時候，可以選擇是

添加它為好友，就是在點擊了添加好友之後，就要把這個消息刪掉了，所以這兩個地方都用到了這個功能的話，就可以把這個功能封裝在removeMesage函數裏面，如何直接用this.removeMessage來調用即可了

效果就是：點擊了添加它為好友之後，這個申請為好友的消息就會被刪掉了

 

 

db.collection('message').where({
            userId : app.userInfo._id
          }).get().then((res)=>{
              // console.log(res);
              let list = res.data[0].list;
            console.log(list);
              list = list.filter((val , i)=>{
                  return val != this.data.messageId
              });
              // console.log(list);
              wx.cloud.callFunction({
                name : 'update',
                data : {
                  collection : 'message',
                  where : {
                    userId : app.userInfo._id
                  },
                  data : {
                    list : list
                  }
                }
              }).then((res)=>{
                this.triggerEvent('myevent',list) 
              });
          });

 

 整體邏輯：

1、在removeList.wxml 中的昵稱中添加一個點擊事件 

<movable-view bindtap="handleAddFriend" direction="horizontal" class="view">{{ userMessage.nickName }}</movable-view>

2、在removeList.js中隊這個點擊事件進行渲染

 handleAddFriend(){
      wx.showModal({
        title: '提示信息',
        content: '申請好友',
        confirmText: "同意",
        success: (res) => {
          if (res.confirm) {
              db.collection('users').doc(app.userInfo._id).update({
                data:{
                    friendList : _.unshift(this.data.messageId)
                }
              }).then((res)=>{});

          //其他用戶和我構成好友的關係，用到客戶端來實現（也就是用雲函數來實現）
          wx.cloud.callFunction({
            name : 'update',
            data : {
              collection : 'users',
              doc : this.data.messageId,
              data : `{ friendList:  _.unshift('${app.userInfo._id}')}`
            }
          }).then((res)=>{});
          this.removeMessage();
          } else if (res.cancel) {
            console.log('用戶點擊取消')

          }
        }
      })
    }

3、點擊了接受邀請之後，把這個申請好友的消息刪除（和之前實現刪除功能一樣，就可以直接把這個功能封裝到removeMessage這個函數裏面

removeMessage(){
      //也就是點擊了確定的話，就不提示這個了，而是刪除信息
      //  目前沒有直接更新的，智能是這個過程就變成了先查詢然後再更新
      db.collection('message').where({
        userId: app.userInfo._id
      }).get().then((res) => {
        // console.log(res);
        let list = res.data[0].list;
        console.log(list);
        list = list.filter((val, i) => {
          return val != this.data.messageId
        });
        // console.log(list);
        wx.cloud.callFunction({
          name: 'update',
          data: {
            collection: 'message',
            where: {
              userId: app.userInfo._id
            },
            data: {
              list: list
            }
          }
        }).then((res) => {
          this.triggerEvent('myevent', list)
        });
      });

注意：因為我們開通了一個friendList 給每一個用戶數據庫字段，所以在user.js初始化用戶數據庫的時候也要加上初始化這個friendList數組才行

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※台北網頁設計公司全省服務真心推薦

※想知道最厲害的網頁設計公司"嚨底家"!

※新北清潔公司,居家、辦公、裝潢細清專業服務

※推薦評價好的iphone維修中心

摘要

經歷了一個特殊的2020上半年，疫情出乎意料的持續了半年之久，還是沒有看到結束的趨勢。雖然外部環境很惡劣，還是做出了個人的重大選擇，換工作。期間糾結了很久，畢竟工作就是生活，換工作就是對未來的期待，對過去的總結，對自己的人生的深度思考。這裏回顧下當時的個人思考，供後續復盤參考。

當前的狀況

2020，本科畢業的第六年，不再像剛畢業那會，覺得換公司是輕而易舉的事，考慮的事情越來越多。
畢業五年開始就越發的焦慮，這是當時的心境
2019年春-當前的困境、
2019秋-走的太久忘記了為什麼出發

總結起來

1. 在擁抱變化的過程中，沒有匹配上自己的個人目標
2. 工作多年還依然在糾結擅長和喜歡

老馬說的員工想要離職無非兩個原因

1. 錢沒給到位
2. 心委屈了
   分別是物質和精神方面。算是高度概括了。細分起來就是三方面錢、人、事。

錢

錢的計算相對比較複雜了。

1. 時薪和月薪
   月薪20K 的996，和15K的965相比，時薪還要低不少。但是如何選擇，每個人的情況不一樣，選擇不一樣
2. 月薪和總包
   互聯網公司的總包除了現金部分還包括股票或者期權。一般分4年歸屬，待滿兩年才能拿到一半。股票的價值不好估算，畢竟二級市場波動很大。對比股票，期權價值就更不好估算了。因為沒上市的公司估值的水分很大，另外不一定能兌現，畢竟上市沒那麼容易。但是機會和風險並存，創業公司會給很多期權來吸引(忽悠)人才加入。你想獲得高額的回報甚至是財務自由，就得冒很大的風險。

所以總收入： 現金 + 風險係數 * 股票/期權價值。 同時考慮你的時間比。

那對於當前的我來說，缺錢，但是不是缺工作跳槽的錢。怎麼說呢，就是生活基本物質得到了保障，但是更高的需求無法滿足，而這些多出來的需求靠換工作是滿足不了。所以錢不是重點考慮的。

人

互聯網的從業人員的個人素質相對比較高，加上工作專業度比較高，所以都比較簡單，沒那麼多亂七八糟的人情世故需要去處理。所以相處起來還比較愉快。

但是人與人之間是有磁場的，不是每個人都能和你對脾氣、遇到合適的領導，相近的同事也沒那麼容易，另外建立關係也需要時間。這個對於跳槽是減分項。

事

事包含兩部分，一部分是成就感，一部分個人成長機會。也就是通常說的借人成事、借事修人。

馬斯洛需求理論最高層級就是自我實現。對於互聯網人，每天除了睡覺，70%以上時間都給了工作，那自我實現肯定要在工作中實現。

那對於我個人而已，相對穩定的業務，確定性比較高，沒什麼發展前景的就沒什麼吸引力。希望是有挑戰性的工作，能把事情做成功，並且自己能夠在其中發揮重要的作用。

個人成長其實就是未來。個人成長不是一蹴而就的，短期內不易覺察。但是非常重要，互聯網更新很快，你沒跟上就被淘汰了。對於廣泛流傳的程序員成長路線，3年高工，7年架構，10年外賣。

雖然是調侃，但是也說明了幾點內容

1. 更新迭代很快的互聯網對大齡人不是很友好，你必須要持續成長。恍惚中我就工作6年，在互聯網行業中都算一個老兵了。
2. 互聯網人的職業發展與其他行業發展曲線不一樣。一個發展很快，新知識很多的領域，個體是永遠追不上行業的發展水平的。

總結來說，發展是當前跳槽的主要考慮因素。

跳槽的期望

有了換工作的想法，是對現狀的不滿，但是換一個環境並不意味着問題的解決。這也是為什麼很多人經常抱怨公司的不好，但是不挪窩的原因。我們不能寄希望於未知的事情。尤其是從18年底開始互聯網整體再走下坡路，就業環境並不好，加上今年疫情的原因，外部環境更加惡化。

但是大環境不好，不代表個體就不好。不確定性很多不代表沒有確定性的東西。人的一生就是在不斷選擇中度過的，我們必須要了解自己，抓住重點，匹配自己與環境。

那麼我的個人期望是怎麼樣的，新的工作能滿足我的期望嗎？

職業發展

之前迷茫過還要不要做程序員，能不能轉行到產品，諮詢，售前。現在不能說篤定了一直做技術，但是找到了一些發展規律。

1. 不會再去做偏底層的技術
   以前做過大數據，BI，甚至3年前還拿到過大數據工程師的offer,現在也深入了解了運維、中間件相關的工作內容。徹底打消了偏技術側的技術開發。
2. 解決問題為驅動
   問題為導向，離業務越近越好。通過技術來驅動業務，非技術手段來解決業務問題。

這個算是近兩年個人的一個不小的突破，排除了哪些事不會去做，哪些事要去嘗試探索。

行業

行業涉及面太廣了，現在toC不好做，巨頭林立把用戶時間都擠佔了。toB 更難了，工具效率型的，國內目前付費意願並不強，能幫助企業帶來收入的才能發展的下去。

個人目前對具體做哪個行業的並沒有那麼執着。更多的期望是能夠以某個點切入到某個行業，然後看到如何通過互聯網技術把問題解決了，形成閉環，把事情做成功了。這種成就感足以讓我興奮。因為這些年，在不同的公司做各種創業項目，都沒有做成功的，都因為各種原因死掉了。正因如此，才知道創業是如何的艱難與不易。

通過自我的剖析和明確當前職業發展目標，在2020年春夏之際，我成功換了工作。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※台北網頁設計公司全省服務真心推薦

※想知道最厲害的網頁設計公司"嚨底家"!

※新北清潔公司,居家、辦公、裝潢細清專業服務

※推薦評價好的iphone維修中心

抱歉用這種標題吸引你點進來了，不過你不妨看完，看看能否讓你有所收穫。​（有收穫，請評論區留個言，沒收穫，下周末我直播吃**，哈哈，這你也信）

補充說明：微信公眾號改版，對各個號主影響還挺大的。目前從後台數據來看，對我影響不大，因為我這反正都是小號，閱讀量本身就少的可憐，真相了，狗頭（剛從交流群學會的表情）。

先直接上代碼：

boolean safeEqual(String a, String b) { if (a.length() != b.length()) { return false; } int equal = 0; for (int i = 0; i < a.length(); i++) { equal |= a.charAt(i) ^ b.charAt(i); } return equal == 0; } 

上面的代碼是我根據原版（Scala）翻譯成 Java的，Scala 版本（最開始吸引程序猿石頭注意力的代碼）如下：

def safeEqual(a: String, b: String) = { if (a.length != b.length) { false } else { var equal = 0 for (i <- Array.range(0, a.length)) { equal |= a(i) ^ b(i) } equal == 0 } } 

剛開始看到這段源碼感覺挺奇怪的，這個函數的功能是比較兩個字符串是否相等，首先“長度不等結果肯定不等，立即返回”這個很好理解。

再看看後面的，稍微動下腦筋，轉彎下也能明白這其中的門道：通過異或操作1^1=0, 1^0=1, 0^0=0，來比較每一位，如果每一位都相等的話，兩個字符串肯定相等，最後存儲累計異或值的變量equal必定為 0，否則為 1。

再細想一下呢？

for (i <- Array.range(0, a.length)) { if (a(i) ^ b(i) != 0) // or a(i) != b[i] return false } 

我們常常講性能優化，從效率角度上講，難道不是應該只要中途發現某一位的結果不同了（即為1）就可以立即返回兩個字符串不相等了嗎？(如上所示)

這其中肯定有……

再再細想一下呢？

結合方法名稱 safeEquals 可能知道些眉目，與安全有關。

本文開篇的代碼來自playframewok 里用來驗證cookie(session)中的數據是否合法(包含簽名的驗證)，也是石頭寫這篇文章的由來。

以前知道通過延遲計算等手段來提高效率的手段，但這種已經算出結果卻延遲返回的，還是頭一回！

我們來看看，JDK 中也有類似的方法，如下代碼摘自 java.security.MessageDigest：

public static boolean isEqual(byte[] digesta, byte[] digestb) { if (digesta == digestb) return true; if (digesta == null || digestb == null) { return false; } if (digesta.length != digestb.length) { return false; } int result = 0; // time-constant comparison for (int i = 0; i < digesta.length; i++) { result |= digesta[i] ^ digestb[i]; } return result == 0; } 

看註釋知道了，目的是為了用常量時間複雜度進行比較。

但這個計算過程耗費的時間不是常量有啥風險？ （腦海里響起了背景音樂：“小朋友，你是否有很多問號？”）

真相大白

再深入探索和了解了一下，原來這麼做是為了防止計時攻擊（Timing Attack）。（也有人翻譯成時序攻擊​）​

計時攻擊(Timing Attack)

計時攻擊是邊信道攻擊(或稱”側信道攻擊”， Side Channel Attack， 簡稱SCA) 的一種，邊信道攻擊是一種針對軟件或硬件設計缺陷，走“歪門邪道”的一種攻擊方式。

這種攻擊方式是通過功耗、時序、電磁泄漏等方式達到破解目的。在很多物理隔絕的環境中，往往也能出奇制勝，這類新型攻擊的有效性遠高於傳統的密碼分析的數學方法（某百科上說的）。

這種手段可以讓調用 safeEquals("abcdefghijklmn", "xbcdefghijklmn") （只有首位不相同）和調用 safeEquals("abcdefghijklmn", "abcdefghijklmn") （兩個完全相同的字符串）的所耗費的時間一樣。防止通過大量的改變輸入並通過統計運行時間來暴力破解出要比較的字符串。

舉個，如果用之前說的“高效”的方式來實現的話。假設某個用戶設置了密碼為 password，通過從a到z（實際範圍可能更廣）不斷枚舉第一位，最終統計發現 p0000000 的運行時間比其他從任意a~z的都長（因為要到第二位才能發現不同，其他非 p 開頭的字符串第一位不同就直接返回了），這樣就能猜測出用戶密碼的第一位很可能是p了，然後再不斷一位一位迭代下去最終破解出用戶的密碼。

當然，以上是從理論角度分析，確實容易理解。但實際上好像通過統計運行時間總感覺不太靠譜，這個運行時間對環境太敏感了，比如網絡，內存，CPU負載等等都會影響。

但安全問題感覺更像是 “寧可信其有，不可信其無”。為了防止(特別是與簽名/密碼驗證等相關的操作)被 timing attack，目前各大語言都提供了相應的安全比較函數。各種軟件系統（例如 OpenSSL）、框架（例如 Play）的實現也都採用了這種方式。

例如 “世界上最好的編程語言”（粉絲較少，評論區應該打不起架來）—— php中的:

// Compares two strings using the same time whether they're equal or not. // This function should be used to mitigate timing attacks; // for instance, when testing crypt() password hashes. bool hash_equals ( string $known_string , string $user_string ) //This function is safe against timing attacks. boolean password_verify ( string $password , string $hash ) 

其實各種語言版本的實現方式都與上面的版本差不多，將兩個字符串每一位取出來異或(^)並用或(|)保存，最後通過判斷結果是否為 0 來確定兩個字符串是否相等。

如果剛開始沒有用 safeEquals 去實現，後續的版本還會通過打補丁的方式去修復這樣的安全隱患。

例如 JDK 1.6.0_17 中的Release Notes^[1]中就提到了MessageDigest.isEqual 中的bug的修復，如下圖所示：

MessageDigest timing attack vulnerabilities

大家可以看看這次變更的的詳細信息openjdk中的 bug fix diff^[2]為：

MessageDigest.isEqual計時攻擊

Timing Attack 真的可行嗎？

我覺得各大語言的 API 都用這種實現，肯定還是有道理的，理論上應該可以被利用的。 這不，學術界的這篇論文就宣稱用這種計時攻擊的方法破解了 OpenSSL 0.9.7 的RSA加密算法了。關於 RSA 算法的介紹可以看看之前本人寫的這篇文章。

這篇Remote Timing Attacks are Practical^[3] 論文中指出（我大致翻譯下摘要，感興趣的同學可以通過文末鏈接去看原文）：

計時攻擊往往用於攻擊一些性能較弱的計算設備，例如一些智能卡。我們通過實驗發現，也能用於攻擊普通的軟件系統。本文通過實驗證明，通過這種計時攻擊方式能夠攻破一個基於 OpenSSL 的 web 服務器的私鑰。結果證明計時攻擊用於進行網絡攻擊在實踐中可行的，因此各大安全系統需要抵禦這種風險。

最後，本人畢竟不是專研完全方向，以上描述是基於本人的理解，如果有不對的地方，還請大家留言指出來。感謝。

補充說明2：感謝正在閱讀文章的你，讓我還有動力繼續堅持更新原創。

本人發文不多，但希望寫的文章能達到的目的是：佔用你的閱讀時間，就盡量能夠讓你有所收穫。

如果你覺得我的文章有所幫助，還請你幫忙轉發分享，另外請別忘了點擊公眾號右上角加個星標，好讓你別錯過後續的精彩文章（微信改版了，或許我發的文章都不能推送到你那了）。

​原創真心不易，希望你能幫我個小忙唄，如果本文內容你覺得有所啟發，有所收穫，請幫忙點個“在看”唄，或者轉發分享讓更多的小夥伴看到。 ​ 參考資料：

• Timing Attacks on RSA: Revealing Your Secrets through the Fourth Dimension
• Remote Timing Attacks are Practical

參考資料

[1] Release Notes: http://www.oracle.com/technetwork/java/javase/6u17-141447.html

[2] openjdk中的 bug fix diff: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/562da0baf70b

[3] Remote Timing Attacks are Practical: http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※台北網頁設計公司全省服務真心推薦

※想知道最厲害的網頁設計公司"嚨底家"!

※新北清潔公司,居家、辦公、裝潢細清專業服務

※推薦評價好的iphone維修中心