تعلم ASP.NET MVC


الدرس: إدارة المصادقة


الصفحة السابقة
لذا ، ماذا لو تمكنا أخيرًا من إدارة المصادقة على موقعنا؟
لأنني لا أعرف ما إذا كنت مثلي ، ولكن اختراق TP الأخير لمحاولة التعرف على مستخدم باسم المتصفح ... لم يكن فظيعًا. على أي حال ، لا يستحق كل الآمال التي وضعناها في هذا البرنامج التعليمي. لذلك سنقوم بمعالجة كل هذا ونرى كيف يمكننا تقديم نظام مصادقة على موقعنا ، وذلك لتحديد هوية الشخص بشكل فريد ولكن قبل كل شيء لمنع شخص غير مصادق من الوصول إلى أجزاء معينة من موقعنا.

مصادقة المنزل


تعتمد معظم الموارد على الإنترنت على آلية عضوية ASP.NET لإدارة المصادقة. هذا حل مثير للاهتمام ، على الرغم من أنه بدأ حتى الآن قليلاً ، لكني أجد أنه يخفي إلى حد ما الآليات وراء المصادقة.
في هذا البرنامج التعليمي ، اخترت أن أقدم لك كيفية إجراء مصادقة داخلية لتظهر لك شيئًا آخر وأيضًا يمكنك أن ترى أنه لا يوجد هذا الحل فقط.
لدينا بالفعل العديد من الطرق في DAL لإدارة إنشاء مستخدم ومصادقته. أذكرك:

public interface IDal : IDisposable
{
    […]
    int AjouterUtilisateur(string nom, string motDePasse);
    Utilisateur Authentifier(string nom, string motDePasse);
    Utilisateur ObtenirUtilisateur(int id);
    Utilisateur ObtenirUtilisateur(string idStr);
}
تعمل هذه الطرق نظرًا لأننا كتبنا اختبارات آلية للتحقق منها. حسنًا ... كان ذلك قبل اختراقنا القذر. الآن دعنا نعود إلى أساليبنا الخاصة:

public int AjouterUtilisateur(string nom, string motDePasse)
{
    string motDePasseEncode = EncodeMD5(motDePasse);
    Utilisateur utilisateur = new Utilisateur { Prenom = nom, MotDePasse = motDePasseEncode };
    bdd.Utilisateurs.Add(utilisateur);
    bdd.SaveChanges();
    return utilisateur.Id;
}

public Utilisateur Authentifier(string nom, string motDePasse)
{
    string motDePasseEncode = EncodeMD5(motDePasse);
    return bdd.Utilisateurs.FirstOrDefault(u => u.Prenom == nom && u.MotDePasse == motDePasseEncode);
}

public Utilisateur ObtenirUtilisateur(int id)
{
    return bdd.Utilisateurs.FirstOrDefault(u => u.Id == id);
}

public Utilisateur ObtenirUtilisateur(string idString)
{
    int id;
    if (int.TryParse(idString, out id))
        return ObtenirUtilisateur(id);
    return null;
}
و أيضا :

public bool ADejaVote(int idSondage, string idStr)
{
    int id;
    if (int.TryParse(idStr, out id))
    {
        Sondage sondage = bdd.Sondages.First(s => s.Id == idSondage);
        if (sondage.Votes == null)
            return false;
        return sondage.Votes.Any(v => v.Utilisateur != null && v.Utilisateur.Id == id);
    }
    return false;
}
هنا ، أصبحت DAL جاهزة مرة أخرى لإدارة المصادقة وستعمل جميع اختباراتنا مرة أخرى. 

مصادقة نموذج ASP.NET


يحتوي ASP.NET على نظام مصادقة تم تطويره في عصر Webforms ، والذي يتكامل بشكل مثالي مع إطار عمل MVC ؛ يطلق عليه مصادقة النموذج . يعمل من خلال ملفات تعريف الارتباط.
المبدأ هو أنه عندما يرسل عميل طلب HTTP للوصول إلى مورد آمن ، يتحقق ASP.NET من وجود ملف تعريف ارتباط المصادقة. إذا لم تتم مصادقة المستخدم ، فسيتم إعادة توجيهه إلى صفحة مصادقة ، وإلا يمكنه متابعة التصفح. عندما يصادق المستخدم ، يقوم ASP.NET بإنشاء ملف تعريف الارتباط هذا للسماح له بالوصول إلى الموارد الآمنة.
يتم تشفير المعلومات الموجودة في ملف تعريف الارتباط هذا بواسطة ASP.NET . كل ما نحتاج إلى معرفته هو أنه من الممكن استعادة المستخدم الحالي وإذا تم المصادقة عليه بفضل خصائص الكائن:

HttpContext.User.Identity
على سبيل المثال ، لمعرفة ما إذا كان المستخدم مصادقًا ، يمكننا استخدام:

HttpContext.User.Identity.IsAuthenticated
ولمعرفة معرف المستخدم الذي قام بتسجيل الدخول ، يمكننا استخدام:

HttpContext.User.Identity.Name
لتنشيط هذه المصادقة ، هناك إعداد صغير في web.config . يجب تعريف قسم المصادقة تحت القسم <system.web> :

<authentication mode="Forms">
  <forms loginUrl="~/Login/Index" />
</authentication>
وضع المصادقة هو نماذج (= نموذج) وعنوان URL المستخدم لتسجيل الدخول سيكون /Login/Index.
وبالتالي ، سيتم إعادة توجيه أي طلب للوصول إلى مورد محمي ، وحيث لا تتم المصادقة على المستخدم ، إلى صفحة تسجيل الدخول التي تم تكوينها.
لذلك يجب علينا تأمين وحدات التحكم المناسبة ، ثم كتابة وحدة تحكم تسمح بالمصادقة والتي يمكن الوصول إليها عبر عنوان URL /Login/Index . دعنا نذهب!

تأمين وحدة تحكم


أقول لك على الفور ، لتأمين وحدة تحكم أمر سهل للغاية. سنقوم بتأمين وحدة التحكم في التصويت حتى يتمكن الأشخاص المصادق عليهم فقط من الوصول إليها. انظروا كم هو بسيط:

 [Authorize]
public class VoteController : Controller
{
    …
}
وهذا كل شيء. 
ما عليك سوى استخدام السمة Authorize   في الفئة ، وبمجرد محاولة استدعاء إجراء من وحدة التحكم هذه ، سيتحقق ASP.NET MVC من أنك مصادق. إذا لم يكن الأمر كذلك ، فستتم إعادة توجيهك إلى صفحة تسجيل الدخول.
إليك ما يحدث عند النقر فوق الزر إنشاء استطلاع:
ASP.NET framework
لم يتم العثور على إعادة التوجيه للمصادقة
ما هو مهم أن نراه هنا هو أنه تمت إعادة توجيهنا إلى عنوان URL /Login/Index، كما هو متوقع ... ولكن هناك أيضًا شيء آخر في عنوان URL :
http://localhost:60818/Login/Index?ReturnUrl=%2fVote%2fIndex%2f1
يمكننا رؤية مُدخل ReturnUrl التي تشير إلى أننا قد أتينا من عنوان URL /Vote/Index/1 (بالطبع تم ترميز عنوان URL ) .
تأتي رسالة الخطأ بالطبع من حقيقة أن وحدة التحكم Login   وعملها Index   غير موجودين ...
وها ، لا يمكنك الوصول إلى الاستبيان دون مصادقة ؛ في كل مرة تتم إعادة توجيهنا إلى صفحة المصادقة. ونظرًا لعدم وجوده ، سيتعين علينا إنشاؤه للسماح للمستخدم بالمصادقة بشكل صحيح.
من الممكن أيضًا تأمين الطرق بشكل فردي ، بدلاً من تأمين وحدة تحكم كاملة. ما عليك سوى نقل السمة Authorize   واستخدامها لتزيين الطرق التي تريد تأمينها:

 [Authorize]
public ActionResult Index(int id)
{
    …
}
على العكس ، إذا تم تأمين وحدة التحكم بشكل كامل ، فمن الممكن إلغاء تأمين الإجراءات بشكل فردي عن طريق تزيينها بالسمة AllowAnonymous :

 [Authorize]
public class VoteController : Controller
{
    [AllowAnonymous]
    public ActionResult Index(int id)
    {
        …
    }
}
ملاحظة: تعتمد آلية المصادقة على مرشحات ASP.NET MVC التي سنكتشفها بعد قليل.

اكتب وحدة التحكم للمصادقة


الآن دعونا نسمح للمستخدم بالمصادقة عن طريق كتابة وحدة تحكم المصادقة.
يخبرك عنوان URL الذي حددناه في web.config (/Login/Index) بالفعل عن وحدة التحكم التي سنكتبها. إنها وحدة التحكم Login  . هنا هو كوده:

public class LoginController : Controller
{
    private IDal dal;

    public LoginController() : this(new Dal())
    {

    }

    private LoginController(IDal dalIoc)
    {
        dal = dalIoc;
    }

    public ActionResult Index()
    {
        UtilisateurViewModel viewModel = new UtilisateurViewModel { Authentifie = HttpContext.User.Identity.IsAuthenticated };
        if (HttpContext.User.Identity.IsAuthenticated)
        {
            viewModel.Utilisateur = dal.ObtenirUtilisateur(HttpContext.User.Identity.Name);
        }
        return View(viewModel);
    }

    [HttpPost]
    public ActionResult Index(UtilisateurViewModel viewModel, string returnUrl)
    {
        if (ModelState.IsValid)
        {
            Utilisateur utilisateur = dal.Authentifier(viewModel.Utilisateur.Prenom, viewModel.Utilisateur.MotDePasse);
            if (utilisateur != null)
            {
                FormsAuthentication.SetAuthCookie(utilisateur.Id.ToString(), false);
                if (!string.IsNullOrWhiteSpace(returnUrl) && Url.IsLocalUrl(returnUrl))
                    return Redirect(returnUrl);
                return Redirect("/");
            }
            ModelState.AddModelError("Utilisateur.Prenom", "Prénom et/ou mot de passe incorrect(s)");
        }
        return View(viewModel);
    }

    public ActionResult CreerCompte()
    {
        return View();
    }

    [HttpPost]
    public ActionResult CreerCompte(Utilisateur utilisateur)
    {
        if (ModelState.IsValid)
        {
            int id = dal.AjouterUtilisateur(utilisateur.Prenom, utilisateur.MotDePasse);
            FormsAuthentication.SetAuthCookie(id.ToString(), false);
            return Redirect("/");
        }
        return View(utilisateur);
    }

    public ActionResult Deconnexion()
    {
        FormsAuthentication.SignOut();
        return Redirect("/");
    }
}
يمكنك أن ترى أنه في طريقة index ، أتحقق من مصادقة المستخدم باستخدام الخاصية HttpContext.User.Identity.IsAuthenticated  . إذا كان هذا هو الحال ، فأنا استرد هذا المستخدم عبر DAL . لاحظ أنني قمت بإنشاء نموذج عرض لإعداد بياناتي للعرض في واجهة العرض:

public class UtilisateurViewModel
{
    public Utilisateur Utilisateur { get; set; }
    public bool Authentifie { get; set; }
}
هذا يزودني بالمستخدم وأيضًا إذا تمت مصادقة المستخدم.
عند الوصول إلى العرض ، إذا لم تتم المصادقة على المستخدم ، فسنزوده بنموذج للقيام بذلك. لذلك من الضروري معالجة هذا النموذج ، إنها مهمة الطريقة Index   التي تهتم بإدارة POST . ستلاحظ أن هذه الطريقة لها مُدخلان:

 [HttpPost]
public ActionResult Index(UtilisateurViewModel viewModel, string returnUrl)
{
    …
}
يوجد بالفعل نموذج العرض ، وهو أمر معتاد تمامًا ؛ سيعالج محتوى النموذج. ولكن هناك أيضًا مُدخل سلسلة أخرى. كنت قد خمنت بفضل التسمية أن هذا سيسمح بالقبض على المُدخل المحتمل ReturnUrl   التي يمكن وضعها من قبل ASP.NET عندما يعيد توجيهنا إلى نموذج المصادقة بعد محاولة الوصول إلى مورد بينما نحن لا يمكن. تذكر أن عنوان URL هذا كان مثل:
/Login/Index?ReturnUrl=%2fVote%2fIndex%2f1
لذا ، لدينا الفرصة هنا لاسترداد عنوان URL للإرجاع. لماذا؟ من أجل إعادة توجيه المستخدم إلى المورد الذي كان يحاول الحصول عليه قبل إعادة توجيهه إلى المصادقة ، مما يبسط رحلته.
لذا يسمح لك الإجراء أولاً بالتحقق من صلاحية النموذج. في هذه الحالة ، سيتحقق من أن الاسم الأول وكلمة المرور مكتوبين جيدًا ، وذلك عبر الخاصية ModelState.IsValid  . بعد ذلك ، سنقوم بمصادقة المستخدم. إذا كان الاسم الأول وكلمة المرور لا يسمحان بذلك ، فإننا نضيف خطأ من ModelState   أجل إبلاغ العرض. انتباه ، هنا الحقل الذي به خطأ هو User.Firstname لأنه مسار الوصول عبر نموذج العرض.
إذا كان تسجيل الدخول وكلمة المرور صالحين ، فكل ما عليك فعله هو مصادقة المستخدم على ASP.NET عن طريق إنشاء ملف تعريف ارتباط. يتم ذلك عن طريق استدعاء الأسلوب FormsAuthentication.SetAuthCookie  . تقوم هذه الطريقة بإنشاء ملف تعريف ارتباط المصادقة من معرف المستخدم. هذا ما اخترته كمعلومات مصادقة. false  يسمح المُدخل الثاني الموضح في التأكد من أن مدة المصادقة تقتصر على الجلسة فقط.
سيسمح استدعاء هذه الطريقة بشكل غير مباشر بإبلاغ خصائص الكائن HttpContext.User.Identity   الذي يسمح لنا بالتحقق من أن المستخدم مصادق.
بعد ذلك ، إذا كان المُدخل في عنوان URL موجود ، فأنا أعالجها من أجل إعادة المستخدم إلى الصفحة التي طلبها سابقًا. لاحظ أن عنصر التحكم IsLocalUrl   لا يتم إجراء ذلك فقط لجعله يبدو جميلًا ، ولكنه يتأكد من أن مُدخل ReturnUrl تحتوي على رابط إلى موقعنا ، وذلك لتجنب أي محاولة لإعادة التوجيه إلى موقع غير خاص بنا.
بمجرد استرداد هذا المُدخل بشكل صحيح ، يمكننا إعادة توجيه المستخدم إلى المكان الصحيح.
قمت أيضًا بتنفيذ إجراءات لإنشاء حساب. يعرض الإجراء في GET العرض ببساطة ، وأنه في POST يعالج النموذج ويستدعي DAL لإنشاء الحساب. نحن بالطبع نستخدم نفس الطريقة التالية لإنشاء ملف تعريف الارتباط.
انتهزت أيضًا الفرصة لإنشاء إجراء يسمح للمستخدم بتسجيل الخروج. ما عليك سوى استدعاء الطريقة FormsAuthentication.SignOut()   لتفريغ ملف تعريف ارتباط المصادقة.
أما بالنسبة إلى العرض ، فلا شيء جديد ، فالطريقة التي تتيح المصادقة كلاسيكية جدًا:


    @model ChoixResto.ViewModels.UtilisateurViewModel

    [...]
    
    @if (Model.Authentifie)
    {
        <h3>
            Vous êtes déjà authentifié avec le login :
            @Model.Utilisateur.Prenom
        </h3>
        @Html.ActionLink("Voulez-vous vous déconnecter ?", "Deconnexion")
    }
    else
    {
        <p>
            Veuillez vous authentifier :
        </p>
        using (Html.BeginForm())
        {
            <div>
                @Html.LabelFor(m => m.Utilisateur.Prenom)
                @Html.TextBoxFor(m => m.Utilisateur.Prenom)
                @Html.ValidationMessageFor(m => m.Utilisateur.Prenom)
            </div>
            <div>
                @Html.LabelFor(m => m.Utilisateur.MotDePasse)
                @Html.PasswordFor(m => m.Utilisateur.MotDePasse)
                @Html.ValidationMessageFor(m => m.Utilisateur.MotDePasse)
            </div>
            <input type="submit" value="Se connecter" />
            <br />
            @Html.ActionLink("Créer un compte", "CreerCompte")
        }
    }
يمكنك ملاحظة أن لدي if كبيرةً في المنتصف مما يسمح لي بعرض شيئين مختلفين اعتمادًا على ما إذا كان المستخدم مصدقًا بالفعل:
ASP.NET framework
نموذج المصادقة
او لا :
ASP.NET framework
العرض عندما تتم مصادقتك بالفعل
ملاحظة: للحصول على هذا النموذج الرائع ، كان علي أن أضيف سمات Display   للنموذج Utilisateur   :

public class Utilisateur
{
    public int Id { get; set; }
    [Required]
    [Display(Name = "Prénom")]
    public string Prenom { get; set; }
    [Required]
    [Display(Name = "Mot de passe")]
    public string MotDePasse { get; set; }
}
وبالتالي فإن الحقول Prenom   و MotDePasse   استخدام قنوات قليلا أكثر ملاءمة.
بالنسبة إلى عرض إنشاء الحساب ، فهو نفس المبدأ:

@model  ChoixResto.Models.Utilisateur

[...]

Créer un compte :

@using (Html.BeginForm()) {
@Html.LabelFor(m => m.Prenom) @Html.TextBoxFor(m => m.Prenom) @Html.ValidationMessageFor(m => m.Prenom)
@Html.LabelFor(m => m.MotDePasse) @Html.PasswordFor(m => m.MotDePasse) @Html.ValidationMessageFor(m => m.MotDePasse)
}
ها أنت ذا .
لم أرغب في التحدث عنه هنا ، ولكن من الممكن أيضًا قصر الإجراءات على مجموعة معينة من المستخدمين. غالبًا ما يتم ذلك بشكل خاص لأجزاء الإدارة في الموقع. قد يكون هذا هو الحال في تطبيقنا ، قد نرغب في السماح بالوصول إلى إضافة مطعم أو تعديل فقط لمسؤولي الموقع. هنا ، لا يبدو لي أنه ذو صلة.
إذا كنت بحاجة إلى ذلك ، فاعلم أنك بحاجة إلى إدارة نظام الأدوار ، على سبيل المثال باستخدام آلية إدارة الأدوار لـ ASP.NET  . ثم يمكنك تغيير السمة Authorize   بحيث تأخذ مجموعة كمُدخل:

 [Authorize(Roles="Administrateur")]
public ActionResult CreerRestaurant()
{
   …
}

استخدم الهوية


بقي شيء واحد فقط للقيام به. الآن بعد أن عرفنا من هو المستخدم ، نحتاج إلى استخدامه في وحدة تحكم Vote ( VoteController ) ، خاصة عندما نستخدم الطريقة ObtenirUtilisateur   :

Utilisateur utilisateur = dal.ObtenirUtilisateur(HttpContext.User.Identity.Name);
في الخاصية Name نجد معرف المستخدم لأنه هو الذي نضعه من خلال استدعاء الطريقة SetAuthCookie :

FormsAuthentication.SetAuthCookie(id.ToString(), false);
بفضل هذا المعرف المخزن في ملف تعريف الارتباط ، يمكننا العثور على المستخدم الذي يتصفح. لذا استبدل الكل:

Request.Browser.Browser
بواسطة:

HttpContext.User.Identity.Name
يمكنك أيضًا تصحيح الاختبارات VoteControllerTests   بحيث لا تستخدم حد الخاصية بعد Browser   ذلك ، بل يمكنك تحديد الحد الأقصى Identity.Name  . لذا قم بتغيير طريقة Init من الفئة   VoteControllerTests  ليكون:

 [TestInitialize]
public void Init()
{
    dal = new DalEnDur();
    idSondage = dal.CreerUnSondage();

    Mock<ControllerContext> controllerContext = new Mock<ControllerContext>();
    controllerContext.Setup(p => p.HttpContext.User.Identity.Name).Returns("1");

    controleur = new VoteController(dal);
    controleur.ControllerContext = controllerContext.Object;
}
وكذلك طريقة الاختبار:

 [TestMethod]
public void IndexPost_AvecViewModelValideEtUtilisateur_AppelleBienAjoutVoteEtRenvoiBonneAction()
{
    Mock<IDal> mock = new Mock<IDal>();
    mock.Setup(m => m.ObtenirUtilisateur("1")).Returns(new Utilisateur { Id = 1, Prenom = "Nico" });

    Mock<ControllerContext> controllerContext = new Mock<ControllerContext>();
    controllerContext.Setup(p => p.HttpContext.User.Identity.Name).Returns("1");
    controleur = new VoteController(mock.Object);
    controleur.ControllerContext = controllerContext.Object;

    RestaurantVoteViewModel viewModel = new RestaurantVoteViewModel
    {
        ListeDesResto = new List<RestaurantCheckBoxViewModel>
            {
                new RestaurantCheckBoxViewModel { EstSelectionne = true, Id = 2, NomEtTelephone = "Resto pinière (0102030405)"},
                new RestaurantCheckBoxViewModel { EstSelectionne = false, Id = 3, NomEtTelephone = "Resto toro (0102030405)"},
            }
    };
    controleur.ValideLeModele(viewModel);

    RedirectToRouteResult resultat = (RedirectToRouteResult)controleur.Index(viewModel, idSondage);

    mock.Verify(m => m.AjouterVote(idSondage, 2, 1));
    Assert.AreEqual("AfficheResultat", resultat.RouteValues["action"]);
    Assert.AreEqual(idSondage, resultat.RouteValues["id"]);
}
والآن ، كل شيء في مكانه الآن بحيث لا يمكن الوصول إلى بقية التطبيق إلا للأشخاص المصادق عليهم.

المصادقة عند إنشاء مشروع


حتى الآن ، استخدمنا فقط قالب المشروع "الفارغ" عندما أردنا إنشاء مشروع ASP.NET MVC . وإذا نظرت بعناية أثناء إنشاء هذا المشروع ، يمكنك أن ترى على اليمين أنه كان هناك عنصر رمادي مع علامة "لا مصادقة" مميزة:
ASP.NET framework
لا مصادقة لنموذج فارغ
من ناحية أخرى ، إذا حاولت اختيار نموذج آخر بدلاً من ذلك ، على سبيل المثال MVC ، فستتمكن من رؤية أن الزر غير نشط ، وتقترح مصادقة بناءً على حسابات المستخدمين الفرديين:
ASP.NET framework
مصادقة نوع حسابات المستخدم الفردية
إذا قمت بالنقر فوق الزر "تعديل المصادقة" ، فستتمكن حينئذٍ من رؤية أنواع أخرى من المصادقة:
ASP.NET framework
أنواع المصادقة المختلفة
لذلك ، لدينا تحت تصرفنا:
لا مصادقة للتطبيقات التي لا تتطلب المصادقة
حسابات المستخدم الفردية للتطبيقات التي تقوم بتخزين ملفات تعريف المستخدمين في قاعدة بيانات SQL Server. يمكن للمستخدمين التسجيل أو تسجيل الدخول باستخدام حساباتهم على Facebook و Twitter و Google و Microsoft وما إلى ذلك. موجود
حسابات المؤسسة بالنسبة للتطبيقات التي تقوم بمصادقة المستخدمين إلى Active Directory أو Windows Azure Active Directory أو Office 365
مصادقة Windows لتطبيقات الإنترانت
إذا قمت بإنشاء التطبيق باستخدام حسابات المستخدمين الفرديين ، فيمكنك أن ترى أن Visual Studio قد أنشأ حلًا لك يحتوي على الكثير من الملفات الجديدة وبشكل خاص إذا كنت سترى في دليل App_Start ، فستتمكن من العثور على الملف على سبيل المثال StartupAuth.cs الذي سيقوم بتكوين المصادقة. والأمر الرائع هو أن لديك بالفعل الكثير من الأشياء لإدارة الاتصال بمزودي الطرف الثالث ؛ عليك فقط إلغاء تعليق الاسطر (وتقديم معلومات من تطبيقات الطرف الثالث ، مثل المفاتيح والأسرار) لاستخدامها:

// Supprimer les commentaires des lignes suivantes pour autoriser la connexion avec des fournisseurs de connexions tiers
//app.UseMicrosoftAccountAuthentication(
// clientId: "",
// clientSecret: "");

//app.UseTwitterAuthentication(
// consumerKey: "",
// consumerSecret: "");

//app.UseFacebookAuthentication(
// appId: "",
// appSecret: "");

//app.UseGoogleAuthentication(new GoogleOAuth2AuthenticationOptions()
//{
// ClientId = "",
// ClientSecret = ""
//});
هذا يبسط إلى حد كبير هذا النوع من المصادقة ، التي أصبحت تقليدية أكثر فأكثر.
أشجعك على إلقاء نظرة أيضًا على وحدة التحكم  AccountController  التي أنشأها Visual Studio .

هوية ASP.NET


لم يتطور نظام المصادقة لـ ASP.NET منذ عام 2005. ومؤخرًا ، قام بجعل شبابًا جديدًا مع دمج هوية ASP.NET ، يمكن استخدامه بالطبع دون مشاكل مع ASP.NET MVC . من الواضح أن هناك دائمًا طريقة لتسجيل مستخدمينا في قاعدة بيانات وهذه الآلية مبسطة بفضل واجهات برمجة التطبيقات الخاصة بهوية ASP.NET ، ولكن من الممكن أيضًا الاتصال بموفري هوية آخرين ، مثل Facebook ، Google ، ... هذا ما رأيناه أعلاه ، حتى لو لم أخوض في تفاصيل التنفيذ.
للتبسيط ، يمكننا القول أن هوية ASP.NET هي نظام العضوية الجديد لـ ASP.NET . وهو يعتمد على البرامج الوسيطة للمصادقة OWIN ، أي طبقة مستقلة سيتم استخدامها للمصادقة.
OWIN هي اختصار لـ Open Web Interface لـ .NET . إن فكرة OWIN هي إنشاء تجريد بين خوادم الويب ومكونات الإطار من أجل أن تكون قادرًا على نشر تطبيق ويب على أي خادم يحترم معيار OWIN .
ما سيتغير لمصادقتنا هو أنها ستستند إلى واجهات تحترم معيار OWIN ، وعلينا فقط تنفيذ هذه الواجهات بالحل الذي اخترناه لإدارة مصادقتنا ، سواء في قاعدة بيانات ، في Azure ، مع Active Directory ، ...

باختصار


  • إن مصادقة ASP.NET سهلة الإعداد وتسمح لك بتأمين وحدات التحكم أو الإجراءات في التطبيق الخاص بك.
  • يمكنك استخدام مصادقة النموذج مع استخدام السمة [Authorize] .
  • تعمل مصادقة النموذج مع ملف تعريف ارتباط مشفر.
  • تجلب هوية ASP.NET تجديدًا في المصادقة ، وهي قادرة على استخدام خدمات الطرف الثالث للمصادقة ، دون الاعتماد بشكل كامل على ASP.NET .