Asp.net WebApi এ কাস্টম অনুমোদন - কি গোলমাল?

Question

আমি ওয়েবএপিতে অনুমোদনের বিষয়ে বিভিন্ন সংস্থান (বই এবং এসও উত্তর) থেকে পড়ছি।

মনে করুন আমি কাস্টম অ্যাট্রিবিউট যুক্ত করতে চাই যা কেবলমাত্র নির্দিষ্ট ব্যবহারকারীর জন্য অ্যাক্সেসের অনুমতি দেয়:

মামলা 1

আমি ওভাররাইডের এই পদ্ধতিটি দেখেছি OnAuthorization, যা কিছু ভুল হলে প্রতিক্রিয়া সেট করে

public class AllowOnlyCertainUsers : AuthorizeAttribute
{
 public override void OnAuthorization(HttpActionContext actionContext)
  {
   if ( /*check if user OK or not*/)
   {
     actionContext.Response = new HttpResponseMessage(HttpStatusCode.Unauthorized);
   }
  }
}

কেস # 2

তবে আমি এই একই উদাহরণটিও দেখেছি যা ওভাররাইডিং OnAuthorizationকিন্তু কল করার সাথে base:

public override void OnAuthorization(HttpActionContext actionContext) 
{ 
  base.OnAuthorization(actionContext);

    // If not authorized at all, don't bother

    if (actionContext.Response == null)  
     {
      //...
     }
}

তারপরে, আপনি পরীক্ষা করে নিন HttpActionContext.Responseযে সেট করা আছে কি না যদি এটি সেট না করা থাকে তবে এর অর্থ হ'ল অনুরোধটি অনুমোদিত এবং ব্যবহারকারী ঠিক আছে

কেস # 3

তবে আমি ওভাররাইডের এই পদ্ধতিটিও দেখেছি IsAuthorized :

public class AllowOnlyCertainUsers : AuthorizeAttribute
{
 protected override bool IsAuthorized(HttpActionContext context)
  {
   if ( /*check if user OK or not*/)
   {
    return true;// or false
   }
  }
}

কেস # 4

এবং তারপরে আমি একই উদাহরণটি দেখতে পেয়েছি তবে কলিং বেসের সাথে sআইএস অনুমোদিত (প্রসঙ্গ):

protected override bool IsAuthorized(HttpActionContext context)
{
 if (something1 && something2 && base.IsAuthorized(context)) //??
 return true;
 return false;
}

আরেকটা জিনিস

এবং অবশেষে ডোমিনিক এখানে বলেছেন :

আপনার অন-অনুমোদনটিকে ওভাররাইড করা উচিত নয় - কারণ আপনি [AllowAnonymous] হ্যান্ডলিং মিস করবেন missing

প্রশ্নাবলি

• 1) আমার কোন পদ্ধতিগুলি ব্যবহার করা উচিত: IsAuthorizedবা OnAuthorization? (বা কখন ব্যবহার করবেন)

• ২) কখন আমি base.IsAuthorized orবেস কল করব?

• 3) তারা কি এটি এটি তৈরি করে? যে প্রতিক্রিয়া যদি নাল হয় তবে সবকিছু ঠিক আছে? (কেস # 2)

বিশেষ দ্রষ্টব্য

দয়া করে লক্ষ্য করুন, আমি AuthorizeAttributeইতিমধ্যে উত্তরাধিকার সূত্রে প্রাপ্ত কেবলমাত্র (এবং ব্যবহার করতে চাই) ব্যবহার করছিAuthorizationFilterAttribute

কেন?

বুকুয়েজ আমি প্রথম পর্যায়ে এসেছি: http://www.asp.net/web-api/overview/security/authentication-and-authorization-in-aspnet-web-api

যাইহোক আমি অনুমোদনের বৈশিষ্ট্য প্রসারিত করে জিজ্ঞাসা করছি।

Comments

অনুমোদনের বৈশিষ্ট্যটি ওভাররাইড করার জন্য আপনার কী দরকার? আপনি অর্জন করতে চান ইউজকেস কি? আপনার যদি নির্দিষ্ট ব্যবহারকারীদের অ্যাক্সেসের অনুমতি দেওয়ার দরকার হয় তবে কেন [অনুমোদন (ব্যবহারকারী = "প্রশাসন")] বৈশিষ্ট্যটি ব্যবহার করবেন না?

— তাইসর জৌদেহ

@ তাইসরজৌদহ উদাহরণস্বরূপ 10:00 থেকে 12:00 (কনফিগারযোগ্য) এর মধ্যে ব্যবহারকারীদের অনুমোদনের চেষ্টা করুন। আপনি সরল ভূমিকা এবং অনুমোদিত অ্যাটর দিয়ে এটি করতে পারবেন না। আপনাকে নিজের যুক্তি তৈরি করতে হবে

— রই নমির

Answer 1

আমার কোন পদ্ধতিগুলি ব্যবহার করা উচিত: IsAuthorised or OnAuthorization? (বা কখন ব্যবহার করবেন)

AuthorizationFilterAttributeআপনার অনুমোদনের যুক্তিটি প্রতিষ্ঠিত পরিচয় এবং ভূমিকার উপর নির্ভর না করে আপনি প্রসারিত করবেন । ব্যবহারকারী এর সাথে সম্পর্কিত অনুমোদন জন্য, আপনি বর্ধিত করে এবং ব্যবহার করবে AuthorizeAttribute। পূর্ববর্তী ক্ষেত্রে, আপনি ওভাররাইড করবেন OnAuthorization। পরবর্তী ক্ষেত্রে, আপনি ওভাররাইড করবেন IsAuthorized। আপনি যেমন এই বৈশিষ্ট্যগুলির উত্স কোড থেকে দেখতে পাচ্ছেন, OnAuthorizationআপনি যদি থেকে উদ্ভূত হন তবে আপনাকে ওভাররাইড করার জন্য ভার্চুয়াল চিহ্নিত করা হয়েছে AuthorizationFilterAttribute। অন্যদিকে, IsAuthorizedপদ্ধতিটি ভার্চুয়াল ইন হিসাবে চিহ্নিত করা হয়েছে AuthorizeAttribute। আমি বিশ্বাস করি এটি উদ্দিষ্ট ব্যবহারের জন্য একটি ভাল পয়েন্টার।

কবে আমাকে বেস বলা উচিত? আইএস অনুমোদিত বা বেস Oঅনুত্তরকরণ?

এই প্রশ্নের উত্তর ওও সাধারণত কীভাবে কাজ করে তার মধ্যে রয়েছে। আপনি যদি কোনও পদ্ধতিকে ওভাররাইড করে থাকেন তবে আপনি সম্পূর্ণভাবে একটি নতুন বাস্তবায়ন সরবরাহ করতে পারেন বা পিতামাতার দ্বারা সরবরাহিত বাস্তবায়নের পিছনে পিগি ফিরিয়ে দিতে এবং আচরণকে বাড়িয়ে তুলতে পারেন। উদাহরণস্বরূপ, এর ক্ষেত্রে নিন IsAuthorized(HttpActionContext)। বেস শ্রেণীর আচরণটি হ'ল প্রতিষ্ঠানের পরিচয় বনাম ফিল্টারটিতে যা নির্দিষ্ট করা হয়েছে তার বিরুদ্ধে ব্যবহারকারী / ভূমিকা যাচাই করা। বলুন, আপনি সমস্ত কিছু করতে চান তবে উপরন্তু, আপনি অন্য কিছু পরীক্ষা করতে চান, একটি অনুরোধ শিরোনাম বা কোনও কিছুর উপর ভিত্তি করে থাকতে পারে। সেক্ষেত্রে আপনি এর মতো ওভাররাইড সরবরাহ করতে পারেন।

protected override bool IsAuthorized(HttpActionContext actionContext)
{
    bool isAuthroized = base.IsAuthorized(actionContext);
    // Here you look at the header and do your additional stuff based on actionContext
    // and store the result in isRequestHeaderOk
    // Then, you can combine the results
    // return isAuthorized && isRequestHeaderOk;
}

আমি দুঃখিত তবে আপনার কিউ 3 বুঝতে পারছি না। বিটিডাব্লু, অনুমোদনের ফিল্টার দীর্ঘকাল ধরে ছিল এবং লোকেরা এটি সমস্ত ধরণের জিনিস এবং কখনও কখনও ভুলভাবেও ব্যবহার করে।

আরেকটা জিনিস. এবং অবশেষে এখানে এই লোকটি ছিল যিনি বলেছিলেন: আপনার অনঅর্থাইজেশনকে ওভাররাইড করা উচিত নয় - কারণ আপনি [AllowAnonymous] হ্যান্ডলিং মিস করবেন।

যে লোকটি বলেছিল যে প্রবেশাধিকার নিয়ন্ত্রণের Godশ্বর - ডমিনিক D অবশ্যই এটি সঠিক হবে। আপনি যদি OnAuthorizationনীচে (অনুলিপি করা হয়েছে) এর বাস্তবায়নের দিকে নজর দেন ,

public override void OnAuthorization(HttpActionContext actionContext)
{
    if (actionContext == null)
    {
        throw Error.ArgumentNull("actionContext");
    }

    if (SkipAuthorization(actionContext))
    {
        return;
    }

    if (!IsAuthorized(actionContext))
    {
        HandleUnauthorizedRequest(actionContext);
    }
}

কলটি SkipAuthorizationহ'ল সেই অংশ যা নিশ্চিত করে যে AllowAnonymousফিল্টার প্রয়োগ করা হয়, অর্থাত্ অনুমোদন বাদ দেওয়া হয়। আপনি যদি এই পদ্ধতিটিকে ওভাররাইড করেন তবে আপনি সেই আচরণটি আলগা করুন। প্রকৃতপক্ষে, আপনি যদি ব্যবহারকারীদের / ভূমিকার উপর আপনার অনুমোদনের ভিত্তি স্থির করার সিদ্ধান্ত নেন তবে সেই মুহুর্তে আপনি থেকে প্রাপ্ত সিদ্ধান্ত নেবেন AuthorizeAttribute। সেই সময়ে আপনার জন্য কেবল সঠিক বিকল্পটি ওভাররাইড করা হবে IsAuthorizedএবং ইতিমধ্যে ওভাররাইড করা হবে নাOnAuthorization , যদিও প্রযুক্তিগতভাবে এটি করাও সম্ভব।

পুনশ্চ. এএসপি.নেট ওয়েব এপিআইতে, প্রমাণীকরণ ফিল্টার নামে আরও একটি ফিল্টার রয়েছে। আইডিয়াটি হ'ল আপনি নামটি প্রমাণ হিসাবে প্রমাণীকরণ এবং অনুমোদনের জন্য ফিল্টার ব্যবহার করেন। যাইহোক, এখানে অনেকগুলি উদাহরণ রয়েছে যেখানে এই সীমানাটি ফ্যজড। প্রচুর পরিমাণে প্রমাণীকরণ ফিল্টার উদাহরণ কোনও ধরণের প্রমাণীকরণ করবে। যাইহোক, আপনার যদি সময় থাকে এবং আরও কিছুটা বুঝতে চান তবে এই এমএসডিএন নিবন্ধটি একবার দেখুন । দাবি অস্বীকার: এটি আমার লেখা ছিল।

Comments

আবারও ধন্যবাদ, তবে আমি যদি লাইনের মধ্যে পড়ি, ইসআউটিক্যান্টেটেড হ'ল অনঅথাইরাইজেশন দ্বারা কলস, তবে কেন অনঅর্টিফিকেশন এবং কল বেসটি ওভাররাইড করবেন না? অনুমোদন এবং তারপরে প্রতিক্রিয়াটি পরীক্ষা করুন?

— রই নমির

আপনি অবশ্যই এটি করতে পারেন, যদি আপনি চান।

— বদ্রি

আমার তৃতীয় প্রশ্নে আমি বলতে চাইছিলাম: বেস ফাংশনটি চালানোর পরে - বেস.অনুত্তরকরণ উদাহরণস্বরূপ, এটি সফল হয়েছে কিনা তা পরীক্ষা করার একমাত্র উপায়- প্রতিক্রিয়া সম্পত্তিটি পরীক্ষা করা কি ?, উদাহরণগুলি আপনার বই থেকে পাওয়া যায় :-)

— রই নমির

হ্যাঁ, সাধারণত আপনি 401 স্থিতি কোডটি সন্ধান করেন তবে যতদূর আমি জানি ull বিটিডাব্লু, OnAuthorizationআমার বইটিতে ওভাররাইডিং সম্পর্কে লেখার কথা মনে নেই । আমি নিশ্চিত যে আমি শূন্যতার জন্য প্রতিক্রিয়া যাচাই করার বিষয়ে লিখিনি না, কোজ এটিই প্রথমবারের মতো শুনছি :)

— বদ্রি

হ্যাঁ আমি অন্য বইয়ের সাথে বিভ্রান্ত হয়ে পড়েছি। আমি একই সাথে 3 টি বই পড়ছি: সিকিওরটি (আপনার), ব্যবহারিক (আপনার) এবং ওয়েবপি প্রো (টুবার্কস, জিটলার, আলী)। আপনি যেমন দেখতে পাচ্ছেন - তারা এটি সেখানে করেছে: i.stack.imgur.com/LNGi4.jpg - তারা কেবল নাল কিনা তা পরীক্ষা করেছে, তাই আমি নাল বা ত্রুটি কোডগুলি পরীক্ষা করব?

— রই নমির

Answer 2

ঠিক আছে, আমার পরামর্শটি নিম্নলিখিত অনুমান করেই করা উচিত যে আপনি নিজের ওয়েব এপিআই সুরক্ষিত করার জন্য OAuth বহনকারী টোকেন ব্যবহার করছেন এবং আপনি টোকেনটি ইস্যু করার সময় আপনি অনুমতিপ্রাপ্ত ব্যবহারকারীকে দাবি হিসাবে সেট করছেন। আপনি এখানে টোকেন ভিত্তিক প্রমাণীকরণ সম্পর্কে আরও পড়তে পারেন

1. অনুমোদনফিলারঅ্যাট্রিবিউট থেকে প্রাপ্ত কাস্টমঅ্যাটারিাইজএট্রিবিউট তৈরি করুন

2. ওভাররাইড পদ্ধতি OnAuthorizationAsyncএবং নীচের নমুনা কোডটি ব্যবহার করুন:

    public class CustomAuthorizeAttribute : AuthorizationFilterAttribute
   {
   
       public override Task OnAuthorizationAsync(HttpActionContext actionContext, System.Threading.CancellationToken cancellationToken)
       {
   
           var principal = actionContext.RequestContext.Principal as ClaimsPrincipal;
   
           if (!principal.Identity.IsAuthenticated)
           {
               return Task.FromResult<object>(null);
           }
   
           var userName = principal.FindFirst(ClaimTypes.Name).Value;
           var userAllowedTime = principal.FindFirst("userAllowedTime").Value;
   
           if (currentTime != userAllowedTime)
           {
               actionContext.Response = actionContext.Request.CreateResponse(HttpStatusCode.Unauthorized, "Not allowed to access...bla bla");
               return Task.FromResult<object>(null);
           }
   
           //User is Authorized, complete execution
           return Task.FromResult<object>(null);
   
       }
   }

3. এখন আপনার নিয়ন্ত্রণকারীগুলিতে আপনি এই অনুমোদনের যুক্তি ব্যবহার করে আপনার নিয়ন্ত্রণকারীদের সুরক্ষার জন্য কাস্টম-অনুমোদন বৈশিষ্ট্য ব্যবহার করেন।

Comments

ধন্যবাদ। তবে আমি বর্তমানে ব্যবহার করছি AuthorizeAttributeযা উত্তরাধিকারসূত্রে হয় AuthorizationFilterAttributeএবং যা শিখার জন্য তাও আমি বিশেষভাবে জিজ্ঞাসা করেছি যে আমার কোন পদ্ধতিটি ব্যবহার করা উচিত এবং প্রতিক্রিয়ার বিষয়ে বিষয়বস্তু রয়েছে কি না জিনিস ...

— রায় রায় নামির

Answer 3

ASP.NET v5 একটি সম্পূর্ণ নতুন অনুমোদনের সিস্টেম প্রবর্তন করেছে। যারা নেট নেট 5 ব্যবহার করতে যাচ্ছেন তাদের জন্য আমি মাইক্রোসফ্টে যাওয়ার পরামর্শ দিচ্ছি spস্পট নেট.অরধিকারকরণ।

প্রায় কাছাকাছি এটি উভয় রেখে সৃষ্ট জগাখিচুড়ি আপ গোপন System.Web.Http.Authorizeএবং System.Web.Mvc.Authorizeএবং অন্যান্য পুরোনো প্রমাণীকরণ বাস্তবায়নের।

এটি ক্রিয়াকলাপের প্রকারগুলি (তৈরি, পড়ুন, আপডেট করুন, মুছুন), সংস্থানসমূহ, ভূমিকা, দাবী, দর্শন, দর্শন, কাস্টম প্রয়োজনীয়তা এবং উপরের যে কোনওটিকে একত্রিত করে কাস্টম হ্যান্ডলারগুলি তৈরি করতে দেয় a এছাড়াও এই হ্যান্ডলারগুলি সংমিশ্রণেও ব্যবহার করা যেতে পারে।

এএসপি.এনইটি ভি 5-তে অনুমোদন এখন সাধারণ ঘোষণামূলক ভূমিকা এবং আরও সমৃদ্ধ নীতি ভিত্তিক মডেল সরবরাহ করে যেখানে অনুমোদনের প্রয়োজনীয়তাগুলিতে প্রকাশ করা হয় এবং হ্যান্ডলাররা প্রয়োজনের বিরুদ্ধে ব্যবহারকারীদের দাবির মূল্যায়ন করে। জরুরী চেকগুলি সাধারণ নীতি বা নীতিগুলির উপর ভিত্তি করে তৈরি করা যেতে পারে যা ব্যবহারকারীর পরিচয় এবং ব্যবহারকারী যে অ্যাক্সেসের চেষ্টা করছে সেই সংস্থার বৈশিষ্ট্য উভয়ই মূল্যায়ন করে।

Comments

জেনে রাখা ভাল, তবে মোটেই প্রশ্নের উত্তর দেয় না।

— জিরো 3