Prevent the user from modifying his own account

Hi,

By default, in ARAS, a user is able to modify his account. So, he can change "Login Name", "First Name", "Last Name" and many other attributes.

How to prevent these changes while allowing the password to be changed?

Thank you in advance.

Parents
  • Hi Mirkas,

    this one is an interesting question and I am also looking for a solution.

    In one project I simple removed end user´s 'View' rights to the 'User' Form. This way end users are not able to change their accounts when using the regular user interface. Of course they still could by using AML, so this is not a very thorough solution.

  • Hi

    I guess this need to be handled through code as the requirement is disable all fields except password. I guess below blog might help

    https://community.aras.com/f/development/35923/disabling-all-fields-in-the-form-using-method

  • Hi,

    disabling the fields is another variant, but it´s still 'just' a client side solution. It´s sufficient for most use cases as a client side approach helps to prevent accidental unintended changes by the user.

    But me being the 'Ultimate (self-proclaimed..) Innovator security expert' I still would prefer a real restriction on server side.

    There is a community project that uses property based permissions, but I am not sure if we should use it on a core item. One other variant would be to replace the existing "Change Password" Action with a custom version that just grants permission to overwrite the password of ones own account. But I am not sure if this would open up an unwanted backdoor.

Reply
  • Hi,

    disabling the fields is another variant, but it´s still 'just' a client side solution. It´s sufficient for most use cases as a client side approach helps to prevent accidental unintended changes by the user.

    But me being the 'Ultimate (self-proclaimed..) Innovator security expert' I still would prefer a real restriction on server side.

    There is a community project that uses property based permissions, but I am not sure if we should use it on a core item. One other variant would be to replace the existing "Change Password" Action with a custom version that just grants permission to overwrite the password of ones own account. But I am not sure if this would open up an unwanted backdoor.

Children
  • Hi Angela,

    I switched the "readonly" property to 1 for some properties of the User ItemType (login_name, first_name, last_name) with this code:


    var ws = innovator.newItem("Property", "merge");
    ws.setAttribute("where", "id IN ('6C3BE07832AA41028237F2FA79EBC069', 'E96F463BC35146A1AC1A0D92AC0C2A6E', '7188DFCEC22147DC97F10239607ADDFA', '86EC9DD76D504543BAF6AFC372187C36')");
    ws.setProperty("readonly", "1");
    var r = ws.apply();
    if(r.isError()) output+=r.getErrorString();

    Thank you again.