掘金登陸引起的思考

寫在前面

近日看了幾篇關於自動發佈掘金文章的帖子。都是後端直接調用發佈文章的接口配合定時任務完成的。可是缺點就是繞過了登陸掘金的步驟。經過手動獲取頁面的 cookie ，而後將 cookie 交給程序，完成自動發佈的功能。因此今天就從技術的角度出發，一探掘金的登陸時如何實現的。

正文開始

首先聲明這裏只探討技術實現。

1. 問題提出的背景

在這次文章打卡的活動中，會存在寫好文章存在草稿箱，可是忘了發佈文章致使斷更的狀況發生。因而就突發奇想，可否有自動發佈文章的功能，幫助咱們完成一部分自動化的工做，去解決漏發佈的問題。

因而就從文章發佈的接口入手，咱們先看掘金文章發佈的邏輯；

• a. 文章新建後都會存入草稿，而且生成惟一的ID。
• b. 文章編輯不發佈依舊是在草稿箱，文章ID不變。
• c. 文章發佈時填寫必要的標籤後，便可發佈成功。
• d. 文章發佈完成，經過審覈即會變成可讀狀態，便可分享於他人。

下面是發佈接口具體的參數以及地址：

• 接口地址：api.juejin.cn/content_api…
• 請求方式：POST
• 請求參數：

參數	類型	說明
draft_id	字符串	文章ID
sync_to_org	布爾	是否同步
column_ids	列表	未知

對於 python 處理這種事情很簡單，相似這樣：

# 代碼爲演示代碼
body = {
    "draft_id": "123456",
    "sync_to_org": False,
    "column_ids": []
}
requests.post(self.publish_url, body=body)
複製代碼

很明顯這麼作是行不通的。由於在代碼中是沒有體現出任何登陸的操做。下面就看一下掘金的登陸實現。

2. 登陸方式

目的：已知用戶名密碼的狀況實現自動登陸。

• 手機驗證碼登陸

• 帳號密碼登陸

手機驗證碼登陸因爲每次都須要動態的獲取驗證碼，因此這裏就不考慮；第三方登陸本質上也是須要登陸其餘帳號，這裏也不考慮；因此咱們只須要查看 掘金帳號密碼登陸便可；那麼咱們就研究一下這個東西。

在正常輸入用戶名密碼後會出現滑動驗證碼，須要手動驗證才能經過。

彷佛問題到這裏陷入了死衚衕。個人目的是爲了自動登陸，可是查看了幾種方式後繞不開人爲的介入。

3. 深刻探究

通過思考登陸的本質是一個 POST 請求的過程也就是發送請求就能夠完成。因此繼續沿着這個思路繼續查看登陸的接口，下圖爲登陸時具體的接口。

如圖請求的接口與請求的參數都有，可是參數明顯是加密處理事後的數據。

這裏繼續深刻了解後得知大體的登陸流程，這裏沒有作深刻了解只是根據本身的經驗總結的結果。

• 滑動驗證過程

• 登陸過程，此過程用戶名&密碼加密

因此要想經過腳本的方式登陸成功就須要完成兩件事：

1. 滑動驗證碼請求參數的構造
2. 登陸接口請求參數構造

可是努力查詢掘金前端的代碼，雖然說能找到一些蛛絲馬跡。可是終究是被前端代碼的量以及動態加載的 JS 搞怕了，花出的時間可能與收穫不成正比。卒，享年28歲。

PS：這裏提供的破解思路是可行的，但願有能力的小夥伴研究出來以後，能夠一塊兒探討。

總結

掘金的登陸兩個比較重要的功能：

• 經過滑動驗證碼肯定操做者身份爲真實用戶。
• 經過前端加密後端解密的方式避免登陸過程當中明文傳輸用戶信息。

二者結合就實現了比較安全的登陸方式，使得大部分程序員想經過程序直接登陸掘金的夢想直接破滅。

因此想實現自動發佈的功能，須要另闢蹊徑才能達到目的。