Activities of "EngincanV"

What do I do in the meantime? What is the workaround?

Hi, unfortunately there is no workaround that we can provide for now. We have fixed the problem and if you update your LeptonX package versions to 4.0.7, it should fix this problem.

Hi, please ensure that the related file (cregister.js) is an embedded resource (see https://abp.io/docs/9.0/framework/infrastructure/virtual-file-system#embedding-the-files).

The related build action for the file should be embedded resource. (You can right-click to the file and see it's properties and check build-action)

Hi, did you enable the Idle Session Timeout option (https://abp.io/docs/9.1/modules/account/idle-session-timeout)? It seems it might be related to that. Can you confirm if it's enabled for further investigation?

Regards.

Hi, after setting the phone_number in the account manage page, did you logout and then re-login? This is needed to refresh the claims if you are not using dynamic claims.

Can you logout and then re-login and see if the claims are listed as expected?

Regards.

Hi, from the error log, it seems it's not related to ABP. Can you please check this SO answer and try it to see if it works for you?

Best regards.

Thank you EngincanV so much, the configuration as you suggested "options.TokenCookie.SecurePolicy = CookieSecurePolicy.Always;" already help me fixed the issue. Thanks, Dharma

Great to hear that!

Would switching to RenderMode.InteractiveWebAssembly help ensure better persistence across mobile browsers?

Hi, I don't think it does. Because, when you use auto mode, it first connects via blazor server and then switches to wasm (when the DLLs are downloaded to the browser). So, you can keep InteractiveAuto unless you want strict WASM execution.

Could there be a conflict or redundancy with SignOutSessionStateManager in mobile browsers that affects session persistence?

Yes, this may conflict with session persistence in mobile browsers. Mobile browsers handle session storage differently as you said, possibly triggering unintended sign-outs. So, you can try to remove SignOutSessionStateManager and test if session persistence improves or not.

Is there any recommended approach for ensuring authentication token persistence in Blazor WebAssembly for mobile browsers specifically?

Would explicitly persisting the token in sessionStorage or localStorage on mobile browsers help mitigate this issue?

Storing the token in localStorage might be the best option, since it persists across tabs and restarts and there is no expiration.

Hi, here are the answers for your questions:

1-) Does the system natively support Redis Cluster Mode for distributed caching and event bus communication?

ABP's redis package (Volo.Abp.Caching.StackExchangeRedis) uses the Microsoft.Extensions.Caching.StackExchangeRedis package and it should support Redis Cluster as long as the proper connection string is provided for distributed caching.

For our event bus providers please see https://abp.io/docs/latest/framework/infrastructure/event-bus/distributed#providers

2-) Is any custom logic required for handling multiple Redis nodes?

If you're using a single Redis instance or Sentinel Mode, no custom logic is required as far as I know. However, if you're using Redis Cluster Mode, you should:

• Ensure that the connection string includes all cluster nodes.
• Set abortConnect=false to allow automatic failover handling.
• Consider using a cluster-aware Redis library if advanced failover handling is needed.

3-) How does the system handle failover in case one of the Redis nodes becomes unavailable?

StackExchange.Redis will attempt to reconnect to available nodes automatically, but it does not natively support Redis Cluster failover in an optimal way.

If you're running in Redis Cluster Mode, you need to handle reconnections properly in your configuration to avoid interruptions in caching or event handling.

4-) Could you provide a sample configuration for integrating Redis in a multi-node Kubernetes environment?

Since this is not fully related to ABP, rather than it's related to Redis configuration, I don't have a sample configuration for that.

But, in your appsettings.json, a configuration like below should work:

"Redis": {
  "Configuration": "node1:6379,node2:6379,node3:6379,abortConnect=false"
}

Set abortConnect=false to allow automatic failover handling.

or you can configure RedisCacheOption in your module as below:

        Configure<RedisCacheOptions>(options =>
        {
            options.ConfigurationOptions = new ConfigurationOptions
            {
                EndPoints = { "node1:6379", "node2:6379", "node3:6379" },
                AbortOnConnectFail = false,
                ConnectRetry = 5
            };
        });

The new modules will continue being DDD layered.

Then why not provide a param in the add microservice command to use DDD layer solution or the new one which will be default while adding microservice?

The reason behind this is in your microservice solution, it's more beneficial to go with our standard module template, which provides 3 layers. This allows you to still separate your interfaces and their implementations into different projects and re-use them. For most of the cases, this is more maintainable and easy to start with.

If you go with our old microservice solution template, then there is no problem, you can still use the DDD layered services, but this is a new way that we suggest to start with.

Regards.

Hi, you are trying to deploy your application to IIS right? Please check our IIS Deployment document and see if it works for you.

Regards.