美多商城項目(一)

美多商城項目(一)
1.在給用戶受權的時候，用到了一個%，表示的是任何ip均可以鏈接這個數據庫。換句話說，若是你換了電腦，你也是能夠進行鏈接數據庫繼續開發的。

grant all on meiduo_mall.* to 'meiduo'@'%';
1.用戶信息的存儲
用戶表分析

ID
用戶名
密碼
手機號
郵箱
是否管理員is_admin
是否註銷is_delete
想要生成表，須要定義一個模型類。Django裏面不須要定義模型類了。

Django的認證系統已經爲咱們提供了一個用戶模型類，還提供了認證和受權功能。

Django認證機制依賴於session機制，但咱們使用JWT認證機制。

is_staff是否能夠訪問admin站點，至關於以前咱們用的is_admin
is_superuser超級管理員
系統的模型類中，缺乏咱們須要的一些字段，那麼咱們能夠自定義用戶模型類，採用繼承就能夠解決這個問題。在遷移以前，咱們須要在配置文件中設置一下，不然，系統不知道咱們定義了模型類。

AUTH_USER_MODEL = '子應用.模型類'

這裏不是路徑，只是一個格式，注意便可。

AUTH_USER_MODEL = 'users.User'
若是咱們直接使用了系統的模型類，那麼那張用戶表叫作auth_users。

2.設計接口的思路
咱們在接到了工做任務的時候，那麼咱們按照下面的思路來思考。

業務功能：分析子業務（子功能），每一個子業務設計一個API接口

API設計過程：

• 接口的請求方式，如GET 、POST 、PUT等
• 接口的URL路徑定義
• 須要前端傳遞的數據及數據格式（如路徑參數、查詢字符串、請求體表單、JSON等）
• 返回給前端的數據及數據格式
  2.1用戶註冊子業務
  1.獲取短信驗證碼

2.用戶名是否存在

3.手機號是否存在

4.註冊信息的保存

四個子業務，那麼設計四個API接口。

2.1.1獲取短信驗證碼
API: GET /sms_codes/ /

/sms_codes/?P 1[3-9]\d{9}/

參數：
經過url傳遞手機號
響應：
{
"message":"OK"
}
補充功能：

1.短信發送60s間隔限制（同一個手機在60以內只發一個短信驗證碼）

2.redis管道的使用：

能夠向redis管道中添加多個redis命令，而後一次性進行執行（能夠作到只鏈接一次redis，那麼網站的效率會高一點。）

2.1.2 異步發短信
爲何使用：傳統的方式形成用戶長時間的等待

解決：

1.將發送短信的代碼抽取成一個函數

2.在短信發送API接口中建立一個進程調用發送短信函數。

問題：

1.若是客戶端請求較多，就會形成服務器壓力過大。

咱們可使用稍後介紹的celery

2.1.3Celery異步任務隊列
本質：經過提早建立的進程調用函數來實現異步的任務。

建立的進程能夠在不一樣的服務器上。

概念：

1.任務執行者( worker)：提早建立的進程

2.任務發出者：發出任務信息，讓執行者去調用某個函數( 任務函數)

3.中間人( broker)：存聽任務消息。

特色：

1.任務執行者的進程能夠單獨在其餘電腦上進行建立。

2.中間人又叫作任務隊列，先添加到隊列中的任務消息會先被worker所執行。

3.生產者-消費者模型。

注意：中間人能夠是rabbit-mq，也能夠是redis，咱們使用redis。

使用：

1.安裝

pip install celery
2.建立一個Celery類的對象並進行配置,是爲了配置中間人的地址。

main.py

from celery import Celery

建立Celery類的對象

celery_app = Celery('demo')

加載配置

celery_app.config_from_object('配置文件的包路徑')

config.py

設置中間人地址borker

broker_url = 'redis:// : / '

broker_url = 'redis://127.0.0.1:6379/3'
3.封裝任務函數

@celery_app.task(name='send_sms_code')
def send_sms_code(a,b):
# ...
pass
4.啓動celery的worker( 建立工做的進程)

celery -A 'celery_app對象所在文件包路徑' worker -l <日誌級別>
日誌級別：critial fatal、error、warn、info、debug

5.發出任務消息

send_sms_code.delay()
2.2用戶名是否存在
獲取用戶名的數量。

API:GET /usernames/(?P \w{5,20})/count/
參數：
經過url地址傳遞用戶名
響應：
{
"username":"用戶名",
"count":"數量"
}
2.3手機號是否存在
獲取手機號的數量。

API: GET /mobiles/(?P 1[3-9]\d{9})/count/
參數:
經過url地址傳遞手機號
響應:
{
"mobile": "手機號",
"count": "數量"
}
3.經過域名訪問網站
靜態文件服務器：127.0.0.1:8080 ---> www.ethanyan.site:8080

後端API服務器：127.0.0.1:8000 -----> api.ethanyan.site:8000

域名對應IP

經過域名訪問網站 --->DNS解析( 根據域名獲取對應的ip)--->再訪問ip對應的服務器。

經過域名訪問網站 --->先到本地 /etc/host文件中查找域名和ip對應關係，若是找到，直接根據ip訪問對應的服務器，再也不進行DNS解析，若是找不到，纔會進行DNS解析過程。

注意：若是想經過一個域名訪問到Django網站服務器，須要將域名添加到 ALLOWED_HOSTS中。

4.一些小的知識點
1.日誌的記錄等級，常見四種大小關係是：

DEBUG < INFO < WARNING < ERROR
只有記錄級別大於或者等於該級別的信息纔會輸出。

5.跨域地址
同源地址：對於兩個url地址，若是協議，ip和端口徹底一致，這樣的地址就是同源地址，不然就不是同源地址。

跨域請求：客戶端發出請求時，若是源請求地址和被請求地址不是同源，這個請求就是跨域請求。

源請求地址： http://www.ethanyan.site:8080/

被請求地址： http://api.ethanyan.site:8000/

瀏覽器在發起ajax跨域請求時，會有CORS跨域請求的限制

在發起跨域請求時，在請求中攜帶一個請求頭：

Origin:源請求地址

被請求的服務器在返回響應時，若是容許源地址對其進行跨域請求，須要在響應時攜帶一個響應頭：

Access-Control-Allow-Origin:源請求地址

瀏覽器若是發現被請求的服務器在返回響應時，沒有攜帶 Access-Control-Allow-Origin:源請求地址響應頭，瀏覽器會直接將請求駁回，而後進行報錯。

...

CSRF跨站請求是否是跨域請求？

答：是跨域請求。

總結
1.Django認證系統用戶模型類

class User(AbstractUser):
mobile = models.CharField(max_length=11,verbose_name='手機號')
....
AUTHUSERMODEL = 'users.User'

2.接口設計思路

分析子業務，每一個子業務實現一個API接口

a.請求方式和URL地址

b.接口所需的參數和格式

c.接口的響應數據和格式

3.短信驗證碼獲取

基本業務邏輯

a.隨機生成6位數字做爲短信驗證碼

b.在redis中存儲短信驗證碼內容，以 sms_ 爲key，以驗證碼內容爲value

c.使用雲通信給手機號發送短信

d.返回應答，短信發送成功

補充兩個功能：

a.短信發送60s間隔限制

b.redis管道的使用

4.本地域名設置

/etc/hosts
5.跨域請求

同源地址：協議，ip，port徹底一致

跨域請求：瀏覽器發請求時，若是源地址和被請求地址不是同源，這個請求就是跨域。

瀏覽器針對Ajax跨域請求，有CORS跨域請求的限制。

6.celery異步任務隊列

使用celery異步發送短信驗證碼，解決用戶點擊獲取短信驗證碼以後，長時間等待。

7.用戶名和手機號是否存在

獲取用戶名數量 1.根據用戶名查詢數據庫，獲取查詢結果數量 2.返回用戶名數量