.NET Tips | جستجوها: نتایج جستجوی «identity server refresh token»، صفحه: ۷

سید علیرضا حسینی

اشتراک‌ها

سری ASP.NET Core Identity

ASP.NET Core Identity is Microsoft’s membership system widely known to .NET developers for managing application users.

‫۶ سال و ۵ ماه قبل، یکشنبه ۹ اردیبهشت ۱۳۹۷، ساعت ۱۹:۲۲

وحید نصیری

اشتراک‌ها

کتاب راهنمای Claims-Based Identity

A Guide to Claims-Based Identity and Access Control, Second Edition - Book Download

‫۸ سال و ۶ ماه قبل، پنجشنبه ۲۶ فروردین ۱۳۹۵، ساعت ۲۲:۴۶

فرهاد فرهمندخواه

مطالب

نحوه ایجاد Sequence و استفاده آن در Sql Server 2012

قبل از ایجاد Sequence در Sql Server 2012، توضیح مختصری را درباره آن می‌دهم.
در واقع Sequence روشی برای تولید اعداد ترتیبی با قابلیت افزایش یا کاهش عدد‌های دلخواه می‌باشد که توسط کاربر یا برنامه نویس ایجاد می‌شود. بنابراین Sequenceها User-Defined می‌باشند.
در اینجا ممکن است سئوالی پیش بیاید که اینکار توسط Identity هم قابل انجام است، اما چرا استفاده از Sequence توسط مایکروسافت پیشنهاد می‌شود.
بدلایل زیر استفاده از Sequence بهتر می‌باشد:

ممکن است Application شما قبل از درج رکورد، درون یک جدول نیاز به عدد منحصربفردی داشته باشد.
عدد تولید شده بوسیله Sequence را می‌توانید بین جداول یا ستونهای مختلف یک جدول به اشتراک بگذارید.
می‌توانید روند تولید اعداد ترتیبی را Restart نمایید. به عبارت دیگر قابلیت Restart نمودن Sequence وجود دارد.
می‌توانید Sequence خود را براساس Sort یک یا چند فیلد، تنظیم نمایید.

Syntax آن به شرح ذیل می‌باشد:

CREATE SEQUENCE [schema_name . ] sequence_name
    [ AS [ built_in_integer_type | user-defined_integer_type ] ]
    [ START WITH <constant> ]
    [ INCREMENT BY <constant> ]
    [ { MINVALUE [ <constant> ] } | { NO MINVALUE } ]
    [ { MAXVALUE [ <constant> ] } | { NO MAXVALUE } ]
    [ CYCLE | { NO CYCLE } ]
    [ { CACHE [ <constant> ] } | { NO CACHE } ]
    [ ; ]

شرح Syntax :

در زمان ایجاد Sequence، نوع آن می‌بایست عددی باشد، چنانچه ،Type آن را مشخص ننمایید، SQL Server، نوع آن را bigint در نظر می‌گیرد.
Start With: بدین مفهوم می‌باشد، که Sequence ایجاد شده از چه عددی آغاز شود.
INCREMENT BY: مفهومش این است که Sequence به چه مقداری افزایش یا کاهش یابد. به عبارت دیگری عدد تولید شده براساس مقدار Increment by تولید می‌شود.
Minvalue: کمترین مقداری که Sequence می‌تواند ایجاد نماید.
Maxvalue :بیشترین مقداری که Sequence می‌تواند ایجاد نماید.
Cycle :مقداری را که برای Cycle تعیین می‌نماییم، بدین مفهوم است که Sequence پس از چه عددی می‌بایست Restart شود.
Cache :عددی که برای Cache در نظر می‌گیریم، مفهومش این است که چه تعداد از اعداد تولید شده توسط Sequence، قبل از استفاده، می‌تواند در Cache قرار گیرد.

در ادامه با یک مثال ساده، یک Sequence ایجاد می‌نماییم:

CREATE SEQUENCE [dbo].[SequenceTest] 
 AS [int]
 START WITH 1
 INCREMENT BY 1
 MINVALUE 1
 MAXVALUE 30
 CYCLE 
 CACHE 
GO

در مثال بالا Start with برابر یک است، یعنی اولین عددی که تولید می‌شود، برابر یک است،INCREMENT BY برابر یک است یعنی در هر بار فراخوانی Sequence یک عدد به عدد تولید شده قبلی افزوده می‌شود. مقدار Minvalue برابر یک است، یعنی کمترین مقداری که Sequence می‌تواند تولید نماید برابر یک است. مقدار Maxvalue برابر 30 است، یعنی بیشترین مقداری که Sequence می‌تواند تولید نماید برابر 30 می‌باشد. و Cycle هم برای Sequence فوق در نظر گرفته شده است، بدین مفهوم ، که Sequence به مقدار 30 برسد، Restart شده و از مقدار یک شروع به تولید اعداد می‌نماید.
برای اینکه بتوانیم مقدار Sequence را بدست آوریم، کافیست از Syntax زیر استفاده نمایید:

NEXT VALUE FOR [ database_name . ] [ schema_name . ]  sequence_name
   [ OVER (<over_order_by_clause>) ]

به عنوان مثال داریم:

اگر Select بالا را تا 30 بار انجام دهید، برای دفعه 31 مقدار آن یک می‌شود، چون در زمان تعریف Cycle ،Sequence را انتخاب کرده بودیم. در غیر اینصورت برای دفعه 31 با خطا زیر مواجه می‌شوید.

Msg 11728, Level 16, State 1, Line 1
The sequence object 'SequenceTest' has reached its minimum or maximum value. Restart the sequence object to allow new values to be generated.

یکی از امکانات جالب Sequence این است که شما می‌توانید Sequence را روی یک فیلد Sort شده تنظیم نمایید، برای روش شدن مطلب به مثال زیر توجه نمایید:
در ابتدا مطابق Script زیر جدولی را ایجاد و مقادیری را درون آن درج می‌نماییم:

create table Kids
( ID int,
Name varchar(50)
);
Go
insert Kids
 values
  (1,'Emma')
, (1,'Tabitha')
, (2,'Kendall')
, (3,'Delaney')
, (4,'Kyle')
, (5,'Jessica')
, (6,'Josh')
, (7,'Kirsten')
, (8,'Amanda')
, (9,'Jimmy')
;

سپس یک Schema به نام Sample ایجاد می‌کنیم:

CREATE SCHEMA Samples ;
GO

در ادامه یک Sequence به نام Test ایجاد می‌کنیم:

CREATE SEQUENCE Samples.Test
    AS tinyint
    START WITH 1
    INCREMENT BY 1 ;
GO

حال Query زیر را اجرا می‌نماییم:

SELECT NEXT VALUE FOR Samples.Test OVER (ORDER BY Name) AS NutID, ID, Name FROM  test1.Kids
WHERE Name LIKE '%e%' ;

در Query بالا روی فیلد Name به صورت صعودی عملیات Sort انجام می‌شود، و سپس Sequence روی آن اعمال می‌گردد، برای روشن‌تر شدن مطلب خروجی را مشاهده نمایید که تعداد رکورد آن 6 میباشد.

امیدوارم مطلب فوق مفید واقع شده باشد.

‫۱۲ سال و ۱ ماه قبل، شنبه ۲۲ مهر ۱۳۹۱، ساعت ۱۸:۳۸

وحید نصیری

اشتراک‌ها

ASP.NET Identity 2.2.1 منتشر شد

این به روز رسانی با نگارش قبلی سازگار است و خصوصا تعداد بار فراخوانی GetClaimsAsync کمتری دارد (سبک‌تر است).

‫۹ سال و ۷ ماه قبل، چهارشنبه ۱۹ فروردین ۱۳۹۴، ساعت ۱۴:۵۵

رشوند

اشتراک‌ها

آموزش فارسی ASP.NET Identity

اموزش روانی است,

برای مطالعه بیشتر در سایت جاری

‫۱۰ سال و ۳ ماه قبل، سه‌شنبه ۱۴ مرداد ۱۳۹۳، ساعت ۲۱:۵۴

وحید نصیری

اشتراک‌ها

گزینه‌های سفارشی سازی ASP.NET Identity

برای برنامه‌های موجود و جدید

‫۱۰ سال و ۱۰ ماه قبل، جمعه ۲۰ دی ۱۳۹۲، ساعت ۱۷:۴۸

مجتبی کاویانی

اشتراک‌ها

عرضه ASP.NET Identity 2.1.0-alpha1

خوشبختانه در این نگارش پیشنهاد متود الحاقی ()<GetUserId<T را داده بودم که اضافه شده است.

حالا با سفارشی سازی ASP.NET Identity، از این متود الحالی به راحتی می‌توانیم UserId را بدست بیاوریم

User.Identity.GetUserId<int>();

جزئیات بیشتر...

‫۱۰ سال و ۵ ماه قبل، شنبه ۱۷ خرداد ۱۳۹۳، ساعت ۱۵:۵۹

وحید نصیری

اشتراک‌ها

بهبود کارآیی ASP.NET Identity

ASP.NET Identity «بی‌جهت» از متد upper برای تولید کوئری‌های یافتن کاربران استفاده می‌کند. این مورد سبب خواهد شد تا دیگر از index استفاده نگردد. به این دلیل این کار «بی‌جهت» است که واقعا کسی از case sensitive collation در عمل استفاده نمی‌کند و استفاده‌ی از متد upper یک کار اضافی بوده‌است.

‫۹ سال و ۸ ماه قبل، پنجشنبه ۲۳ بهمن ۱۳۹۳، ساعت ۱۳:۵۸

وحید نصیری

مطالب

بررسی فرمت کوکی‌های ASP.NET Identity

فرمت کوکی‌های ASP.NET Identity از پروژه‌ی سورس باز Katana دریافت شده‌است و تولید آن پس از لاگین کاربر، شامل مراحل زیر می‌باشد:
1- با استفاده از کلاس ApplicationUser، شیء ClaimsPrincipal را تولید می‌کند.
2- به این ClaimsPrincipal اطلاعاتی مانند ApplicationUser.Id و SecurityStamp اضافه می‌شوند.
3- در ادامه، ClaimsPrincipal به OWIN و کلاس CookieAuthenticationHandler آن ارسال می‌شود.
4- کار کلاس CookieAuthenticationHandler، تولید و تنظیم اطلاعاتی مانند تاریخ صدور کوکی، تاریخ انقضای آن، نوع کوکی، مانند ماندگار بودن یا امن بودن (HTTPS) و امثال آن است. حاصل این مراحله، تولید یک AuthenticationTicket است.
5- در آخر، AuthenticationTicket و ClaimsPrincipal به کلاس SecureDataFormat، برای ابتدا، serialize شدن اشیاء، رمزنگاری و در نهایت تبدیل آن‌ها به فرمت base64، ارسال می‌شوند.

جزئیات تکمیلی مرحله‌ی آخر آن نیز به این ترتیب است:
AuthenticationTicket با استفاده از کلاس TicketSerializer سریالایز می‌شود. پس از آن یک memory stream تشکیل شده و اطلاعات ClaimsIdentity و AuthenticationTicket سریالایز شده به آن ارسال می‌شوند. این memory stream با استفاده از الگوریتم GZip فشرده شده و برای پردازش بیشتر بازگشت داده می‌شود. مرحله‌ی بعد، رمزنگاری اطلاعات فشرده سازی شده‌است. برای این منظور از کلاس DpapiDataProtector دات نت استفاده می‌کنند. پس از رمزنگاری، استریم نهایی با فرمت base64 برای درج در HTTP Response آماده خواهد شد.

سؤال: چرا کوکی‌‌های یک کاربر معین لاگین شده‌ی توسط ASP.NET Identity، در مرورگرهای مختلف متفاوت است؟
هرچند اطلاعاتی مانند ApplicationUser.Id و SecurityStamp برای یک کاربر، در مرورگرهای مختلف یکسان هستند، اما در مرحله‌ی چهارم، ذکر شد که AuthenticationTicket دارای اطلاعات بیشتری مانند زمان تولید کوکی نیز هست. بنابراین اطلاعات نهایی رمزنگاری شده‌ی در این حالت که در زمان‌های مختلفی تولید شده‌اند، یکسان نخواهند بود.

سؤال: در ساب دومین‌های مختلف دومین مشخصی، چندین برنامه‌ی مختلف نصب شده‌اند. چگونه می‌توان از یک سیستم لاگین ASP.NET Identity برای تمام آن‌ها استفاده کرد؟
برای این منظور نیاز هست خاصیت CookieDomain را به صورت صریح مقدار دهی کرد. برای اینکار فایل Startup.Auth.cs را گشوده و CookieAuthenticationOptions را تنظیم کنید:

var cookieAuthenticationOptions = new CookieAuthenticationOptions
{
    AuthenticationType  = DefaultAuthenticationTypes.ApplicationCookie,
    LoginPath           = new PathString("/Account/Login"),
    CookieDomain        = ".mydomain.com"
};

البته کار به همینجا ختم نمی‌شود. پس از آن نیاز است به ازای تمام دومین‌های موجود، یک machine key مشخص تنظیم شود. از این جهت که در مرحله‌ی پنجم تولید کوکی، کلاس DpapiDataProtector دات نت، از machine key موجود، برای رمزنگاری اطلاعات استفاده می‌کند و اگر این machine key، به ازای برنامه‌های مختلف متفاوت باشد، کوکی تولید شده، قابل رمزگشایی و استفاده نخواهد بود.
برای اینکار به کنسول IIS مراجعه کرده و گزینه‌ی machine key آن‌را بیابید. در این قسمت بر روی generate keys کلیک کرده و اطلاعات تولیدی را باید به تمام web.config‌های موجود کپی کنید:

 <machineKey
  validationKey="DAD9E2B0F9..."
  decryptionKey="ADD1C39C02..."
  validation="SHA1"
  decryption="AES"
/>

سؤال: برنامه‌های مختلفی بر روی یک دومین نصب هستند، اما قصد نداریم از سیستم اعتبارسنجی یکپارچه‌ای برای تمام آن‌ها استفاده کنیم. اما اگر در یکی لاگین کنیم، بلافاصله لاگین در برنامه‌ی دوم منقضی می‌شود، چرا؟
شبیه به همین مساله با Forms Authentication هم وجود دارد. برای رفع آن باید نام کوکی‌های هر برنامه را منحصربفرد کنید و از نام پیش فرض کوکی‌ها استفاده نکنید تا بر روی یکدیگر بازنویسی نشوند. برای اینکار خاصیت CookieName شیء CookieAuthenticationOptions را جداگانه مقدار دهی کنید:

 CookieName = "my-very-own-cookie-name"

سؤال: لاگین انجام شده‌ی در برنامه‌ای که از ASP.NET Identity استفاده می‌کند، زود منقضی می‌شود؛ چرا؟
برای تنظیم صریح زمان انقضای کوکی ASP.NET Identity نیاز است خاصیت ExpireTimeSpan آن‌را مقدار دهی کنید:

 app.UseCookieAuthentication(new CookieAuthenticationOptions
{
     ExpireTimeSpan = TimeSpan.FromHours(24.0),
});

سؤال: کاربر سیستم ASP.NET Identity از سیستم خارج شده‌است (log off کرده) ولی هنوز می‌توان از کوکی پیشین او برای اعتبارسنجی مجدد استفاده کرد. چطور می‌توان این نقیصه‌ی امنیتی را برطرف کرد؟
مشکل از اینجا است:

   public ActionResult LogOff()
  {
      AuthenticationManager.SignOut();
      return RedirectToAction("Index", "Home");
  }

در مثال رسمی ASP.NET Identity یک چنین کدی برای خروج از سیستم ارائه شده‌است. نمونه‌ی امن‌تر آن به صورت زیر است:

[HttpPost]
[ValidateAntiForgeryToken]
public async Task<ActionResult> LogOff()
{
    var user = await UserManager.FindByNameAsync(User.Identity.Name);
    AuthenticationManager.SignOut(DefaultAuthenticationTypes.ApplicationCookie);
    await UserManager.UpdateSecurityStampAsync(user.Id);
    return RedirectToAction("Login", "Account");
}

در اینجا علاوه بر عدم استفاده‌ی از متد بدون پارامتر SignOut (با توجه به خاصیت AuthenticationType ذکر شده‌ی در CookieAuthenticationOptions)، کار به روز رسانی مجدد SecurityStamp کوکی نیز انجام شده‌است. با این تغییر، کوکی موجود بلا استفاده خواهد شد؛ چون دیگر قابل رمزگشایی نیست.
همچنین بهتر است مقدار validateInterval مربوط به SecurityStampValidator.OnValidateIdentity که به صورت پیش فرض 30 دقیقه است را به مقدار کمتری مانند 5 دقیقه تغییر دهید (تنظیمات OnValidateIdentity مربوط به CookieAuthenticationOptions فایل آغارین برنامه). کار این تنظیم، بررسی اعتبار کوکی، در بازه‌های زمانی مشخص شده‌است.

‫۸ سال و ۱۰ ماه قبل، سه‌شنبه ۱۷ آذر ۱۳۹۴، ساعت ۱۱:۳۵

مجید بصیرتی

مطالب

تنظیمات مدت زمان اعتبار کاربران در ASP.NET Identity

نکته: در این مقاله کلمه "بازه زمانی" معادل Interval می‌باشد.

اگر از سیستم احراز هویت از طریق کوکی در asp.net Identity 2.1 استفاده می‌کنید، دو تنظیم برای بررسی پایان یافتن اعتبار کاربر وجود دارد که در نگاه اول، هیچ تفاوتی باهم نداشته و شبیه به هم به نظر می‌رسند: ValidateInterval و ExpireTimeSpan

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
    AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
    LoginPath = new PathString("/Account/Login"),
    Provider = new CookieAuthenticationProvider
    {
        OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, ApplicationUser>(
            validateInterval: TimeSpan.FromMinutes(15),
            regenerateIdentity: (manager, user) => user.GenerateUserIdentityAsync(manager)),
    },
    SlidingExpiration = false,
    ExpireTimeSpan = TimeSpan.FromMinutes(30)
});

ExpireTimeSpan

CookieAuthenticationOptions.ExpireTimeSpan یک خصیصه است که به شما اجازه می‌دهد تا مدت زمان اعتبار کوکی ساخته شده توسط Identity را مشخص کنید. در مثال بالا، کوکی به مدت 30 دقیقه از زمان ایجاد آن، معتبر است. هنگامی که این 30 دقیقه به پایان برسد، کاربر باید مجددا لاگین کند، چون SlidingExpiration به false تنظیم شده است.

اگر SlidingExpiration مقدار true داشته باشد، کوکی بعد از هر درخواستی که پس از گذشت بیش از نیمی از مدت زمان مشخص شده در ExpireTimeSpan ارسال شود، مجددا ایجاد خواهد شد. برای مثال در اینجا (با توجه قطعه به کد بالا) اگر کاربر login شود و درخواست بعدی را پس از گذشت 16 دقیقه ارسال کند، کوکی به مدت 30 دقیقه دیگر معتبر خواهد شد. اما اگر کاربر پس از لاگین، در خواست بعدی را 31 دقیقه بعد ارسال کند، باید مجددا عمل لاگین را انجام دهد.

بازه زمانی اعتبارسنجی SecurityStampValidator

ValidateInterval از تابع SecurityStampValidator.OnValidateIdentity، فیلد SecurityStamp را بعد از گذشت یک بازه زمانی بررسی می‌کند تا از اعتبار کوکی اطمینان حاصل شود. این همان بررسی منقضی شدن کوکی نیست، اگرچه می‌تواند سبب همان عملکرد و یا لاگ آوت کاربر شود.

Security Stamp هربار که رمز عبور ایجاد یا عوض شود و یا یک لاگین خارجی (External Login) ایجاد یا حذف شود، به روز می‌شود. اگر کاربر رمز عبورش را تغییر دهد این فیلد تغییر خواهد کرد و این تغییر باعث می‌شود که در بررسی مجدد این فیلد پس از مدت زمان مشخص شده در ValidateInterval، کوکی نامعتبر شناخته شود و کاربر را مجبور به لاگین مجدد کند.

نکته: در صورتی که بخواهید به صورت دستی مقدار این فیلد را تغییر دهید می‌توانید از کد زیر استفاده کنید:

UserManager.UpdateSecurityStampAsync(userId);

برای درک بهتر مثال زیر را در نظر بگیرید:

کاربر در مکان A لاگین می‌شود.
همان کاربر مکان خود را تغییر داده و ده دقیقه بعد در مکان B لاگین می‌شود.
کاربر رمزعبورش را در مکان B در دقیقه 12ام تغییر می‌دهد.
کاربر به مکان A برمی گردد و یک درخواست را در دقیقه 20ام ارسال می‌کند.
چون کاربر یک درخواست را بعد از مدت زمان مشخص شده در ValidateInterval (یعنی 15 دقیقه) در مکان A ارسال می‌کند، پس عملیات چک کردن فیلد SecurityStamp انجام می‌شود و از آنجایی که این فیلد به علت تغییر رمز عبور، به روز شده است، بنابراین کاربر لاگ آوت خواهد شد.

دلیل لاگ آوت شدن کاربر در این سناریو، با حالتی که کوکی منقضی می‌شود تفاوت دارد، چون مدت زمان انقضای کوکی یعنی 30 دقیقه (در این مثال) هرگز نمی‌رسد. درعین حال کاربر لاگ آوت می‌شود چون مقدار validateInterval بر روی 15 دقیقه تنظیم شده است.

تفاوت این دو چیست؟

تفاوت دو حالت در نگاه اول خیلی ظریف است اما این تفاوت مزایای بزرگی فراهم می‌کند، مانند لاگ آوت کردن از هر مکان. اما این ویژگی می‌تواند گیج کننده هم باشد از آنجا که الگوی پیش فرض ASP.NET Identity فقط validateInterval را دارد و ExpireTimeSpan به طور صریح ذکر نشده و مقدار پیش فرض آن روی 14 روز تنظیم شده است.

منبع

‫۸ سال و ۳ ماه قبل، شنبه ۹ مرداد ۱۳۹۵، ساعت ۲۰:۲۵