I found out that we have this kind of configuration
var redis = ConnectionMultiplexer.Connect(configuration["Redis:Configuration"]); var dataProtectionBuilder = context.Services.AddDataProtection().SetApplicationName("ABC"); dataProtectionBuilder.PersistKeysToStackExchangeRedis(redis, "ABC-Protection-Keys");
I can see two different options to discriminate the data between the deployment stages: either define the stage in application name or Redis key name ( ABC-Protection-Keys). The question is which should we use and should we set different application names for the identity server and the web application?
How should the Redis cache be configured between different instances of the application? We have planned to use four deployment stages (UAT, QA, Canary Production and Production). Can we share the Redis cache server between some of the stages or will there be a problem of data mixing between the stages?
Actually, I have now tested this and at least the redirect URL configuration gets mixed up between the stages. Is there a way to define instance-specific key through configuration so the values won't mix up in the cache?
Ahh, I missed that it was related to tawk to integration which we have used in our application. Thank you for your answer!
Hello, we are deploying our project build on top of ABP to Azure. After the deployment, we found that some of the requests are blocked by the OWASP scanner in the Azure Application Gateway Firewall. The first block comes from the authentication call:
requestUri_s /connect/authorize?response_type=code\u0026client_id=OUR_APP_App\u0026state=UXB5Zmh6VWFST3BLVUZTbXVkdEt3dWpfdWF3dy56XzFFMDNyNURESlFRQnNi\u0026redirect_uri=https%3A%2F%2FOUR_APP-qa.lw.app\u0026scope=offline_access%20openid%20profile%20role%20email%20phone%20OUR_APP\u0026code_challenge=JG1J3rF5kFDd-kQNWu5Bi7ji-zOCKWuJ4b_zK0yADjA\u0026code_challenge_method=S256\u0026nonce=UXB5Zmh6VWFST3BLVUZTbXVkdEt3dWpfdWF3dy56XzFFMDNyNURESlFRQnNi\u0026culture=en\u0026ui-culture=en
Message Detects basic SQL authentication bypass attempts 3/3
ruleSetVersion_s 3.2
ruleGroup_s REQUEST-942-APPLICATION-ATTACK-SQLI
details_message_s
Pattern match (?i:(?:["'](?:\\s*?(?:is\\s*?(?:[\\d.]+\\s*?\\W.*?[\"'
]|\d.+["']?\\w)|\\d\\s*?(?:--|#))|(?:\\W+[\\w+-]+\\s*?=\\s*?\\d\\W+|\\|?[\\w-]{3,}[^\\w\\s.,]+)[\"'
]|[\%\u0026\u003c\u003e^=]+\d\s*?(?:between|like|x?or|and|div|=))|(?i:n?and|x?x?or|div|like|between|not|\|\||\\u0026\\u0026)\s+[\s\w+]+(?:sounds\s+like\s*?["'`]|regexp\s*?\(|[=\d]+x)|in\s*?\(+\s*?select)) at REQUEST_COOKIES.
details_data_s Matched Data: "uuid":" found within REQUEST_COOKIES:twk_uuid_6272619db0d10b6f3e709056: %7B%22uuid%22%3A%221.DECWNFunxcnpgYWrV82YSGHozzios3WMXMuV6utignc1kwKN9BEe3TVjnjGCKBM2TCtxVLGqUFfGNaX8VCZSQkz0Wb2xdIjkmk7pyyl343KA437h7YKdoYt6PKa2VEcY8hVOatTY%22%2C%22version%22%3A3%2C%22domain%22%3A%22lw.app%22%2C%22ts%22%3A1653031469585%7D
details_file_s REQUEST-942-APPLICATION-ATTACK-SQLI.conf
If we disable that rule, we encounter a couple of similar blocks where the pattern matching founds illegal characters in the request cookies: requestUri_s /api/app/***
Message SQL Comment Sequence Detected.
ruleSetVersion_s 3.2
ruleGroup_s REQUEST-942-APPLICATION-ATTACK-SQLI
details_message_s Pattern match (?:/\!?|\/|[';]--|--[\s\r\n\v\f]|--[^-]?-|[^\u0026-]#.?[\s\r\n\v\f]|;?\x00) at REQUEST_COOKIES.
details_data_s Matched Data: --F5xL1NDlpZthOfOfsLDkvkV1sMEefcR9Pd3u7i6Ap_m8rZALmz3YaT5tiyGccQvL1jexkpbFic8v_TNqzyp9Ke- found within REQUEST_COOKIES:XSRF-TOKEN: CfDJ8G_9tIpyArtNlo7jZliI7olinWNezAaJOZPmYgGvad_rNtd1Ia9uNi0eqRUNAs7--F5xL1NDlpZthOfOfsLDkvkV1sMEefcR9Pd3u7i6Ap_m8rZALmz3YaT5tiyGccQvL1jexkpbFic8v_TNqzyp9Ke-p2fz-iSA0WigEIeo13N67-TJ3LYX3rphCGyhx_zKSQ
details_file_s REQUEST-942-APPLICATION-ATTACK-SQLI.conf
I know this is only partially or not directly an ABP issue, but I'm looking for information if we can affect the token characters in some way in ABP. I suppose we cannot change the uuid- existence in the authorize call?
Hello, we are planning to use Azure AD as a third-party authentication provider. We have this enabled and working already. I just want to clarify for myself how to prevent users from logging into other tenants' environments. If the user manages to guess another tenant's name on the logging screen, how is it prevented that the user is not able to log in? Where the check should be that this user can only log into a certain tenant environment?
Any ideas for this?
ABP Framework version: v5.1.0
UI type: Angular
DB provider: EF Core
Tiered (MVC) or Identity Server Separated (Angular): yes According to this advice https://support.abp.io/QA/Questions/2284/Concurrency-handling-clarification-question , we now implemented updating concurrency stamp in every update method. However, we now have a problem that the "conflict" return value is not handled correctly in our Angular app. Backend returns 409 as expected. We get an exception page instead of an error dialog telling the user about the error like it was shown in the linked answer. I assumed that of course there is a default handling for conflict type return code, but couldn't find it from the angular source code.
Steps to reproduce the issue:" Add concurrency stamp update to an entities update method in application service, then update the entity concurrently from Angular UI
ABP Framework version: v5.1.1
UI type: Angular
DB provider: EF Core
Tiered (MVC) or Identity Server Separated (Angular): yes
Problem: After the update from 4.3.0, our Angular client is refreshing the token every second. I assume this is not normal. Can we adjust the refresh interval somehow or is there a bug somewhere?
Ok, thanks for your answer. I'm also interested in the longer version of the answer :) In what situations do you see it's ok not to use that method? Suite templates and at least earlier versions of easy CRM do not implement this. Is this a coming change to the templates?