[データベース| MySQL]フロントエンドおよびバックエンド認証

1つ：Web開発モデル

1：サーバー側レンダリングに基づくWeb開発モデル

サーバー側レンダリングの概念：サーバーからクライアントに送信されるHTMLページは、文字列のスプライシングを通じてサーバーによって動的に生成されます。したがって、クライアントは追加のページデータを要求するためにAjaxなどのテクノロジーを使用する必要はありません。

利点：
①フロントエンドの消費時間が短縮されます。サーバーはHTMLコンテンツの動的な生成を担当するため、ブラウザーはページを直接レンダリングするだけで済みます。特に携帯端末、より省電力。

②SEOに貢献します。サーバーは完全なHTMLページのコンテンツに応答するため、クローラーはクロールして情報を取得しやすくなり、SEOに役立ちます。

短所：
①サーバー側のリソースを占有します。つまり、サーバー側でHTMLページコンテンツのスプライシングが完了します。リクエストが多いと、サーバーに一定のアクセス圧力がかかります。

②フロントエンドとリアエンドの分離が悪く、現像効率が悪い。サーバー側のレンダリングを使用する場合、特にフロントエンドの複雑さが高く、効率的なプロジェクト開発に役立たないプロジェクトでは、分業を実行できません。

2：フロントエンドとバックエンドを分離したWeb開発モデル

フロントエンドとバックエンドの分離の概念：フロントエンドとバックエンドの分離の開発モデルは、Ajaxテクノロジーの幅広いアプリケーションに依存しています。つまり、フロントエンドとバックエンドが分離されたWeb開発モデルは、バックエンドがAPIインターフェイスの提供のみを担当し、フロントエンドがAjaxを使用してインターフェイスを呼び出す開発モデルです。

利点：
①優れた開発経験。フロントエンドはUIページの開発に重点を置いており、バックエンドはAPIの開発に重点を置いており、フロントエンドにはより多くのオプションがあります。

②優れたユーザーエクスペリエンス。Ajaxテクノロジーの幅広いアプリケーションにより、ユーザーエクスペリエンスが大幅に向上し、ページの部分的な更新を簡単に実現できます。

③サーバー側のレンダリング圧力を下げます。ページは最終的に各ユーザーのブラウザで生成されるためです。

短所：
①SEOを助長しません。完全なHTMLページをクライアント上で動的にスプライスする必要があるため、クローラーはページの有効な情報をクロールできません。

（解決策：VueやReactなどのフロントエンドフレームワークを使用したSSR（サーバー側レンダリング）テクノロジーは、SEOの問題を非常にうまく解決できます！）

3：Web開発モデルの選び方

• たとえば、複雑な操作なしで表示することを主な機能とし、優れたSEOを必要とするエンタープライズレベルのWebサイトの場合、現時点ではサーバー側のレンダリングを使用する必要があります。
• また、バックエンド管理プロジェクトと同様に、相互作用は比較的強く、SEOを考慮する必要がないため、フロントエンドとバックエンドを分離する開発モデルを使用できます。
• また、使用する特定の開発モードは絶対的なものではなく、ホームページのレンダリング速度とフロントエンド分離の開発効率の両方を考慮するために、一部のWebサイトはファーストスクリーンサーバーサイドレンダリングの開発モデルを採用しています+他のページのフロントエンド分離。

2：ID認証

認証（Authentication）は、「ID検証」および「認証」とも呼ばれ、特定の手段によるユーザーのIDの確認を指します。

• 高速鉄道のチケット検査、携帯電話のパスワードまたは指紋のロック解除、AlipayまたはWeChatの支払いパスワードなど、日常生活でのID認証はどこでも見られます。
• Web開発では、主要なWebサイトの携帯電話検証コードログイン、メールボックスパスワードログイン、QRコードログインなどのユーザーID認証も含まれます。

2：さまざまな開発モードでのID認証

サーバー側レンダリングとフロントエンド分離の2つの開発モードには、それぞれ異なる認証スキームがあり
ます
。①サーバー側レンダリングにはセッション認証メカニズムが推奨されます②フロントエンドとバックエンド分離にはJWT認証メカニズムが推奨されます

3：HTTPプロトコルのステートレス

HTTPプロトコルのステートレス性は、クライアントの各HTTP要求が独立しており、複数の連続する要求間に直接の関係がなく、サーバーが各HTTP要求のステータスをアクティブに保持しないことを意味します。

4：HTTPステートレスの限界を打破する方法

スーパーマーケットの場合、レジ係が決済中にVIPユーザーを割引できるようにするために、スーパーマーケットは各VIPユーザーに会員カードを発行できます。

実際の会員カード認証方法、Web開発の専門用語はCookieと呼ばれます

4.1：クッキーとは

コンソール：アプリケーション-> Cookie（キー値で構成）

Cookieは、ユーザーのブラウザに保存される4KB以下の文字列です。これは、名前（Name）、値（Value）、およびCookieの有効期間、セキュリティ、およびスコープを制御するために使用されるその他のいくつかのオプションの属性で構成されます。

異なるドメイン名のCookieは独立しています。クライアントがリクエストを開始すると、現在のドメイン名の有効期限が切れていないすべてのCookieがサーバーに自動的に送信されます。

Cookieの主な特徴：
①自動送信
②独立ドメイン名
③有効期限
④4KB制限

4.2：ID認証におけるCookieの役割

クライアントが初めてサーバーを要求すると、サーバーはID認証Cookieを応答ヘッダーの形式でクライアントに送信し、クライアントはそのCookieをブラウザーに自動的に保存します。

その後、クライアントブラウザがサーバーを要求するたびに、ブラウザはID認証に関連するCookieを要求ヘッダーの形式でサーバーに自動的に送信し、サーバーはクライアントのIDを確認できます。

4.3：クッキーは安全ではありません

Cookieはブラウザに保存され、ブラウザはCookieの読み取りと書き込みのためのAPIも提供するため、Cookieは簡単に偽造され、安全ではありません。したがって、サーバーが重要なプライバシーデータをCookieの形式でブラウザに送信することはお勧めしません。

重要なプライベートセキュリティの問題を保存するためにCookieを使用しないでください

5：セッション認証メカニズム

5.1：ID認証のセキュリティを向上させる

レジ係は、顧客が会員カードを偽造することを防ぐために、顧客から提示された会員カードを受け取った後、レジでカード認証を行うことができます。通常はレジで確認した会員証のみご利用いただけます。

メンバーシップカード+クレジットカード認証の設計コンセプトは、セッション認証メカニズムの本質です。

5.2：

1. 
   Express -SessionミドルウェアのインストールExpressプロジェクトでは、プロジェクトでSession認証を使用するためにExpress-Sessionミドルウェアをインストールするだけで済みます。

npm install express-session

2. エクスプレスセッションミドルウェアの構成エクスプレス
   セッションミドルウェアが正常にインストールされたら、app.use（）を使用してセッションミドルウェアを登録する必要があります。

//导入session中间件
const session=require('express-session')

//配置中间件
app.use(session({
    
    
	secret:'keyboard cat',//属性值可以为任意字符
	resave:false,//固定写法
	saveUninitialized:true //固定写法
	}))

3. セッションへのデータの保存
   エクスプレスセッションミドルウェアが正常に構成されたら、req.sessionを介してセッションオブジェクトにアクセスして使用し、ユーザーの重要な情報を保存できます。

app.post('/api/login',(req,res)=>{
    
    
	//判断用户提交的登录信息是否正确
	if(req.body.username !=='admin' || req.body.password !=='000000'){
    
    
		return res.send({
    
    status:1,msg:'登陆失败'})
	}
	req.session.user=req.body //将用户的信息存储在session中
	req.session.isogin=true //将用户登录状态，存储在session中

	res.send({
    
    status:0,msg:'登陆成功'})
})

4. セッションからデータを
   取得する以前に保存したデータをreq.sessionオブジェクトから直接取得できます。

app.get('/api/username',(req,res)=>{
    
    
	//判断用户是否登录
	if(!req.session.islogin){
    
    
		return res.send({
    
    status:1,msg:'登陆失败'})
	}
	res.send({
    
    status:0,msg:'登陆成功',username:req.session.user.username})
	

5. セッションをクリアするに
   は、req.session.destroy（）関数を呼び出して、サーバーによって保存されたセッション情報をクリアします。

app.post('/api/logout',(req,res)=>{
    
    
	//清空当前客户端对应的session
	req.session.destroy()
	res.send({
    
    
		status:0,
		msg:'退出登录成功'
		})
	})

6：JWT認証メカニズム

6.1：セッション認証の制限を理解する

セッション認証メカニズムを実現するには、Cookieと連携する必要があります。Cookieはデフォルトでクロスドメインアクセスをサポートしていないため、バックエンドインターフェイスへのフロントエンドクロスドメインリクエストに関しては、クロスドメインセッション認証を実現するために多くの追加構成が必要です。

注意：

• フロントエンド要求のバックエンドインターフェイスにクロスドメインの問題がない場合は、セッション認証メカニズムを使用することをお勧めします。
• フロントエンドがドメイン間でバックエンドインターフェイスを要求する必要がある場合、セッション認証メカニズムを使用することはお勧めしません。また、JWT認証メカニズムを使用することをお勧めします。

6.2：JWTとは

JWT（英語名：JSON Web Token）は、現在最も人気のあるクロスドメイン認証ソリューションです。

トークン：
Cookieデータ、クロスドメインの場合、
セッションは自動的に実行されず、サーバー側のリソースを占有します。クロスドメインはサポートされていません

概要：ユーザーの情報は、トークン文字列の形式でクライアントブラウザに保存されます。サーバーは、トークン文字列を復元することにより、ユーザーのIDを認証します。

6.3：JWTのコンポーネント

JWTは通常、ヘッダー（ヘッダー）、ペイロード（ペイロード）、署名（署名）の3つの部分で構成されます。

英語の「。」を使用して3つを区切ります。

ペイロード部分は実際のユーザー情報であり、ユーザー情報が暗号化された後に生成される文字列です。

ヘッダーと署名は、トークンのセキュリティを確保するためだけに、セキュリティ関連の部分です。

header.Payload.Signature

6.4：JWTの使用

クライアントは、サーバーから返されたJWTを受信すると、通常、それをlocalStorageまたはsessionStorageに保存します。

その後、クライアントがサーバーと通信するたびに、ID認証のためにこのJWT文字列を取得する必要があります。推奨されるアプローチは、HTTPリクエストヘッダーのAuthorizationフィールドにJWTを配置することです。

//请求头的Authorization
Authorization:Bearer <token>

1. JWT関連パッケージの
   インストール次のコマンドを実行して、次の2つのJWT関連パッケージをインストールします。

npm install jsonwebtoken express-jwt

jsonwebtokenはJWT文字列を生成するために使用されます

express-jwtは、JWT文字列をJSONオブジェクトに解析するために使用されます

2. JWT関連パッケージのインポート
   require（）関数を使用して、2つのJWT関連パッケージをインポートします。

//导入用于生成JWT字符串的包
const jwt = require( ' jsonwebtoken ')
//导入用于将客户端发送过来的JWT字符串，解析还原成JSON对象的包
const expressJWT = require('express-jwt ')

3. 秘密鍵の定義
   JWT文字列のセキュリティを確保し、ネットワーク送信中にJWT文字列が他のユーザーによってクラックされるのを防ぐために、暗号化と復号化のための秘密鍵を具体的に定義
   する必要があります。①JWT文字列を生成する場合、秘密鍵を使用してユーザーの情報を暗号化し、最終的に暗号化されたJWT文字列を取得
   する②JWT文字列を解析してJSONオブジェクトに復元する場合、復号化に秘密鍵を使用する必要があります

//secret密钥的本质:就是一个字符串
const secretKey = 'hello'

4. ログインに成功した後、JWT文字列を生成します
   。jsonwebtokenパッケージで提供されるsign（）メソッドを呼び出して、ユーザーの情報をJWT文字列に暗号化し、クライアントに応答します。

//登录接口
app.post( " lapi/login' , function( req, res){
    
    
//...省略登录失败情况下的代码
//用户登录成功之后，生成JMT字符串，通过token属性响应给客户端
res.send({
    
    
	status: 200,
	message: '登录成功! '，
	//调用jwt , sign()生成JWT字符串，三个参数分别是:用户信息对象、加密密钥、配置对象
	token: jwt.sign({
    
     username: userinfo.username }， secretKey，{
    
     expiresIn: '30s' })10}
 })

5. JWT文字列をJSONオブジェクトに復元します
   。クライアントがこれらの承認されたインターフェースにアクセスするたびに、リクエストヘッダーの承認フィールドを介してID認証のためにトークン文字列をサーバーにアクティブに送信する必要があります。
   この時点で、サーバーは、クライアントから送信されたトークンを自動的に解析して、express-jwtミドルウェアを介してJSONオブジェクトに復元できます。

//使用app.use(）来注册中间件
//expressJMT({ secret: secretKey })就是用来解析Token的中间件
//.unless({ path: [ /A\/api\//]})用来指定哪些接口不需要访问权限
app.use(expressJwT({
    
     secret: secretKey }).unless({
    
     path: [ /A\/api\//] }))

6. req.userを使用してユーザー情報を取得します
   。express-jwtミドルウェアが正常に構成されたら、これらの承認されたインターフェースでreq.userオブジェクトを使用して、JWT文字列から解析されたユーザー情報にアクセスできます。サンプルコードは次のとおりです。

//这是一个有权限的API接口
app·get( ' l admin/getinfo', function(req, res){
    
    
	console.log(req.user)
	res.send({
    
    
		status: 200，
		message: "获取用户信息成功! '，
		data: req.user
	})
})

7. JWTの解析に失敗した後に生成されたエラーをキャプチャする
   express-jwtを使用してトークン文字列を解析するときに、クライアントから送信されたトークン文字列が古くなっているか不正である場合、解析失敗エラーが生成され、通常に影響します。プロジェクトの運用。このエラーをキャッチし、Expressのエラーミドルウェアを介して処理できます。サンプルコードは次のとおりです。

app.use((err, req,res，next) =>{
    
    
	//token 解析失败导致的错误
	if(err.name === 'UnauthorizedError '){
    
    
		return res.send({
    
     
			status: 401，message: '无效的token'
			 })
		}
		//其它原因导致的错误
	res.send({
    
     status: 500，message: '未知错误·})
}

数日で追加します...