Open Closed

Featur enable-disable approach with Redis for on-premise systems #6673


User avatar
0
selinkoykiran created

Hello, We're using abp's default feature module. For every custom module that we developed, we're creating a class derived from FeatureDefinitionProvider and defining our features . When we run the application, it seems these features are written into our Redis cache and into db . We'll be installing our application with modules (some of them disabled some of them enabled by default) as on-premise. But we realized something. If we go to redis and edit features' values manually then we able to see the hidden modules . Is that a bug for on-premise system or do you have any suggestions about that topic ? Because in that case, even if we close some of the features , customers still can go into redis and change default variables and enable hidden features easily. What should we do in that case, how can we prevent this behavior ? Thank you .

  • ABP Framework version: v7.3.1
  • UI Type: MVC
  • Database System: EF Core (SQL Server, )
  • Tiered (for MVC) or Auth Server Separated (for Angular): yes/no
  • Exception message and full stack trace:
  • Steps to reproduce the issue:

3 Answer(s)
  • User Avatar
    0
    liangshiwei created
    Support Team Fullstack Developer

    If we go to redis and edit features' values manually then we able to see the hidden modules .

    No, it's not a bug. you should use a remote Redis server instead of a local.

    If everything is installed locally on the client, even without Redis, the customers can change the database directly, right?

  • User Avatar
    0
    selinkoykiran created

    But abp should support both on-premise and cloud deployments, right ? Besides like you said, even without redis customers still change these features via db and this is a problem for also cloud installations. I think we need a solution something like => not persisting these features to anywhere (just runtime). We need to solve this issue it can be a big problem when you sell your product to customers . In someway this feature enabling/disabling thing via redis or db should be prevented ! What can we do at that point, which class should we override FeatureManagementProvider or IFeatureManagementStore ?

  • User Avatar
    0
    liangshiwei created
    Support Team Fullstack Developer

    Hi,

    If the database server and Redis server are installed on the client, the client can change almost everything. This is not only a problem with ABP but with all software, isn’t it?

    I think we need a solution something like => not persisting these features to anywhere (just runtime).

    This is a possible solution, you can replace the IFeatureManagementStore service to get feature value from memory: https://github.com/abpframework/abp/blob/dev/modules/feature-management/src/Volo.Abp.FeatureManagement.Domain/Volo/Abp/FeatureManagement/FeatureManagementStore.cs

    • Configure the feature value to memory before on-premise
    • Always get the feature value from memory
Made with ❤️ on ABP v9.1.0-preview. Updated on December 12, 2024, 07:15