یکی از نرم افزارهای پرکاربرد در بازار
نرم افزار ایران، سیستم حسابداری میباشد. خوب همه ما میدانیم که تعداد
نرم افزارهای حسابداری خیلی زیاد میباشد. کاربران معمولاً نرم افزارهایی
را انتخاب میکنند که بتوانند گزارشهای استاندارد مالی را از آن استخراج
نمایند. یکی از این گزارشها که در واقع یکی از اصلیترین گزارشهای سیستم
حسابداری است، دفتر معین میباشد
اشتراکها
قابلیت Auto-Start برای Web App ها
استفاده از این قابلیت برای برنامه هایی که:
1- نیاز به بارگذاری حجم زیادی از اطلاعات را برای پردازش دارند.
2- پردازش هایی زیادی برای اولین درخواست نیاز دارند.
3- نیاز به جوابدهی سریعی به کاربران دارند.
4 - درون برنامه ، روالهایی با کاربرد دائمی وجود دارند.
5- و...(در ادامه مطلب)
پیشنهاد میشود.
برای استفاده از این قابلیت به iis 7.5 و بالاتر ، همچنین .NET 4 و بالاتر نیاز میباشد.
1- نیاز به بارگذاری حجم زیادی از اطلاعات را برای پردازش دارند.
2- پردازش هایی زیادی برای اولین درخواست نیاز دارند.
3- نیاز به جوابدهی سریعی به کاربران دارند.
4 - درون برنامه ، روالهایی با کاربرد دائمی وجود دارند.
5- و...(در ادامه مطلب)
پیشنهاد میشود.
برای استفاده از این قابلیت به iis 7.5 و بالاتر ، همچنین .NET 4 و بالاتر نیاز میباشد.
با سلام. اگر چندین کاربر یک نقش یکسانی داشته باشند و بخواهیم که یکی از کاربران را به یکی از صفحاتی که در این role هست عدم دسترسی بدهیم به صورتی که نخواهیم یک نقش جدید با policyهای جدید بدهیم در این روش امکان پذیر هست؟ کارفرما روشی را میخواهد که علاوه بر این که بتواند نقشهای مختلفی بر اساس policy تعریف کند یک روشی هم باشد که یک کاربر خاصی را بتواند عدم دسترسی به یک صفحه خاص را بدهد هر چند که قبلا به آن کاربر نقشی را داده باشید که دسترسی به آن صفحه را دارد.
با تشکر
ممنون از پستی که گذاشتید.
فقط یک موردی هست، این سبک پیاده سازی شما فقط برای کاربران لاگین شده قابل استفاده است. در حالی که کاربرانی که از سایت ما دیدن میکنند ممکن است اکثرا لاگین نکرده باشند.
از طرفی پروتکل HTTP، از نوع state-less هست و نمیشه فهمید که درخواستها از یک شخص مشخص دریافت شده اند و جز آمار نیاریم. البته میشه با cookie این مشکل را هم تا حدودی رفع کرد.
در حالت کلی فکر کنم استفاده از SignalR روش بهتری باشه
- مقدار AccessTokenExpirationMinutes را در فایل تنظیمات برنامه تغییر دهید.
- مفهوم refresh token در اینجا شبیه به پیاده سازی sliding expiration برای کوکیها است. اطلاعات بیشتر: «معرفی JSON Web Token» + مثال به روز رسانی خودکار توکن منقضی شده با یک تایمر سمت کلاینت، در سری «احراز هویت و اعتبارسنجی کاربران در برنامههای Angular» عمیقتر بررسی شدهاست.
- پروژهای برای کش کردن نتایج حاصل از کوئریهای EF Core که میتواند سرعت آنها را تا 3 برابر افزایش دهد: « EFSecondLevelCache.Core »
- کش کردن قسمت نمایش لیست کاربران آنلاین و منوهای کنار صفحه در پروژهی DNT Identity.
+ پروژههای SPA، حتما نیاز به ارتباط با سرور را دارند و در این حالت برای گزارشگیریها میتوان از کش سمت سرور و یا پروژهی اولی که نامبرده شد، استفاده کرد.
"asp-validation-summary="ModelOnly را در مطلب «قسمت 14 - فعال سازی اعتبارسنجی ورودیهای کاربران » مطالعه کنید.
@if (ViewData.ModelState.Any(keyValuePair => keyValuePair.Value.Errors.Any())) { <div class="alert alert-danger"> <a href="#" class="close" data-dismiss="alert">×</a> <h4>خطاهای اعتبارسنجی</h4> <div asp-validation-summary="ModelOnly"></div> </div> }
نظرات مطالب
امن سازی برنامههای ASP.NET Core توسط IdentityServer 4x - قسمت هشتم- تعریف سطوح دسترسی پیچیده
با توجه به مفهوم Role Claims که در مطلب Asp.net Core Identity عنوان شد، چگونه میتوان این سطوح دسترسی پویا را با Identity Server پیاده سازی کرد؟ ( منظور پیاده سازی سطوح دسترسی طبق پاراگراف «وقتی کاربری عضو یک نقش است، به صورت خودکار Role Claims آن نقش را نیز به ارث میبرد. هدف از نقشها، گروه بندی کاربران است. توسط Role Claims میتوان مشخص کرد این نقشها چه کارهایی را میتوانند انجام دهند.» است.)
سلام و ضمن تشکر؛ یک سوال داشتم که بیشتر در زمینه کارایی و بهینه سازی سیستم هست. در بخش "پیاده سازی فیلتر سفارشی JwtAuthorizeAttribute " همین مطلب یک قسمت از آن نوشتید "به ازای هر درخواست به سرور، دو بار بررسی بانک اطلاعاتی را خواهیم داشت"
برای اینکه رفت و برگشت برای هر درخواست به بانک اطلاعاتی در پروژههای بزرگ رو مدیریت بهینه کنیم چکار باید کرد؟ منظورم اینه وقتی تعداد کاربران زیاد باشه و متدهای زیادی هم در پروژه باشه که در هدر همه اونها باید این توکن و دسترسیها چک بشه ممکنه سربار زیادی روی بانک اطلاعاتی داشته باشه. برای مدیریت بهتر این موارد من دو راه تست کرده بودم :
1. توی یک متغیر استاتیک اطلاعات توکنها علاوه بر بانک اطلاعاتی ذخیره بشه و هردو با هم سینک باشند (موردی که خودتون هم اشاره فرموده بودید) بنابراین بیشترین درخواستها برای چک این مقادیر روی یک متغیر استاتیک هست که روی IIS فعال میشه و ممکنه رم زیادی البته بگیره و هر وقت هم IIS ریست شد دوباره اون لیست توکنهای استاتیک از بانک اطلاعاتی فراخوانی میشه و برای درخواستهای بعدی کاربران از اون متغیر استاتیک که لیست توکنها هست رو چک میکنه.
2. راه دوم استفاده از بانک اطلاعاتی هست که رفت و برگشت به بانک اطلاعاتی برای هر درخواست رو زیاد میکنه و ممکنه سربار زیادی داشته باشه
البته من در پروژه از بانک اطلاعاتی مونگو استفاده کردم و این لیست توکنها و کلیه بانک اطلاعاتی کاربران و غیره در اون ذخیره میشه .
سوال اینجاست که برای زمانی که کاربران زیاد و متدهای زیادی داریم که باید چک شوند راه حل بهینه برای انجام این مورد چه راهی هست؟
و اینکه آیا اگه از بانک اطلاعاتی Redis که بر روی رم قرار میگیره برای مدیریت توکنها استفاده کنیم کارایی بهتر میشه یا باز هم همون مشکل قبلی رو داریم؟
برای اینکه رفت و برگشت برای هر درخواست به بانک اطلاعاتی در پروژههای بزرگ رو مدیریت بهینه کنیم چکار باید کرد؟ منظورم اینه وقتی تعداد کاربران زیاد باشه و متدهای زیادی هم در پروژه باشه که در هدر همه اونها باید این توکن و دسترسیها چک بشه ممکنه سربار زیادی روی بانک اطلاعاتی داشته باشه. برای مدیریت بهتر این موارد من دو راه تست کرده بودم :
1. توی یک متغیر استاتیک اطلاعات توکنها علاوه بر بانک اطلاعاتی ذخیره بشه و هردو با هم سینک باشند (موردی که خودتون هم اشاره فرموده بودید) بنابراین بیشترین درخواستها برای چک این مقادیر روی یک متغیر استاتیک هست که روی IIS فعال میشه و ممکنه رم زیادی البته بگیره و هر وقت هم IIS ریست شد دوباره اون لیست توکنهای استاتیک از بانک اطلاعاتی فراخوانی میشه و برای درخواستهای بعدی کاربران از اون متغیر استاتیک که لیست توکنها هست رو چک میکنه.
2. راه دوم استفاده از بانک اطلاعاتی هست که رفت و برگشت به بانک اطلاعاتی برای هر درخواست رو زیاد میکنه و ممکنه سربار زیادی داشته باشه
البته من در پروژه از بانک اطلاعاتی مونگو استفاده کردم و این لیست توکنها و کلیه بانک اطلاعاتی کاربران و غیره در اون ذخیره میشه .
سوال اینجاست که برای زمانی که کاربران زیاد و متدهای زیادی داریم که باید چک شوند راه حل بهینه برای انجام این مورد چه راهی هست؟
و اینکه آیا اگه از بانک اطلاعاتی Redis که بر روی رم قرار میگیره برای مدیریت توکنها استفاده کنیم کارایی بهتر میشه یا باز هم همون مشکل قبلی رو داریم؟
- IdentityServer کاری به مباحث چند مستاجری ندارد. هدف آن، قرار ندادن اطلاعات هویت کاربران و منطق احراز هویت آنها، در تک تک برنامههای متفاوت و مختلف یک شرکت است. هدف اصلی آن فراهم آوردن یک سیستم احراز هویت مرکزی برای برنامههایی اساسا متفاوت است.
- زمانیکه جزئیات روش سفارشی سازی سیستمی در اختیار شما قرار گرفت (مانند این پروژه)، منطق چند مستاجری را خودتان به آن اضافه کنید.