Q8. [個人技能題組][Backend] 第一個功能：會員註冊，開發 API。

[wildwindjen]

繼續「會員註冊」功能的開發，開始設計後端 API，供註冊使用。要注意幾件事：

• 不允許相同帳號(email)重複註冊
• email 格式要檢查是否為 email 格式
• 密碼要加密再存，不可逆。

a. 請提供 github 上的程式碼路徑。
b. 學到哪些 sql 的用法？
c. 什麼是 API？
d. 什麼是 HTTP？
e. 為什麼密碼要加密再存？你用什麼方式加密？
f. 你怎麼測試你的程式？請提供你的驗收項目清單。

提示：
關於驗收項目清單，實務上會從任務目標，整理出之後要驗收的項目，只有清單上面每個項目都通過了，才能說任務完成。能不能整理出驗收項目清單，就看你多了解你這次任務的目的。

答題時間: 12 hr

[dustfantasy]

「於 2017/03/28 開始答題」
a.
https://gitlab.com/enioy74/Practice1/tree/master
b.
select查詢顯示table資料
insert into增加資料
c.
應用程式介面。
介面是溝通的管道，而程式要使用另一程式的功能就必須與之溝通，因此必須使用對方提供的介面，也就是API，進行聯繫。
d.
超文本傳輸協議。
一種非強制性的傳輸標準，提供一種請求與響應的基準規則。
e.
將密碼加密後存于資料庫，在資料庫資料洩漏時也不會讓人得知帳號密碼。
hmac的md5加密，因為我覺得單單用hash的md5加密因為碰撞問題並不安全。
f.
使用postman做測試。
驗收項目有四，重複帳號註冊偵測，重複email註冊偵測，email 格式檢查 ,資料庫的密碼是否加密且正確。
對於重複註冊跟檢查 email 格式都做了錯誤訊息回應。

A 重複帳號註冊偵測
1.
進行重複的帳號註冊測試，預期回傳'帳號已被使用'的訊息，
不重複的測試資料「account:a,password:123,email:[email protected]」，
結果：正確。
2.
進行不重複的帳號註冊測試，預期回傳'註冊成功'的訊息，
不重複的測試資料「account:b,password:123,email:[email protected]」，
結果：正確。

B 重複email註冊偵測
1.
進行重複的email註冊測試，預期回傳'信箱已被使用'的訊息，
重複的測試資料「account:c,password:123,email:[email protected]」，
結果：正確。
2.
進行不重複的email註冊測試，預期回傳'註冊成功'的訊息，
重複的測試資料「account:c,password:123,email:[email protected]」，
結果：正確。

C email 格式檢查
將 email 格式檢查程式獨立出來，進行email格式檢測，正確印出'正確'錯誤印出'錯誤'。
基礎格式為[email protected]，其中不允許空格、.、@符號。
以資料[
'[email protected]',
'[email protected]',
'aa@gmail',
'@gmail.com',
'[email protected]',
'a [email protected]',
'[email protected] m',
'aa@gma il.com',
]進行測試
預期「正確，正確，錯誤，錯誤，錯誤，錯誤，錯誤，錯誤」
印出「正確，正確，錯誤，錯誤，錯誤，錯誤，錯誤，錯誤」
結果：正確。

D 資料庫的密碼是否加密且正確
在程式中加密的部份使用console.log印出加密後的密碼，開啟資料庫的資料進行比對確認。
結果：正確。

「於 2017/03/28 答題結束」

[wildwindjen]

@dustfantasy

d. HTTP 是「網路安全傳輸協議。」？
f. 驗收清單的項目要再細一點、條列式。

[wildwindjen]

@dustfantasy

驗證習慣最好包含「正向」跟「反向」，我拿「重複帳號註冊偵測」舉例

A. 驗證「重複帳號註冊偵測」
a.1 拿重複帳號註冊，測試資料「account:xxx, password:xxx」，預期會丟出重複的訊息。
a.2 拿不重複帳號註冊，測試資料「account:ooo, password:ooo」，預期會註冊成功的訊息。

[dwatow]

「於 2017/04/03 開始答題」
a. 請提供 github 上的程式碼路徑。
https://github.com/dwatow/LaidBackHabitat
(之前建過的一個project)
b. 學到哪些 sql 的用法？
SELECT
UPDATE

c. 什麼是 API？
就是「應用程式介面」在此例，就是把程式複雜度隱藏成一個網址。
d. 什麼是 HTTP？
一種TCP/IP上運作的協定。

e. 為什麼密碼要加密再存？你用什麼方式加密？
防中間人攻擊，直接讓人看見明碼。
rsa加密演算法

f. 你怎麼測試你的程式？請提供你的驗收項目清單。
驗證是否重複: 在資料庫找是否有相同的資料

「於 2017/04/03 答題結束」

[PenguinRun]

「於 2017/04/10 開始答題」

a. 請提供 github 上的程式碼路徑。
model:
https://github.com/PenguinRun/ShoppingCart/blob/master/models/customer/add_model.js
controller:
https://github.com/PenguinRun/ShoppingCart/blob/master/controllers/customer/add_controller.js

b. 學到哪些 sql 的用法？
痾...沒有

c. 什麼是 API？
將程式碼放置在某一網址中，前端及後端可以透過該網址來做溝通。
前端透過該網址不僅可以取得後端資料（若有資料），前端也能透過該網址來傳輸資料給後端。

d. 什麼是 HTTP？
一種Client端(前端)與Server端(後端)之間的通訊協定。

e. 為什麼密碼要加密再存？你用什麼方式加密？
為了怕別人知道密碼，用來做壞事情。
nodejs中cypto的hamc其SHA-1。

f. 你怎麼測試你的程式？請提供你的驗收項目清單。

驗收「確認必填欄位」

1. Name欄位是否填寫

• 有 -> 測試資料：「Name: 123」，預期結果「進行判斷Password欄位是否填寫」
• 沒有 -> 測試資料： 「Name:」，預期結果「回應：please enter the [Name] value」

2. Password欄位是否填寫

• 有 -> 測試資料：「Password: test」，預期結果「進行判斷Email欄位是否填寫」
• 沒有 -> 測試資料： 「Password:」，預期結果「回應：please enter the [Password] value」

3. Email欄位是否填寫

• 有 -> 測試資料：「Email: [email protected]」，預期結果「進行判斷img欄位是否填寫」
• 沒有 -> 測試資料： 「Email:」，預期結果「回應：please enter the [Email] value」

4. img欄位是否填寫

• 有 -> 測試資料：「img: 123.jpg」，預期結果「進行上傳檔案有沒有超過1MB判斷」
• 沒有 -> 測試資料： 「img:」，預期結果「回應：請選擇一個檔案」

驗收「上傳檔案有沒有超過1MB」

• 有 -> 測試資料： 「img:123.jpg(小於1MB)」，預期結果「進行檔案格式是否符合jpg, jpeg or png其中一種判斷」
• 沒有 -> 測試資料： 「456.jpg(大於1MB)」，預期結果「回應：請上傳小於1MB的檔案」

驗收「img欄位是否符合jpg, jpeg or png其中一種」

• 有 -> 測試資料：「img:123.jpg」，預期結果「進行email格式正不正確判斷」
• 沒有 -> 測試資料：「img:456.odt」，預期結果「回應：請選擇正確的檔案格式。如：png, jpg, jpeg等。」

驗收「email格式正不正確」

• 正確 ->測試資料：「[email protected]」，
• 不正確 ->測試資料：「」

驗收「email 欄位是否填寫」

• 有 -> 測試資料：「Email: [email protected]」，預期結果：「進行email是否重複判斷」
• 沒有 -> 測試資料：「Email: [email protected]」，預期結果：「回應：請輸入正確的Eamil格式。(如[email protected])」

驗收「email是否重複」

• 有->測試資料：「[email protected]」，預期結果：「回應：已有重複的Email。」
• 沒有->測試資料：「[email protected]」，預期結果：「回應：result（如下例所述）」

{
  "result": {
    "addData": {
      "Name": "test",
      "Password": "a08369e82fe3534b889e9ecddd602e4a865f29f2",
      "Email": "[email protected]",
      "Img": base64碼,
      "ImgName": "123.jpg"
    }
  }
}

「於2017/04/10 答題結束」

[YenChunchen]

「於 2017/04/12 開始答題」
a. 請提供 github 上的程式碼路徑。 https://github.com/YenChunchen/backend-tranining
b. 學到哪些 sql 的用法？
SELECT 欄位名稱 FROM 資料表名稱 WHERE 篩選欄位=欄位值;
c. 什麼是 API？應用程式介面,程式系統間互相溝通的窗口介面
d. 什麼是 HTTP？超文本傳輸協定,目前網路上應用最廣範的網路傳輸協定,其相關規範在RFC中定義
e. 為什麼密碼要加密再存？你用什麼方式加密？防止有心人士可以直接取得密碼,作惡意的行為;sha-256
f. 你怎麼測試你的程式？請提供你的驗收項目清單。

1.判斷前端傳來的必要參數(account,pwd)是否正確

• 如任一欄位為空值或無該欄位(account=[email protected],pwd='')：回應(請輸入正確欄位);

• 欄位正確(account=[email protected],pwd='111')則接續步驟2

2.判斷account是否為e-mail格式

• 如不為email格式(account=aaa,pwd=111)：回應(請輸入正確欄位);

• 格式正確(account=aaa@gmail,pwd=111)則接續步驟3

3.判斷account是否已被註冊

• 如account已存在(account=aaa@gmail,pwd=111)(DB中已存在)：回應(該會員已存在);

• 帳號未註冊過(account=bbb@gmail,pwd=222)則接續步驟4

4.將最終合法資料加入資料庫

• 回應(會員創建成功);後至DB中查看該筆資料已新增

[wildwindjen]

@PenguinRun
建議驗收清單項目的描述不要太籠統
實務上能越具體越好，這代表你對要開發的部分掌握度很高。

ex:
「有沒有輸入會員欄位資料」這個
假設你的會員欄位是「email」跟「password」兩個
那就分列兩細項去描述，如：

確認必填欄位
1. email 欄位是否填寫
	有 -> ...
	沒有 -> ...
2. password 欄位是否填寫
	有 -> ...
	沒有 -> ...

@PenguinRun
@YenChunchen

寫驗收項目，最好現在就養成習慣，加上驗收時的測試資料資訊。
可以看上面 dustfantasy 的做法。

[PenguinRun]

@wildwindjen 已修改完成

[HoHow]

「於 2017/04/28 開始答題」
繼續「會員註冊」功能的開發，開始設計後端 API，供註冊使用。要注意幾件事：

不允許相同帳號(email)重複註冊
email 格式要檢查是否為 email 格式
密碼要加密再存，不可逆。

a. 請提供 github 上的程式碼路徑。
https://github.com/HoHow/first_member

b. 學到哪些 sql 的用法？
select...from...where...

c. 什麼是 API？
提供給前端串接的程式

d. 什麼是 HTTP？
HTTP是一個用於在客戶端和伺服器間請求和應答的協議。
e. 為什麼密碼要加密再存？你用什麼方式加密？
確保密碼不會外洩，目前是使用sha-1
f. 你怎麼測試你的程式？請提供你的驗收項目清單。
驗證帳號重覆
是：已存在帳號，此帳號已被使用
否：順利執行
驗證姓名
是：已存在姓名，此姓名已被使用
否：順利執行
驗證email
是：已存在email，此email已被使用
否：順利執行
驗證密碼
密碼與確認密碼必須相符

「於 2017/04/28 結束答題」

[wildwindjen]

@HoHow 驗證 email 的什麼，要更明確。

驗證 email 是否存在
驗證 email 格式是否正確

[alxtz]

「於 2017/06/02 開始答題」

a.

https://github.com/alxtz/RegisterAPI

b.

SELECT
INSERT

如果只是要清空table的資料，但留下column的話
DELETE

c.

由另一支程式提供的介面，讓不同的程式間可以互動。
(在提供API的時候常會附上相關的格式及用法)

Ex. 作業系統提供print()這個API，讓其他程式可以呼叫並改變畫面內容
Ex. 瀏覽器提供DOM的API，讓JavaScript可以呼叫來改變畫面上的元件

後端開出的 API 通常是一個 URL，前端使用 API 的方式是向這個 URL 發送特定格式的 request

d.

HTTP是一種常用在網頁的傳輸規定

定義的內容包含:

• 客戶端與伺服器端如何溝通 (Request , Response)
• Request , Response 應該要是什麼樣的格式 (Status, Header, Body)
• Status, Header, Body的各種訊息代表什麼

e.

1. 為了讓除了使用者以外的人，在任何情況下都沒辦法知道原本的密碼

2. 使用的加密演算法是 Bcrypt

f.

想驗證的功能為

• 是否會阻擋同樣帳號的Email註冊
• 能否驗證Email格式
  Email有一套格式的規範叫做RFC
RFC定義了不少奇怪格式的Email
(可以有空格、引號、Emoji)
不過實務上似乎不會特別用RFC來驗證Email

測試資料

1. [email protected]
   預期 註冊成功
   結果 註冊成功
2. [email protected]
   預期 該email已經有人使用
   結果 該email已經有人使用
3. [email protected]
   預期 註冊成功
   結果 註冊成功
4. alxtz.tw@email,com
   預期 註冊失敗
   結果 註冊失敗
5. [email protected]
   預期 註冊失敗
   結果 註冊失敗
6. alxtz.tw@email
   預期 註冊失敗
   結果 註冊成功

通常要驗證Email還會寄驗證信
不太確定只是驗證格式需要做到什麼程度

參考資料 :
https://hackernoon.com/the-100-correct-way-to-validate-email-addresses-7c4818f24643#.hqm4uqbe9

http://girders.org/blog/2013/01/31/dont-rfc-validate-email-addresses/

*途中跑去讀了HTTP

「於 2017/06/05 結束答題」