国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

剝開比原看代碼09:通過dashboard創建密鑰時,前端的數據是如何傳到后端的?

MangoGoing / 1432人閱讀

摘要:下一步,將進入比原的節點也就是后端。它具體是怎么創建密鑰的,這在以后的文章中將詳細討論。當我們清楚了在本文中,前后端數據是如何交互的,就很容易推廣到更多的情景。

作者:freewind

比原項目倉庫:

Github地址:https://github.com/Bytom/bytom

Gitee地址:https://gitee.com/BytomBlockc...

在前面一篇文章,我們粗略的研究了一下比原的dashboard是如何做出來的,但是對里面提到的各種細節功能,并沒有深入的去研究。那么從本文開始,我們將在這一段時間,分別研究里面提到的每一項功能。

在前一篇文章中,當我們第一次在瀏覽器中打開dashboard時,因為還沒有創建過密鑰,所以比原會提示我們輸入一些別名和密碼,為我們創建一個密鑰和相應的帳戶。就是下面這張圖所對應的:

那么本文就將研究一下,當我們點擊了"Register"按鈕以后,我們在前端頁面上填寫的參數,到底是如何一步步的傳到比原的后端的。

跟之前一樣,我們將對這個問題進行細分,然后各個擊破:

前端:當我們填完表單,點了提交以后,比原在前端是如何發送數據的?

后端:比原的后端是如何接收到數據的?

前端:當我們填完表單,點了提交以后,數據會發送到后端的哪個接口?

當我們點擊了"Register"按鈕,在前端頁面中,一定會在某個地方觸發一個向比原節點webapi接口發出請求的操作。究竟是訪問的哪個web api?提交的數據又是什么樣的呢?讓我們先從前端代碼中尋找一下。

注意,比原的前端代碼位于另一個項目倉庫bytom/dashboard中。為了能與我們在本系列文章中使用的比原v1.0.1的代碼相匹配,我找到了dashboard中的v1.0.0的代碼,并且提交到了一個多帶帶的項目中:freewind/bytom-dashboard-v1.0.0。注意該項目代碼未做任何修改,其master分支對應于官方代碼倉庫的v1.0.0分支。之所以要弄一個多帶帶的出來,這是因為我們在文章中,每次引用一段代碼的時候,都會給出相應的github上的鏈接,方便讀者跳過去查看全貌,使用一個獨立項目,會讓這個過程更簡便一些。

由于比原的前端頁面是使用React為主的,所以我猜想在代碼中,也該會有一個名為Register的組件,或者某個表單中有一個名為Register的按鈕。經過搜索,我們幸運的發現了Register.jsx 這個組件文件,它正好是我們需要的。

經過高度簡化后的代碼如下:

src/features/app/components/Register/Register.jsx#L9-L148

class Register extends React.Component {
  // ...
  // 4. 
  submitWithErrors(data) {
    return new Promise((resolve, reject) => {
      // 5. 
      this.props.registerKey(data)
        .catch((err) => reject({_error: err.message}))
    })
  }
  // ...

  render() {
    // ...
    return (
      // ...
      // 3.
      
// 1. // 2. // .... // ... ) } }

上面的代碼,共有5個地方需要注意,被我用數字標示出來了。注意這5個數字并不是從上到下標注,而是按照我們關注的順序來的:

表單上的各個輸入框,就是我們填寫別名和密碼的地方。這里需要關注的是每個TextFieldfieldProps屬性,它對應我們提交到后臺的數據的name

就是那個“Register”按鈕了。需要注意的是,它的typesubmit,也就是說,點擊它以后,將會觸發所在formonSubmit方法

回到了form的開頭。注意它的onSubmit里面,調用的是handleSubmit(this.submitWithErrors)。其中的handleSubmit是從該表單所使用的第三方redux-form中傳入的,用來處理表單提交,我們在這里不關注它,只需要知道我們需要把自己的處理函數this.submitWithErrors傳給它。而在后者中,我們將會調用比原節點提供的web api

第3步中的this.submitWithErrors最終將走到這里定義的submitWithErrors函數

submitWithErrors將會發起一個異步請求,最終調用由外部傳進來的registerKey函數

從這里我們還看不到調用的是哪個api,所以我們必須繼續去尋找registerKey。很快就在同文件中找到了registerKey

src/features/app/components/Register/Register.jsx#L176-L180

(dispatch) => ({
    registerKey: (token) => dispatch(actions.core.registerKey(token)),
    // ...
  })

它又將會調用actions.core.registerKey這個函數:

src/features/core/actions.js#L44-L87

const registerKey = (data) => {
  return (dispatch) => {
    // ...
    // 1.1
    const keyData = {
      "alias": data.keyAlias,
      "password": data.password
    }
    // 1.2
    return chainClient().mockHsm.keys.create(keyData)
      .then((resp) => {
        // ...
        // 2.1
        const accountData = {
          "root_xpubs":[resp.data.xpub],
          "quorum":1,
          "alias": data.accountAlias}
        // 2.2
        dispatch({type: "CREATE_REGISTER_KEY", data})

        // 2.3
        chainClient().accounts.create(accountData)
          .then((resp) => {
            // ...
            // 2.4
            if(resp.status === "success") {
              dispatch({type: "CREATE_REGISTER_ACCOUNT", resp})
            }
          })
    // ...
      })
    // ...
  }
}

可以看到,在這個函數中,做的事情還是很多的。而且并不是我一開始預料的調用一次后臺接口就行了,而是調用了兩次(分別是創建密鑰和創建帳戶)。下面進行分析:

1.1是為了讓后臺創建密鑰而需要準備的參數,一個是alias,一個是password,它們都是用戶填寫的

1.2是調用后臺用于創建密鑰的接口,把keyData傳過去,并且拿到返回的resp后,進行后續的處理

2.1是為了讓后臺創建帳戶而需要準備的參數,分別是root_xpubs, quorumalias,其中root_xpubs是創建密鑰后返回的公鑰,quorum目前不知道(TODO),alias是用戶填寫的帳戶別名

2.2這一句沒有作用(經過官方確認了),因為我在代碼中沒有找到處理CREATE_REGISTER_KEY的代碼??梢钥催@個issue#28

2.3調用后臺創建帳戶,把accountData傳過去,可以拿到返回的resp

2.4調用成功后,再使用redux的dispatch函數分發一個CREATE_REGISTER_ACCOUNT信息。不過這個信息好像也沒有太大用處。

關于CREATE_REGISTER_ACCOUNT,我在代碼中找到了兩處相關:

src/features/core/reducers.js#L229-L234

const accountInit = (state = false, action) => {
  if (action.type == "CREATE_REGISTER_ACCOUNT") {
    return true
  }
  return state
}

src/features/app/reducers.js#L10-L115

export const flashMessages = (state = {}, action) => {
  switch (action.type) {
    // ...
    case "CREATE_REGISTER_ACCOUNT": {
      return newSuccess(state, "CREATE_REGISTER_ACCOUNT")
    }
    // ...
  }
}

第一個看起來沒什么用,第二個應該是用來在操作完成后,顯示相關的錯誤信息。

那就讓我們把關注點放在1.22.3這兩個后臺調用的地方吧。

chainClient().mockHsm.keys.create(keyData)對應的是:

src/sdk/api/mockHsmKeys.js#L3-L31

const mockHsmKeysAPI = (client) => {
  return {
    create: (params, cb) => {
      let body = Object.assign({}, params)
      const uri = body.xprv ? "/import-private-key" : "/create-key"

      return shared.tryCallback(
        client.request(uri, body).then(data => data),
        cb
      )
    },
    // ...
  }
}

可以看到在create方法中,如果找不到body.xprv(就是本文對應的情況),則會調用后臺的/create-key接口。經過一長串的跟蹤,我們終于找到了一個。

chainClient().accounts.create(accountData)對應的是:

src/sdk/api/accounts.js#L3-L30

const accountsAPI = (client) => {
  return {
    create: (params, cb) => shared.create(client, "/create-account", params, {cb, skipArray: true}),
    // ...
  }
}

很快我們在這邊,也找到了創建帳戶時調用的接口為/create-account

前端這邊,我們終于分析完了。下一步,將進入比原的節點(也就是后端)。

后端:比原的后端是如何接收到數據的?

如果我們對前一篇文章還有印象的話,會記得比原在啟動之后,會在Node.initAndstartApiServer方法中啟動web api對應的http服務,并且在API.buildHandler()方法中會配置很多的功能點,其中一定會有我們這里調用的接口。

讓我們看看API.buildHandler方法:

api/api.go#L164-L244

func (a *API) buildHandler() {
    walletEnable := false
    m := http.NewServeMux()

    if a.wallet != nil {
        walletEnable = true
        // ...
        m.Handle("/create-account", jsonHandler(a.createAccount))
        // ...
        m.Handle("/create-key", jsonHandler(a.pseudohsmCreateKey))
        // ...

很快,我們就發現了:

/create-account: 對應a.createAccount

/create-key: 對應a.pseudohsmCreateKey

讓我們先看一下a.pseudohsmCreateKey

api/hsm.go#L23-L32

func (a *API) pseudohsmCreateKey(ctx context.Context, in struct {
    Alias    string `json:"alias"`
    Password string `json:"password"`
}) Response {
    // ...
}

可以看到,pseudohsmCreateKey的第二個參數,是一個struct,它有兩個字段,分別是AliasPassword,這正好和前面從前端傳過來的參數keyData對應。那么這個參數的值是怎么由提交的JSON數據轉換過來的呢?上次我們說到,主要是由a.pseudohsmCreateKey外面套著的那個jsonHandler進行的,它會處理與http協議相關的操作,以及把JSON數據轉換成這里需要的Go類型的參數,pseudohsmCreateKey就可以直接用了。

由于在這個小問題中,我們問題的邊界是比原后臺是如何拿到數據的,所以我們到這里就可以停止對這個方法的分析了。它具體是怎么創建密鑰的,這在以后的文章中將詳細討論。

再看a.createAccount

api/accounts.go#L15-L30

// POST /create-account
func (a *API) createAccount(ctx context.Context, ins struct {
    RootXPubs []chainkd.XPub `json:"root_xpubs"`
    Quorum    int            `json:"quorum"`
    Alias     string         `json:"alias"`
}) Response {
    // ...
}

與前面一樣,這個方法的參數RootXPubs、QuorumAlias也是由前端提交,并且由jsonHandler自動轉換好的。

當我們清楚了在本文中,前后端數據是如何交互的,就很容易推廣到更多的情景。在前端還在很多的頁面和表單,在很多地方都需要調用后端的接口,我相信按照本文的思路,應該都可以快速的找到。如果有比較特殊的情況,我們以后會再專門寫文章講解。

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/24183.html

相關文章

  • 剝開原看代碼10:比原如何通過/create-key接口創建密鑰

    摘要:如果傳的是,就會在內部使用默認的隨機數生成器生成隨機數并生成密鑰。使用的是,生成的是一個形如這樣的全球唯一的隨機數把密鑰以文件形式保存在硬盤上。 作者:freewind 比原項目倉庫: Github地址:https://github.com/Bytom/bytom Gitee地址:https://gitee.com/BytomBlockc... 在前一篇,我們探討了從瀏覽器的dashb...

    ccj659 評論0 收藏0
  • 剝開原看代碼11:比原如何通過接口/create-account創建帳戶

    摘要:而本文將繼續討論,比原是如何通過接口來創建帳戶的。把各信息打包在一起,稱之為另外,在第處還是一個需要注意的。比原在代碼中使用它保存各種數據,比如區塊帳戶等。到這里,我們已經差不多清楚了比原的是如何根據用戶提交的參數來創建帳戶的。 作者:freewind 比原項目倉庫: Github地址:https://github.com/Bytom/bytom Gitee地址:https://git...

    haobowd 評論0 收藏0
  • 剝開原看代碼08:比原Dashboard怎么做出來?

    摘要:所以本文本來是想去研究一下,當別的節點把區塊數據發給我們之后,我們應該怎么處理,現在換成研究比原的是怎么做出來的。進去后會看到大量的與相關的配置。它的功能主要是為了在訪問與的函數之間增加了一層轉換。 作者:freewind 比原項目倉庫: Github地址:https://github.com/Bytom/bytom Gitee地址:https://gitee.com/BytomBlo...

    CHENGKANG 評論0 收藏0
  • 剝開原看代碼12:比原如何通過/create-account-receiver創建地址

    摘要:繼續看生成地址的方法由于這個方法里傳過來的是而不是對象,所以還需要再用查一遍,然后,再調用這個私有方法創建地址該方法可以分成部分在第塊中主要關注的是返回值。 作者:freewind 比原項目倉庫: Github地址:https://github.com/Bytom/bytom Gitee地址:https://gitee.com/BytomBlockc... 在比原的dashboard中...

    oneasp 評論0 收藏0
  • 剝開原看代碼01:初始化生成配置文件在哪兒

    摘要:所以這個文章系列叫作剝開比原看代碼。所以我的問題是比原初始化時,產生了什么樣的配置文件,放在了哪個目錄下下面我將結合源代碼,來回答這個問題。將用來確認數據目錄是有效的,并且將根據傳入的不同,來生成不同的內容寫入到配置文件中。 作者:freewind 比原項目倉庫: Github地址:https://github.com/Bytom/bytom Gitee地址:https://gitee...

    felix0913 評論0 收藏0

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<