使用者認證章節真夠長的，不過涉及到的內容確實多，繼續上一章節

這部分講到的是新使用者註冊以後，需要在郵箱裡麵點擊連結進行確認，這個在我們平時網站註冊新使用者的時候，經常會碰到

確認郵件中最簡單的確認連結是http://www.example.com/auth/confirm/<id> 這種形式的URL，其中id 是資料庫分配給使用者的數字id。使用者點選連結後，處理這個路由的檢視函
數就將收到的使用者id 作為引數進行確認，然後將使用者狀態更新為已確認。但這種實現方式顯然不是很安全，只要使用者能判斷確認連結的格式，就可以隨便指定URL中的數字，從而確認任意賬戶。解決方法是把URL 中的id 換成將相同資訊保安加密後得到的令牌。

(venv) $ python manage.py shell
>>> from manage import app
>>> from itsdangerous import TimedJSONWebSignatureSerializer as Serializer

>>> s = Serializer(app.config['SECRET_KEY'], expires_in = 3600)                #expires_in表示這個祕鑰令牌的有限時間是多久，秒為單位
>>> token = s.dumps

({ 'confirm': 23 })                                                                   #dumps表示將{'confirm':23}轉化成安全令牌
>>> token
'eyJhbGciOiJIUzI1NiIsImV4cCI6MTM4MTcxODU1OCwiaWF0IjoxMzgxNzE0OTU4fQ.ey ...'
>>> data = s.loads(token)                                                                                       #loads則表示解析這個令牌，等於反向解碼

>>> data 
{u'confirm': 23}

接著，有了這個驗證的東西，我們起碼要為我們的模型新增這樣一個屬性

class User(UserMixin,db.Model):
__tablename__='users'
id=db.Column(db.Integer,primary_key=True)
email=db.Column(db.String(64),unique=True,index=True)
username=db.Column(db.String(64),unique=True,index=True)
role_id = db.Column(db.Integer, db.ForeignKey('roles.id'))
password_hash=db.Column(db.String(128))
confirmed = db.Column(db.Boolean,default=False)             #預設屬性是False，也就是未認證

def generate_confirmation_token(self,expiration=3600):
s=Serializer(current_app.config['SECRET_KEY'],expiration)    #這句的作用不是很明白，為什麼要匯入祕鑰，是不是使用這個功能必須要通過祕鑰？
return s.dumps({'confirm':self.id})

def confirm(self,token):
s=Serializer(current_app.config['SECRET_KEY'])
try:
data=s.loads(token)      #嘗試賦值給data......始終沒明白什麼情況下賦值會失敗？token沒有內容？？？
except:
return False
if data.get('confirm') !=self.id:  #如果資料內confirm對應的confirm值不是使用者的唯一id號，則返回False
return False
self.confirmed = True       
db.session.add(self)              
return True

由於更新過資料庫了，所以，需要新建一個指令碼，並更新資料庫

既然有了需要確認的這個新屬性，那在註冊之後，一般網站都會自動向你的郵箱發一份確認郵件，那這個功能就要新增在路由裡面了

from ..email import send_email

@auth.route('/register',methods=['GET','POST'])
def register():
form=RegistrationForm()
if form.validate_on_submit():
user=User(email=form.email.data,username=form.username.data,password=form.password.data)
db.session.add(user)           #這裡就要把user新增進資料庫了，因為只有這樣，才能有唯一的id生成
db.session.commit()            
token = user.generate_confirmation_token()
send_email(user.email,'Confirm Your Account','auth/email/confirm',user=user,token=token)
flash('A Confirmation email has been sent to you by email.')
return redirect(url_for('main.index'))
return render_template('auth/register.html',form=form)

之後，需要做的是，編輯郵件的內容，也就是你收到的郵件內容 auth/mail/confirm.html

<p>Dear {{ user.username }},</p>
<p>Welcome to <b>Flasky</b>!</p>
<p>To confirm your account please <a href="{{ url_for('auth.confirm', token=token, _external=True) }}">click here</a>.</p>  #這裡生成的是超連結按鈕
<p>Alternatively, you can paste the following link in your browser's address bar:</p>
<p>{{ url_for('auth.confirm', token=token, _external=True) }}</p>            #一般來說url_for生成的是相對路徑，有了_external=True以後，就可以生成包括http的全部路徑了
<p>Sincerely,</p>                    #然後上一行，通過<p>來將整段驗證程式碼顯示出來，和平時我們註冊網站時收到的郵件一模一樣
<p>The Flasky Team</p>
<p><small>Note: replies to this email address are not monitored.</small></p>

郵件內容也編輯好了，我們再來看一下，如果我們點選了確認連線，返回的頁面應該是什麼樣的

由於每個使用者的id不一樣，所以說，生成的token不一樣，故這裡的連線肯定是動態地址的

我們來編輯auth/views.py

@auth.route('/confirm/<token>')
@login_required                  #保護路由，要求你必須是在登陸狀態才能訪問這個頁面
def confirm(token):
if current_user.confirmed:         #如果使用者的狀態已經是confirmed的了，那直接範圍首頁了
return redirect(url_for('main.index'))
if current_user.confirm:              #如果使用者通過這個頁面的訪問，呼叫confirm函式並返回True了，那成功驗證
flash('You have confirmed your account. Thanks!')
else:                                               #其他情況下，驗證失敗，並返回主頁
flash('The confirmation link is invalid or has expired.')
return redirect(url_for('main.index'))

如我們平時訪問的一些網站一樣，當你還是個新手上路狀態的賬號時，你可能只能訪問一些特定的區域，也做不了任何事。

這裡就要用到前面章節說的鉤子了，說實話，我還不是很理解鉤子的原理，感覺需要去看上下文的原始碼，不過先這麼用起來吧。

對藍本來說，before_request 鉤子只能應用到屬於藍本的請求上。若想在藍本中使用針對程式全域性請求的鉤子，必須使用before_app_request 修飾器。

@auth.before_app_request                          #這句的意思，字面上理解是，在app的request響應之前，先如何如何............
def before_request():
if current_user.is_authenticated \         #如果使用者是認證過的
and not current_user.confirmed \         #但是confirmed屬性是False的
and request.endpoint[:5] !='auth.'and request.endpoint !='static':     #而且，request的網址不是以auth.和static開頭的
return redirect(url_for('auth.unconfirmed'))                                    #就返回到未確認的一個路由

@auth.route('/unconfirmed')
def unconfirmed():
if current_user.is_anonymous or current_user.confirmed:             #如果使用者是非普通使用者(is_anonymous對普通使用者返回False)，或者已確認的，則返回主頁
return redirect(url_for('main.index'))
return render_template('auth/unconfirmed.html')             #不然，則進入未確認頁面

同時滿足以下3 個條件時，before_app_request 處理程式會攔截請求。
(1) 使用者已登入（current_user.is_authenticated() 必須返回True）。
(2) 使用者的賬戶還未確認。
(3) 請求的端點（使用request.endpoint 獲取）不在認證藍本中。訪問認證路由要獲取權
限，因為這些路由的作用是讓使用者確認賬戶或執行其他賬戶管理操作。

再來看一下未確認的頁面unconfirmed.html如何渲染

{% extends "base.html" %}
{% import "bootstrap/wtf.html" as wtf %}
{% block title %}Flasky - Login{% endblock %}
{% block page_content %}
<div class="page-header">
<h1>You have not confirmed your account yet.</h1>
</div>
<p>
Before you can access this site you need to confirm your account . Check your inbox , you should have received an email with a confirmation link.
</p>
Need another confirmation email? 
<a href = "{{url_for('auth.resend_confirmation',token=token, _external=True)}}">Click here to send again</a>    #注意這裡的寫法，很容易寫錯的
{% endblock %}

效果如圖

有時候，如果你的驗證令牌已經過期了，那我們需要重新發送一份郵件來確認，那怎麼辦呢？

再做一個路由......來重新發送郵件

@auth.route('/confirm')
@login_required
def resend_confirmation():
token = current_user.generate_confirmation_token()
send_email(current_user.email, 'Confirm Your Account','auth/email/confirm', user=current_user, token=token)
flash('A new confirmation email has been sent to you by email')
return redirect(url_for('main.index'))

收到的Email效果如下，還挺有那麼回事

確認完的郵件是這樣的，不過頁面內容還寫的是未完成確認，不過應該不是大問題，渲染檔案裡面加個if語句應該就可以，後面再改吧，先這樣。

這篇章終於快要結束了，還有最後一點管理使用者，另外篇幅講......

這認證使用者一章節內容實在是太飽滿了.....................................