從壹開始 [ Ids4實戰 ] 之四 ║ 用戶數據管理 & 先後端受權聯調

時間 2019-11-05

原文原文鏈接

前言

哈嘍~~~ 你們週一好！夏天到了，你們舒服了沒有，熟話說，戰勝你的不是天真，是天真熱！😂html

過去的一週裏，發生了兩件事跟你們分享下：前端

①、有兩個小夥伴給我提供了 Working Online 的工做，簡單說了說，感受應該不太適合，至少我不適合，前期雙方試探的成分太多了，我是不喜歡，同時也建議正在找OnLine工做的小夥伴需多多考慮可行性。vue

②、我決定開始《微講堂》了，具體能夠參考右側公告欄，由於有些基礎比較薄弱的小夥伴，單單提供思路仍是沒法入門，因此提供在線手把手教學吧，這個我是徹底無所謂，看你心情吧。git

這幾天經過晚上對 IdentityServer4 的學習和研究，發現這個就是一個「大坑」（不是說功能很差，是裏邊有不少不少的內容須要學習，暫時把開發的 Demo 開放出來了，很簡單的，隨便看看，以前看官網，關於 IdentityServer4 的教程，洋洋灑灑就過去了，感受還挺簡單，發現要真是落地到項目裏了，自我感受又有了壓迫感，文末結語中，我簡單的說了幾點問題，你們能夠慢慢往下走，不過知識嘛，無外乎就是本身開心學習和本身學習掙錢，這兩個心理，加油吧。github

固然平時工做之餘，仍是要照顧下先後端分離項目的一些東西的，基礎不能丟，主要是三塊地方作了修改，這裏簡單的列一下，就不單獨的寫文章了，但願一直在看第一個項目的小夥伴，有緣能夠看到吧，不過，就算是看不到也沒事兒，遇到了天然就知道了：數據庫

一、Blog.Vue 首頁的閃屏處理；// 知名博主@張飛洪提出的問題，不知道我是否修改對了；http://vueblog.neters.club/npm

二、Blog.Admin 後臺框架調整優化；// ①登陸頁樣式改版，②Tabs 導航條優化，③兼容手機屏幕等；http://vueadmin.neters.club/後端

三、Blog.Core 後端項目增長 Wiki 頁；// 爲了讓剛接觸框架的小夥伴能快速一覽，特意在 Github 上，建立了 Wiki ，只不過如今纔打了個目錄，內容慢慢填，若是還有其餘的不足之處，歡迎提建議；https://github.com/anjoy8/Blog.Core/wikiapi

忽然轉話題，上次我們第一次對項目進行持久化操做《三║ 詳解受權持久化 & 用戶數據遷移》，不知道小夥伴都看了多少，這裏再把幾個重要問題提一下，但願不要忘記了纔好：瀏覽器

1、Ids4 一共用到了幾個上下文，分別的用處是什麼？

2、在遷移中，數據庫生成了多少表，各個模塊又是幹什麼的？

3、Ids4 的良好擴展性，體如今哪裏？豐富性又體如今哪裏？

4、ApplicationUser 類是起到什麼做用的？

若是腦子裏有些東西，那就恭喜了，若是第一次看，或者徹底不知道我在說什麼的話，請看上一集，今天會說說我在研究的過程當中，遇到的兩個 Flag 🚩，也就是兩個問題，但願有心的小夥伴，能夠幫忙思考下，歡迎找我討論，廢話很少說，開車，立刻講解今天的內容！🛴🚄

零、今天要實現綠色的部分

（知識結構圖，注意這是我本身的講解結構，和Ids4知識圖解無關）

1、用戶數據處理 —— Identity

我們在上篇文章中，簡單的將 IdentityServer4 的結構進行持久化處理，並把先後端項目中的用戶數據進行遷移處理，最後修改了登陸頁的樣式，基本知足了登陸和登出的操做，做爲一個受權服務中心，僅僅只有登陸是徹底解決不了什麼問題的，至少應該對用戶數據進行常規操做處理，好比 CURD 等基礎操做。

正好，咱們使用了 NetCore 自帶的 Identity 機制，能夠幫助咱們作一部分工做，由於它本身也封裝了一些方法，咱們能夠根據他們的方法，實當的作些擴展，從而達到相應的目的，具體有哪些操做，請往下看：

一、用戶數據展現（有權限）

既然有數據處理，確定得有展現出來，固然，這個不是必定的，只是作下處理，若是你擔憂會有數據安全問題的話，要麼不顯示數據，要麼只顯示無關痛癢的兩列，甚至能夠直接加上權限，只有超級管理員或者技術人員能夠看到就行。我這裏僅僅是加了個登陸權限，只有登陸的用戶才能看的到：

// 注入用戶管理
private readonly UserManager<ApplicationUser> _userManager;


 [HttpGet]
 [Route("account/users")]
 [Authorize]//能夠自定義規則 public IActionResult Users(string returnUrl = null)
 {
     ViewData["ReturnUrl"] = returnUrl;
     var users = _userManager.Users.Where(d => !d.tdIsDelete).OrderBy(d => d.UserName).ToList();//Identity 已經對內部的一些方法作了封裝，直接使用便可，若是你對 Net 自帶的 Identity 使用過的話，應該很容易上手。

     return View(users);
 }

注意下上邊的紅色標註的地方，下文會說到爲啥這裏用到了 isDelete 。

咱們簡單的對 User 頁面作了受權處理，必須登陸狀態下才能有權訪問，若是是沒有登陸，會直接跳轉到登陸頁面：

（帶權限的用戶展現頁）

二、註冊

關於註冊其實咱們以前已經說過了，爲何呢，由於咱們在以前導入用戶數據的時候，就已經用到了這個方法，只不過這裏單拎出來了，可是這裏有一個問題須要咱們好好的思考思考，那就是角色的獲取！這裏就是我下邊要說的第一個「Flag」🚩，爲何重要呢，不知道如今讀的你是否使用過 IdentityServer4 ，我也這幾天在考慮這個問題，受權中心確定須要有用戶管理的，那很天然的，就會出現「區分控制」的問題，這裏簡單說下會出現的兩個狀況：

一、前臺展現項目：若是咱們的vue 項目，是一個前臺網站，好比電商類的或者 Blog.Vue 這樣的，很簡單，咱們只須要在 api 上加上 [Authorize] 這個無具體規則的受權特性就行，你們先不要往下看，先停一分鐘想想是否是這個狀況。商城嘛，只須要用戶登陸一下就能夠購買了，咱們不須要特意的區分商城用戶有什麼區別，有什麼三六九等，你們都是同樣，登陸了，就能夠任何操做，不管是買東西，仍是寫文章，亦或者投票等等；

二、後臺管理項目：可是！還有另外一種狀況，那就是後臺管理，一個對用戶身份要求特別嚴格的一個系統，咱們確定不能僅僅在 api 接口地址上，加上 [Authorize] 這個簡單的特性就完事兒了，就好比咱們的 Blog.Admin 項目，確定須要一套複雜的受權策略機制，那就不得不用到用戶的角色信息，或者其餘的模塊信息，這就是我上邊說的「區分控制」；（至因而基於角色的策略，仍是模塊化，我還在考慮中，目前先嚐試角色管理）

三、猜測：你是否是想說使用基於角色+策略受權的 Hybrid Flow 混合模式？彆着急，之後的問題會說到，這裏提出這個問題，就是向給你們一個思路的過程。

若是是第二種狀況的話，咱們在用戶註冊的時候，就須要帶上「角色」這個信息，好比我這裏先默認是一個 test 系統測試管理員的角色（這個暫時這麼處理，後期我會再深刻研究下，是否是這個模式，或者若是正再看的你很懂的話，歡迎指導下，不勝感激！），固然，若是你的項目不須要對用戶的權限進行劃分，就好比我上邊的第一種狀況，電商類，博客類，只要不是後臺管理這種的前臺系統，都很簡單，只須要在 api 上加上 [Authorize] ，而後受權中心是不須要角色這個概念的。

咱們學術討論嘛，固然是從複雜的着手，就把角色給考慮進去了，如今先寫死一個角色，咱們之後的文章中會進一步討論這個複雜的狀況：

 [HttpPost]
 [Route("account/register")]
 [ValidateAntiForgeryToken]
 public async Task<IActionResult> Register(RegisterViewModel model, string returnUrl = null, string rName = "AdminTest")
        {
            ViewData["ReturnUrl"] = returnUrl;
            IdentityResult result = new IdentityResult();
            // 模型校驗
            if (ModelState.IsValid)
            {
                // 判斷用戶名是否存在，說明：若是是DDD設計思想，這中查重應該是寫在領域模型的。
                var userItem = _userManager.FindByNameAsync(model.LoginName).Result;
                if (userItem == null)
                {
                    // 轉成咱們的實體模型，說明：這種多個實體轉換，可使用 Dto
                    var user = new ApplicationUser
                    {
                        Email = model.Email,
                        UserName = model.LoginName,
                        LoginName = model.RealName,
                        sex = model.Sex,
                        age = model.Birth.Year - DateTime.Now.Year,
                        birth = model.Birth,
                        addr = "",
                        tdIsDelete = false
                    };
                    // 建立用戶，注意密碼的規範，好比必須有大小寫字母+數字+符號
                    result = await _userManager.CreateAsync(user, model.Password);
                    if (result.Succeeded)
                    {
                        // 用戶添加成功後，就須要添加聲明瞭，看本身須要多少吧，能夠自定義擴展
                        result = await _userManager.AddClaimsAsync(user, new Claim[]{
                            // 這個 Name ，就是 Jwt 的惟一名字，也是頁面裏展現的名稱，好比是「測試帳號」，而不是登陸名的「test1」
                            new Claim(JwtClaimTypes.Name, model.RealName),
                            new Claim(JwtClaimTypes.Email, model.Email),
                            // 是否須要進行 Email 郵件驗證
                            new Claim(JwtClaimTypes.EmailVerified, "false", ClaimValueTypes.Boolean),
                            // 這裏就是角色聲明
                            new Claim(JwtClaimTypes.Role, rName)
                        });
                        if (result.Succeeded)
                        {
                            // 添加成功，能夠直接登陸，這個就好比是咱們的博客項目或者電商項目，咱們在受權中心註冊成功後，直接登陸了，跳轉到前臺了。
                            //await _signInManager.SignInAsync(user, isPersistent: false);
                            return RedirectToLocal(returnUrl);
                        }
                    }
                }
                else
                {
                    ModelState.AddModelError(string.Empty, $"{userItem?.UserName} already exists");
                }
                // 收集所有異常數據，返回前臺
                AddErrors(result);
            }
            return View(model);
        }

上邊的就是註冊的主要代碼，你們能夠本身任意的擴展，而後重要的部分，我已經標紅，也寫上了詳細的註釋，特別簡單，都能看懂。

這一 Part 都很日常，最重要的一個問題仍是那個角色這一塊，但願讀到這裏的都能看懂，想想到底你的項目裏需不須要這樣的 Claim，不懂的歡迎來討論。

三、更新與邏輯刪除（有權限）

上邊我們說到了展現和添加，那下邊就是說到更新了（這個操做我帶上了最高的權限，必須是超級管理員才能操做 [Authorize(Roles = "SuperAdmin")] ），你會問，爲啥要把刪除和更新放到一塊兒呢？其實我我的感受邏輯是同樣的，平時開發確定也都知道，邏輯刪除其實就是把「是否刪除」這個字段設置成 True 就好了，可是真的是這樣麼，咱們慢慢往下看。

首先更新用戶這個很簡單的，我就很少說什麼了，具體的能夠看看代碼，主要的邏輯就是平時的三步走：

一、查詢出當前人Model；

二、用視圖模型修改Model；

三、執行更新操做 _userManager.UpdateAsync(userItem); // 這裏要說下就是，Identity 自帶了不少擴展方法，你們須要本身好好的研究下，從而達到本身的相應目的。

更新說完了，下邊說說刪除，刪除其實自己就有兩種狀況：

一、邏輯刪除，很天然，就是將數據更新下狀態，好比咱們能夠用上邊的方法，把當前操做人的 IsDeleted=True 便可，很簡單；

二、物理刪除，這個仍是須要好好研究研究，我在官方的代碼裏，沒有找到如何物理刪除的方法，可能仍是須要開發者本身定義擴展吧；

這就是我說的第二個「Flag」🚩 ，須要好好的思考思考，若是你已經忘了第一個 Flag 的話，請向上看，用戶註冊章節裏的角色問題。

（更新 & 刪除有權限動圖）

四、重置密碼

這個是目前爲止稍微複雜一點的，需用用到流程，首先看動圖吧：

（重置/更新密碼動圖）

這個過程其實很簡單，也是項目中必須使用到的功能，我相信任何一個網站，必需要用到這個重置和找回密碼的功能吧，固然生產環境很複雜，可能須要郵箱或者手機等來處理動態連接，我這裏只是提供一個思路，總結來講，流程說明以下：

一、輸入當時註冊郵箱；

二、獲取包含動態 Code 的安全連接（可經過發郵件的形式）；

三、根據安全連接，設置新密碼；

四、從新登陸；

核心代碼（節選）：

// 一、判斷郵箱
var user = await _userManager.FindByEmailAsync(model.Email);

// 二、生成重置密碼回調連接
var code = await _userManager.GeneratePasswordResetTokenAsync(user);
var callbackUrl = Url.ResetPasswordCallbackLink(user.Id, code, Request.Scheme);
var ResetPassword = $"Please reset your password by clicking here: <a href='{callbackUrl}'>link</a>";

// 三、重置密碼
var result = await _userManager.ResetPasswordAsync(user, model.Code, model.Password);

五、其餘狀況處理？

經過上邊的簡單說明，AccountController 這個控制器的內容，我們說完了，是否是就沒有問題了呢，不是！咱們要研究，就要研究透徹，你們確定注意到了這個項目中，基本都說到了，可是在覈心的快速啓動文件夾 Quickstart 中，還有幾個控制器沒有說到：

不光如此，在平時的開發中，咱們還會遇到下邊這幾個業務邏輯操做：

1、如何找回註冊郵箱？

2、如何經過發送郵件，從而達到郵件確認的目的？

3、如何實現FaceBook、Google登陸？

4、如何更新用戶的角色等Claims？

五、如何刷新 Token ?

上邊紅框中的那幾個控制器都是什麼意思？

下邊四條業務邏輯又該如何實現？

當前項目是否是還有其餘不爲咱們知道的祕密？之後的章節再慢慢展開，請關注。

不過咱們既然已經完成用戶的基本操做，咱們就先停下上邊的疑惑問題，往下走走，看看 IdentityServer4 究竟是如何經過 OpenID Connect 來操做的。

2、簡單受權模式 —— Implicit Flow OpenID

0、OpenID Connect受權模式

OPID 認證流程主要是由 OAuth2 的五種受權流程延伸而來的，它有如下 3 種：

Authorization Code Flow（受權碼模式）：基於OAuth2的受權碼來換取Id Token和Access Token。
Implicit Flow（簡化模式）：基於OAuth2的Implicit流程獲取Id Token和Access Token。
Hybrid Flow：混合Authorization Code Flow+Implici Flow獲取Id Token和Access Token。

注：OpenID Connect 爲何沒有基於OAuth2的Resource Owner Password Credentials Grant和Client Credentials Grant擴展，Resource Owner Password Credentials Grant是須要應用提供帳號密碼的，帳號密碼都有了在獲取Id Token意義不大。Client Credentials Grant沒有用戶的參與因此獲取Id Token 也沒意義。這也能反映受權和認證的差別，以及只使用OAuth2來作身份認證的事情是遠遠不夠的，也是不合適的。

一、概念

簡化模式用於獲取訪問令牌（但它不支持令牌的刷新，之因此因此稱爲簡化模式，和受權碼模式比少了獲取受權碼的步驟），並對運行特定重定向URI的公共客戶端進行優化，而這一些列操做一般會使用腳本語言在瀏覽器中完成，令牌對訪問者是可見的，且客戶端也不須要驗證。

簡化模式，主要有下邊三個特色：

一、用於「公共」客戶端；

二、客戶端應用直接從瀏覽器訪問資源；

三、沒有顯式的客戶端身份認證；

二、結構圖

爲了配合你們理解，我這裏有兩個場景，你們腦子裏先有個畫面，而後往下看四個角色和流程圖：

場景一：博客園登陸，須要獲取騰訊的某一個QQ用戶的頭像和暱稱等資源；

場景二：先後端分離，Vue 項目須要獲取 Core 項目的 當前test1帳號的數據；

首先先理解下四個角色：

一、Resource Owner（資源擁有者） —— 資源全部者，就好比咱們受權登陸中的，QQ用戶，他纔是資源的擁有者。3143422472 / test1帳號

二、Resource Server（資源服務器） —— 資源服務器，用來存儲用戶資源（頭像，暱稱等）的服務器，好比騰訊QQ。騰訊QQ服務器 / Blog.Core

三、Client（客戶端） —— 第三方客戶端，好比博客園；https://www.cnblogs.com / Blog.Vue

四、Authorization Server（受權服務器）—— 受權服務器，用來做爲認證第三方平臺的服務，好比騰訊的QQ互聯平臺。https://graph.qq.com/oauth2.0/show?whic...... / Blog.Idp

而後我們看看具體的流程是怎樣的：

（流程1：參考網上畫的，可能不是很明瞭）

（流程2：本身根據官網圖片作了下修改）

Tips：Web-Hosted Client Resource 服務器至關因而一個存儲 accessToken 的地方，一般指瀏覽器中的存儲（cookie、localStorage、SessionStorge、js變量等），通常這個頁面是看不到的，並且通常狀況是和 Client 客戶端寫在一塊兒的，固然也有分開的。

步驟解析：

客戶端攜帶客戶端標識以及重定向URI到受權服務器；
用戶確認是否要受權給客戶端；
受權服務器獲得許可後，跳轉到指定的重定向地址，並將令牌也包含在了裏面；
客戶端不攜帶上次獲取到的包含令牌的片斷，去請求資源服務器；
資源服務器會向瀏覽器返回一個腳本；
瀏覽器會根據上一步返回的腳本，去提取在C步驟中獲取到的令牌；
瀏覽器將令牌推送給客戶端。

（A步驟）中須要用到的參數，注意在這裏要使用"application/x-www-form-urlencoded"格式：

response_type 必選項，此值必須爲"token"
client_id 必選項
redirect_uri 可選項
scope 可選項
state 建議選項

例如：

&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz

（C步驟）中返回的參數包含：

access_token 必選項
token_type 必選項
expires_in 建議選項
scope 可選項
state 必選項

例如：

HTTP/1.1 302 Found      Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA&state=xyz&token_type=example&expires_in=3600

上邊咱們簡單的說了說 Implicit Flow 模式的相關知識點，不知道你們有沒有一點點感受，若是不是很懂，正好感受配合着下邊的代碼研究下，兩者結合會更好。

3、先後端項目受權聯調

由於咱們用到了先後端分離項目，因此必定是要三方處理，若是你如今使用的是 MVC 模式的話，咱們之後的章節也會說到受權碼受權模式（Authorization Code Flow），這裏先把簡化模式調通了：

一、受權服務端 —— Implicit（Blog.Idp）

這個配置很簡單，在 Blog.Idp 項目中，你們別看是在 Config.cs 文件裏，其實它已經在咱們上一篇文章中，生成到了數據庫中，不懂的請回看上一篇文章

 new Client {
     ClientId = "blogvuejs",//客戶端id
     ClientName = "Blog.Vue JavaScript Client",
     AllowedGrantTypes = GrantTypes.Implicit,
     AllowAccessTokensViaBrowser = true,

     RedirectUris =           { "http://localhost:6688/callback" },//回調頁面
     PostLogoutRedirectUris = { "http://localhost:6688" },
     AllowedCorsOrigins =     { "http://localhost:6688" },
 // 容許的前端獲取的做用域
     AllowedScopes = {
         IdentityServerConstants.StandardScopes.OpenId,
         IdentityServerConstants.StandardScopes.Profile,
         "roles",
         "blog.core.api"
     }
 }

二、資源服務端 —— Bearer（Blog.Core）

這裏的配置是在 Blog.Core 咱們的資源服務器中，在啓動文件 Startup.cs 中，你們自行查看，注意若是使用這個的話，請把 Jwt 認證給註釋掉：

services.AddAuthentication("Bearer")
  .AddIdentityServerAuthentication(options =>
  {
      options.Authority = "http://localhost:5002";//受權服務器地址
      options.RequireHttpsMetadata = false;//是否Https
      options.ApiName = "blog.core.api";//咱們在 Blog.Idp 中配置的資源服務器名
  });

添加過程當中，可能會須要引用擴展包： IdentityServer4.AccessTokenValidation 這都是小問題，你們自行檢查便可。

三、請求客戶端 —— Oidc（Blog.Vue）

上邊咱們已經在兩個服務端作好了配置，客戶端如何處理，這個地方纔是今天的重頭戲，不管是什麼客戶端，JS 或者 Vue、React、Ng 等等前端框架，都須要用到 oidc-client 這個插件庫：

一、安裝

執行命令：npm install oidc-client --save

二、封裝

注意這個是一個js庫，咱們就像以前將 SignalR 那樣，直接使用就行，不用在 main.js 中引用，可是仍是須要先實例化一個用戶管理類 ApplicationUserManager 並配置構造函數，請注意這些參數都要和 Blog.Idp 受權服務器配置一致。

在 src 文件夾下新建 Auth 文件夾，並添加 applicationusermanager.js 來封裝咱們的鏈接管理：

import { UserManager } from 'oidc-client'

class ApplicationUserManager extends UserManager {
  constructor () {
    super({
      authority: 'http://localhost:5002',// 受權服務中心地址
      client_id: 'blogvuejs',// 客戶端 id
      redirect_uri: 'http://localhost:6688/callback',// 登陸回調地址
      response_type: 'id_token token',
      scope: 'openid profile roles blog.core.api',// 做用域也要一一匹配
      post_logout_redirect_uri: 'http://localhost:6688' //登出後回調地址
    })
  }

  async login () {
    await this.signinRedirect()
    return this.getUser()
  }

  async logout () {
    return this.signoutRedirect()
  }
}

同時爲了配合其餘頁面使用，咱們封裝幾個經常使用的方法，在 Auth 文件夾下，新建 UserAuth.js 來封裝用戶的一些基本信息：

import applicationUserManager from "./applicationusermanager";
const userAuth = {
  data() {
    return {
      user: {
        name: "",
        isAuthenticated: false
      }
    };
  },
  methods: {
    async refreshUserInfo() {//獲取用戶信息 const user = await applicationUserManager.getUser();
      if (user) {
        this.user.name = user.profile.name;
        this.user.isAuthenticated = true;
      } else {
        this.user.name = "";
        this.user.isAuthenticated = false;
      }
    }
  },
  async created() {
    await this.refreshUserInfo();
  }
};
export default userAuth;

三、發起登陸/登出請求

咱們封裝好了方法，下邊就是直接設計業務邏輯了，過程很簡單，在 App.vue 組件中：

一、每次路由跳轉需異步獲取用戶數據；

二、發起異步登陸請求；

三、發起異步登出請求；

import applicationUserManager from "./Auth/applicationusermanager";
import userAuth from "./Auth/UserAuth";

export default {
  name: "app",
  mixins: [userAuth],
  data: function() {
    return {};
  },
  watch: {
    $route: async function(to, from) {
      //這裏使用Id4受權認證，用Jwt，請刪之；
      // await this.refreshUserInfo();
    }
  },
  methods: {
    async login() {
      try {
        await applicationUserManager.login();
      } catch (error) {
        console.log(error);
        this.$root.$emit("show-snackbar", { message: error });
      }
    },
    async logout() {
      try {
        await applicationUserManager.logout();
        this.$store.commit("saveToken", "");
      } catch (error) {
        console.log(error);
        this.$root.$emit("show-snackbar", { message: error });
      }
    }
  }
};

四、回調

在上邊的用戶管理配置中，咱們用到了一個回調頁面，這個很重要，由於咱們在登陸成功後，須要調整到客戶端，而且須要將信息給存儲下來，就是上邊流程圖中，咱們說到的客戶端資源

具體怎麼寫的，很簡單，在 views 視圖頁面文件夾下，新建一個 LoginCallbackView.vue 頁面：

import applicationUserManager from '../Auth/applicationusermanager'

export default {
  async created () {
    try {
      // 核心的就是這裏了
      await applicationUserManager.signinRedirectCallback()
        let user = await applicationUserManager.getUser()
        // 將 token 存儲在客戶端
        this.$store.commit("saveToken", user.access_token);
        // 調整首頁
        this.$router.push({name: 'home'})
    } catch (e) {
      console.log(e)
      this.$root.$emit('show-snackbar', { message: e })
    }
  }
}