ابتدا سامانه را دریافت می کنیم و سپس آن را در مسیر مشخص استخراج می کنیم  حالا باید در sql server ، پایگاه داده مربوط به سامانه را ایجاد کرد برای این کار می توانید از لینک زیر BackUp تهییه شده از دنلود کنیم و آن را بر روی پایگاه داده Restore ، Sql server کنیم ---- پایگاه داده خالی را از حالت فشرده خارج می کنیم  ---- سپس باید پایگاه داده در sql server که می خواهیم سامانه را بر روی آن نصب کنیم restore کنیم  پس از restore کردن باید تمام جدول های مربوط به سامانه نمایش داده شود ---- در internet information service باید تنظیمات مربوط به اضافه کردن سامانه را انجام داد  در قسمت physical path باید آدرس پوشه مربوط به فایل های سامانه را انتخاب کرد تا در محتوا اضافه شود ---- در مرحله بعد باید در فایل web.config تنظمات اتصال به پایگاه داده را انجام داد برای این کار باید به پوشه سانامانه مراجعه کنید و سپس web.config را باز کنید  اگر می خواهید هم زمان چند کاربر با یک نام کاربری در سامانه وارد شوند باید SessionMultiple را برار با True قرار دهید ```yaml key="SessionMultiple" value="true ``` ----- برای اتصال پایگاه داده به بانک اطلاعاتی باید ConnectionString مورد نظر در این قسمت درج شود  **نمونه ConnectionString :** ```yaml ``` ```yml Data Source : آدرس سرور پایگاه داده Initial Catalog : نام پایگاه داده user id : شناسه password : رمز عبور ``` -----  بعد از ویرایش و ذخبره کردن web.config باید اسکریپ ها مربوط به نسخه همان سامانه در در بانک اطلاعاتی ایجاد شده اجرا شود > توجه داشته باشید که باید نسخه سورس پروژه با نسخه اسکریپ یکسان باشد {.is-warning} > نسخه هر اسکریت در اول کد های آن درج شده و نام فایل اسکریت شامل نسخه اسکریت است {.is-info} > اسکریپت های مروبط به سامانه در سورس کد پروژه و در شاخه SQLScript قرار دارد {.is-info}  ---- در internet information service و در قسمت permission فایل های سامانه باید جهت آپلود فایل ها و عکس کاربران سامانه ، اخبار ، گالری دسترسی را مطابق مراحل زیر اضافه نمود ابتدا باید بر روی Edite Permission کلیک کرد  سپس باید در قسمت Security و در Group or UserNames مجوز های Full control و Modify را داد   ---- در قسمت Manage Website باید Browes را انتخاب کنید تا وارد سامانه شوید 

ابتدا سامانه را از طریق internet information service متوقف می کنیم  پس از دریافت نسخه جدید سامانه باید آن را بر روی سرور و یا سیستم مد نظر خود بارگذاری کنیم و سپس وارد پوشه نسخه قدیمی سامانه بشویم برای اطمینان از محل پوشه نسخه قدیمی سامانه می توانیم از قسمت explore وارد آن شویم   برای بروز کردن سامانه باید پوشه های bin , content , Mobile_PWA و فایل های notification-sw , service-worker و Web.Config ر از نسخه جدید جایگزین نسخه قدیمی کرد > قبل از جایگزین کردن web.config بهتر است نسخه قدیمی را تغییر نام داد تا اطلاعات connection string را از نسخه قدیمی به نسخه جدید منتقل کنیم {.is-warning}   پس از جایگزین کردن فایل ها باید connection string را از web.config نسخه قدیمی در نسخه جدید کپی کرد  **نمونه ConnectionString :** ```yaml ``` > در نسخه های جدید سامانه باید در ConnectionString عبارت MultipleActiveResultSets=True باشد {.is-info} ```yaml Data Source : آدرس سرور پایگاه داده Initial Catalog : نام پایگاه داده user id : شناسه password : رمز عبور ``` سپس باید کوئری که در پوشه sql script نسخه جدید می باشد را اجرا کرد  باید دقت داشته باشید که در قسمت message نباید خطایی باشد  > توجه داشته باشید که باید نسخه سورس پروژه با نسخه اسکریپ یکسان باشد {.is-warning} > نسخه هر اسکریت در اول کد های آن درج شده و نام فایل اسکریت شامل نسخه اسکریت است {.is-info} > اسکریپت های مروبط به سامانه در سورس کد پروژه و در شاخه SQLScript قرار دارد {.is-info} پس از اجرای کوئری ها می توانید سامانه را start کنید 

با توجه به اینکه Copression در سامانه های گراف راه اندازی شده است شما می توانید برای فعال سازی این قابلیت باید وارد iis شده  بر روی Compression کلیک کنید  و مطابق عکس بالا مقادیر را برای compression تنظیم کنید

new asynchronous pipeline / Needed for WebSocket And Signal /if false it can make deadlock ```xml ``` BPMS Core File Version / can be used in release versioning ```xml ``` Used By Active Query Builder ```xml ``` Used By Active Query Builder ```xml ``` Used By Active Query Builder / Enables or disables compression of HTTP traffic between clent and server. ```xml ``` Used by razor Engine / Upgrade from MVC 4 to 5 -> 2.0.0.0.0 to 3.0.0.0 ```xml ``` When WebMatrix.WebData.dll is included in in the /bin directory of an ASP.NET MVC 4 apps, it takes over the URL for forms authentication. Adding the WebMatrix.WebData.dll assembly to your application (for example,by selecting "ASP.NET Web Pages with Razor Syntax" when using the Add Deployable Dependencies dialog) will override the authentication login redirect to /account/logon rather than /account/login as expected by the default ASP.NET MVC Account Controller.To prevent this behavior and use the URL specified already in the authentication section of web.config, you can add an appSetting called PreserveLoginUrl and set it to true ```xml ``` MVC3 & MVC4 supports unobtrusive client-side validation. In which validation rules are defined using attributes added to the generated HTML elements. These rules are interpreted by the included JavaScript library and uses the attribute values to configure the jQuery Validation library which does the actual validation work. In this article, I would like to demonstrate various ways for enabling or disabling the client side validation.We can enable and disable the client-side validation by setting the values of ClientValidationEnabled & UnobtrusiveJavaScriptEnabled keys true or false. This setting will be applied to application level. ```xml ``` This is a configuration setting used in OWIN (Open Web Interface for .NET) self-hosted applications. It controls how OWIN discovers the startup class responsible for initializing your application. Here's a breakdown of what it does: Value: This setting can be either "true" (default) or "false". True (default): Enables automatic discovery. OWIN will search for a class with the OwinStartup attribute in your assemblies. This class will be used to configure your application pipeline. False: Disables automatic discovery. You need to manually specify the startup class using another setting named owin:AppStartup. Use Cases: Automatic Discovery (owin:AutomaticAppStartup = true): This is the recommended approach for most scenarios. It simplifies configuration, especially for projects with a single startup class. Manual Configuration (owin:AutomaticAppStartup = false): You might use this approach in these situations: You have multiple startup classes for different environments (e.g., development, staging, production). You need more control over startup class discovery or use a custom mechanism. Your project structure doesn't follow the typical convention where OWIN expects to find the startup class. ```xml ``` Purpose: Limits the complexity of incoming JSON data to prevent potential Denial-of-Service (DoS) attacks and improve performance. Value: This setting takes an integer value representing the maximum number of key-value pairs allowed in the JSON being deserialized. Default: By default, ASP.NET restricts JSON deserialization to 1,000 members due to security concerns. How it Works: When your ASP.NET application receives a JSON request, the framework attempts to deserialize it into usable data structures. The aspnet:MaxJsonDeserializerMembers setting defines a threshold on the number of members allowed during this process. If the JSON payload exceeds this limit, the deserialization fails, and the application typically throws an exception. Use Cases: Security: Limiting the complexity of JSON data helps mitigate DoS attacks where attackers send excessively large or nested JSON requests to overwhelm the server's resources. Performance: Deserializing very large JSON structures can be resource-intensive. This setting can help prevent performance degradation caused by complex JSON payloads. ```xml ``` System Temp Files Path ```xml ``` System Users Files Path ```xml ``` System News Files Path ```xml ``` System News ImageGallery File Path ```xml ``` System DynamicPage File Path ```xml ``` Enables Archive File Encryption ```xml ``` Deny List of File type for upload ```xml ``` حداکثر تعداد رکورد ذخیره لاگ در جدول SystemLog ```xml ``` SaveSelectLog true/false => true means Insert Log For Start And End Controller ```xml ``` ذخیر لاگ Qeury های Select ```xml ``` ذخیره لاگ Query های Insert ```xml ``` ذخیره لاگ Query های Update ```xml ``` ذخیره لاگ Query های Delete ```xml ``` ShouldLogAgent true/false => true means Insert Log For User Browser Agent ```xml ``` مشخص کردن وضعیت ذخیره لاگ های سرویس Provider درجدول dbo.Provider ```xml ``` قابلیت ورود همزمان چند کاربر با یک نام کاربری و رمز عبور در سامانه ```xml ``` Token Lifetime In Minutes ```xml ``` Ajax Script TimeOut ```xml ``` WebApi Request TimeOut ```xml ``` نمایش Captcha در زمان ورود به سامانه ```xml ``` If SSL not configured on IIS, set false for UseSecureCookie flag ```xml ``` aspnet:MaxJsonLength is a configuration setting used in ASP.NET applications to control the maximum allowed size of JSON data that can be processed. Here's a breakdown of its functionality: Purpose: Limits the size of incoming JSON requests or responses to prevent potential Denial-of-Service (DoS) attacks and improve performance.Protects your application from being overwhelmed by excessively large JSON payloads. Value:This setting takes an integer value representing the maximum number of characters allowed in the JSON string. The default value varies depending on the ASP.NET version: ASP.NET MVC 4 and below: Default is 102,400 characters (approximately 100 KB). ASP.NET MVC 5 and above: Default is 2,097,152 characters (approximately 2 MB). How it Works:When your ASP.NET application receives or sends JSON data, the framework serializes or deserializes it for processing. aspnet:MaxJsonLength defines a threshold on the size of the JSON string allowed during this process. If the JSON data exceeds this limit, the serialization or deserialization fails, typically throwing an exception. Use Cases: Security: Restricts DoS attacks where attackers send very large JSON requests to crash the server. Performance: Processing massive JSON payloads can be resource-intensive. This setting prevents performance degradation caused by excessively large JSON data. ```xml ``` Avoid Conflict with out Auth / Avoid Request redirect to /Account/Login?ReturnUrl=%2f (Should be False) ```xml ``` Disabled to avoid using Microsoft SimpleMembership(we are using ASP.NET Identity) ```xml ``` Disabled to avoid using Microsoft SimpleMembership(we are using ASP.NET Identity) ```xml ``` حد محدودیت درخواست های هر کاربر بر حسب ثانیه مقدار پیشفرض 0.1 است به این معنی که هر کاربر می تواند در 0.1 ثانیه یک درخواست ارسال کند ```xml ``` فعال یا غیر فعال کردن سرویس تایمر ```xml ``` با توجه به گزینه های موجود میتوانید سطح امنیت کلمه عبور کاربر در زمان ساخت اکانت را مشخص کنید. Blank:رمز عبور خالی(فقط خالی و/یا فاصله) VeryWeak:یا خیلی کوتاه(کمتر از5حرف)، فقط حروف یک حالته یا فقط اعداد Weak:حداقل8حرف، یک شرط قوی برآورده شده است(حداقل8حرف با1یا بیشتر حروف بزرگ، حروف کوچک، اعداد و کاراکترهای خاص) Medium:حداقل8حرف، دو شرط قوی برآورده شده است(حداقل8حرف با1یا بیشتر حروف بزرگ، حروف کوچک، اعداد و کاراکترهای خاص) Strong:حداقل8حرف، سه شرط قوی برآورده شده است(حداقل8حرف با1یا بیشتر حروف بزرگ، حروف کوچک، اعداد و کاراکترهای خاص) VeryStrong:حداقل16حرف، تمام شرایط قوی برآورده شده است(حداقل8حرف با1یا بیشتر حروف بزرگ، حروف کوچک، اعدادو کاراکترهای خاص) ```xml ``` قابلیت استفاده از Script Task C# در طراحی فرآیند اگر در فرآیند Script Task C# استفاده کرده باشید ، غیر فعال کردن این ویژگی باعث می شود که از Script Task رد شود ```xml ``` Maximum allowed execution time to second ```xml ``` Maximum allowed number of statement in script ```xml ``` Let you use full or minify version of bundle ```xml ``` SSO Tehran ```xml ``` SSO Tehran ```xml ``` SSO Tehran ```xml ``` SSO Tehran ```xml ``` SSO Tehran ```xml ``` These settings can be set in IIS configs too In case you are using shared host or don't have access to IIS , You can set these setting here The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>,<iframe>, <embed> or <object>. Sites can use this to avoid click-jacking attacks, by ensuring that their content is not embedded into other sites. DENY => The page cannot be displayed in a frame, regardless of the site attempting to do so.SAMEORIGIN => The page can only be displayed if all ancestor frames are same origin to the page itself.(AFTA) ```xml ``` The HTTP X-XSS-Protection response header is a feature of Internet Explorer,Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. These protections are largely unnecessary in modern browsers when sites implement a strong Content-Security-Policy that disables the use of inline JavaScript ('unsafe-inline').(AFTA) 0 => Disables XSS filtering. 1 => Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts). 1; mode=block => Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.1; report=<reporting-uri> => (Chromium only) Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report. ```xml ``` applied to them by default. This restricts the sources from which they can load code such as <script> and disallows potentially unsafe practices such as using eval(). This article briefly explains what a CSP is, what the default policy is and what it means for an extension, and how an extension can change the default CSP. Under the default CSP, you can only load code that is local to the extension. The CSP limits script-src to secure sources only, which covers <script> resources, ES6 modules and web workers. In browsers that support obsolete plugins, the object-src directive is also restricted. For more information on object-src in extensions, see the WECG issue Remove object-src from the CSP (at least in MV3)). default : "script-src 'self'; object-src 'self';" default manifest V3 : "script-src 'self'; upgrade-insecure-requests;" Manifest V2 syntax : "content_security_policy": "default-src 'self'" Manifest V3 syntax : "extension_pages : 'self' 'none' 'wasm-unsafe-eval'" Manifest V2 syntax : "content_security_policy": "script-src 'self' https://graphbpms.com; object-src 'self'" Manifest V3 syntax : Manifest V3 does not allow remote URLs in script-src of extension_pages. Manifest V2 syntax : "content_security_policy": "script-src 'self' 'unsafe-eval'; object-src 'self';" Manifest V3 syntax : Manifest V3 does not allow 'unsafe-eval' in script-src. Manifest V2 syntax : Content-Security-Policy: img-src 'none' When you encounter the none keyword in a Content-Security-Policy header directive it means that no resources are allowed to load. object-src specifies the URLs from which plugins can be loaded from. The object-src directive may be required in some browsers that support obsolete plugins and should be set to a secure source such as 'none' if needed. This may be necessary for browsers up until 2022. child-src => allows the developer to control nested browsing contexts and worker execution contexts. connect-src => provides control over fetch requests, XHR, eventsource, beacon and websockets connections. font-src => specifies which URLs to load fonts from. ```xml ``` The Referrer-Policy HTTP header controls how much referrer information (sent with the Referer header) should be included with requests. Aside from the HTTP header, you can set this policy in HTML. no-referrer => The Referer header will be omitted: sent requests do not include any referrer information. no-referrer-when-downgrade => Send the origin, path, and querystring in Referer when the protocol security level stays the same or improves (HTTP→HTTP, HTTP→HTTPS, HTTPS→HTTPS). Don't send the Referer header for requests to less secure destinations (HTTPS→HTTP, HTTPS→file). origin => Send only the origin in the Referer header. For example, a document at https://example.com/page.html will send the referrer https://example.com/. origin-when-cross-origin => When performing a same-origin request to the same protocol level (HTTP→HTTP, HTTPS→HTTPS), send the origin, path, and query string. Send only the origin for cross origin requests and requests to less secure destinations (HTTPS→HTTP). same-origin => Send the origin, path, and query string for same-origin requests. Don't send the Referer header for cross-origin requests. strict-origin => Send only the origin when the protocol security level stays the same (HTTPS→HTTPS). Don't send the Referer header to less secure destinations (HTTPS→HTTP). strict-origin-when-cross-origin (default) => Send the origin, path, and querystring when performing a same-origin request. For cross-origin requests send the origin (only) when the protocol security level stays same (HTTPS→HTTPS). Don't send the Referer header to less secure destinations (HTTPS→HTTP). Note: This is the default policy if no policy is specified, or if the provided value is invalid (see spec revision November 2020). Previously the default was no-referrer-when-downgrade. unsafe-url => Send the origin, path, and query string when performing any request, regardless of security. ```xml ``` The X-Content-Type-Options response HTTP header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should be followed and not be changed. The header allows you to avoid MIME type sniffing by saying that the MIME types are deliberately configured. nosniff => Blocks a request if the request destination is of type style and the MIME type is not text/css, or of type script and the MIME type is not a JavaScript MIME type. ```xml ``` Avoid user to logout in case of browser closed ```xml ``` Logging Notification ```xml ``` Path Of Android SDK ```xml ``` aspnet:RequestQueueLimitPerSession is a configuration setting in ASP.NET applications that controls the maximum number of concurrent requests allowed per user session. Here's a breakdown of what it does: Purpose: This setting prevents overwhelming the server with too many requests from a single user at once. It helps manage server resources and improves overall application performance. Value: This setting takes an integer value representing the maximum number of queued requests allowed per session. Default Value: The default value depends on the ASP.NET version: ASP.NET 4.6.2 and earlier: No limit by default (potentially unlimited queuing). ASP.NET 4.7 and above: Default is 50. How it Works: In ASP.NET, requests from the same user session are typically processed sequentially due to session state management. aspnet:RequestQueueLimitPerSession introduces a limit on how many requests can queue up waiting for processing within a single session. If the number of queued requests reaches the limit, subsequent requests from the same session are rejected, and an error might be logged or returned to the user. Use Cases: Performance: Prevents a single user from overloading the server with too many concurrent requests, improving overall application responsiveness. Stability: Protects the server from Denial-of-Service (DoS) attacks where attackers bombard the server with excessive requests from a single source (potentially spoofed to appear like a single user session). ```xml ``` LogVerbosityLevel: 1- just show "Error" 2- show last Exception message 3- show stacktrace ```xml ``` Acceptable List of device for browsing website ```xml ``` lock users to single login ```xml ``` for cached items. Here's a breakdown of how it works: Cache: A temporary storage mechanism used to store frequently accessed data for faster retrieval. Cache Expiration: The concept of data in the cache becoming invalid or stale after a certain period. This helps ensure the retrieved data is up-to-date. Sliding Expiration: A specific type of cache expiration strategy based on item access. Here's how it works: When a cached item is accessed (read), the expiration timer is reset. The item remains valid for a predefined duration (specified by CacheSlidingExpirationInterval) after the last access. If the item is not accessed within the CacheSlidingExpirationInterval, it is automatically removed from the cache. Contrast with Absolute Expiration: There's another common expiration strategy called Absolute Expiration. Here, the cached item becomes invalid at a specific predefined time regardless of access. Benefits of Sliding Expiration: Keeps frequently accessed data fresh: Items actively used are automatically renewed, ensuring access to the latest data. Efficient memory usage: Items not accessed for a period are removed, freeing up cache space for other data. CacheSlidingExpirationInterval: This property defines the duration for which a cached item remains valid after the last access. It's typically set in milliseconds, seconds, or minutes. Example: You set CacheSlidingExpirationInterval to 60 seconds (1 minute). If a cached item is accessed, its expiration timer restarts. The item remains valid for another 60 seconds from that point of access. If the item is not accessed again within 60 seconds, it's automatically removed from the cache. Using CacheSlidingExpirationInterval: The specific way to use CacheSlidingExpirationInterval depends on the caching library or framework you're using. Here are some general steps: Get a reference to the cache object. Add or retrieve an item from the cache. ```xml ``` CacheAbsoluteExpirationInterval complements CacheSlidingExpirationInterval by providing another approach to managing cache item expiration in caching libraries and frameworks. Here's a breakdown of the key differences: CacheAbsoluteExpirationInterval: Defines a fixed expiration time for a cached item. The item becomes invalid at a predefined point in time, regardless of whether it's accessed or not. Comparison with CacheSlidingExpirationInterval: FeatureCacheSlidingExpirationIntervalCacheAbsoluteExpirationInterval Expiration TypeSlidingAbsolute Depends onItem accessPredefined time Use caseFrequently accessed data that needs to be fresh (updates periodically)Data with a well-defined lifespan (e.g., news articles with a set expiration time) Example: You set CacheAbsoluteExpirationInterval to 3 hours. A cached item added at 10:00 AM will automatically become invalid and removed from the cache at 1:00 PM, even if it's accessed multiple times within that timeframe. Using CacheAbsoluteExpirationInterval: Similar to CacheSlidingExpirationInterval, the specific way to use it depends on the caching library. Generally, you'll: Get a reference to the cache object. Add or retrieve an item from the cache. Set the CacheAbsoluteExpirationInterval property on the cache item or during the retrieval process (depending on the library). Choosing the Right Strategy: Use CacheSlidingExpirationInterval for data that needs to be fresh and updates periodically. It ensures the retrieved data reflects recent changes as long as it's accessed regularly. Use CacheAbsoluteExpirationInterval for data with a well-defined lifespan that becomes stale after a certain period, regardless of access frequency. This is useful for content with expiration dates or information that changes infrequently. In summary, both CacheSlidingExpirationInterval and CacheAbsoluteExpirationInterval offer valuable tools for managing cache expiration. Choose the appropriate strategy based on your data's characteristics and how it's used within your application. ```xml ``` Limit Provider ```xml ```