m-Power Manual

Modifying Default Tomcat User How can we change the default username/password Tomcat ships with? Various areas of Tomcat are secured to prevent unauthorized access, such as the Probe utility. mrc highly recommends changing the default username and password. You can change this information by modifying the following file: /m-power/tomcat/conf/tomcat-users.xml. Simply change references of mrcuser and […]

Securing Applications Against Multiple Validation Sources As you may know, m-Power applications can be configured to require Sign-on validation so that your user must first authenticate before accessing the underlying page. Also, as you may be aware, m-Power supports a variety of Sign-on validation types (Database user, Active Directory, Database table, etc…). Occasionally, some developers […]

Automating m-Power Authentication Occasionally, developers need their users to authenticate to the m-Power server (For row level or menu security) but do not wish to prompt the user to authenticate. Most of the time, this is because the user has already authenticated into another system first. Not wanting the user to duplicate the authentication, developers […]

Auditing m-Power Login Activity m-Power developers have the ability to log end-user activity for signon/signoff of generated applications. This functionality is quite useful for a number of reasons, including: Logging which users have accessed their account, when and at what time. Logging which application a user has accessed. Logging how long someone stays active before […]

m-Power Applications and Security   Click here to access the legacy version of this documentation. Jump to: Toggling Security On/Off Configuring Security mrc Signon Page Active Directory Validation Single Sign On Validation Other Information For some users, the need to implement Sign-on security is relatively low. However, at some point in time, you may need […]

Row Level Security for m-Power Applications Click here to access the legacy version of this documentation. Row Level Security is a highly flexible technique for controlling which records are returned based on the current user. The following few steps demonstrate the technique. Create a security table and populate it with data. It may contain several […]

Secure by User or Session ID   Click here to access the legacy version of this documentation. After you have implemented Sign on Security (see here), you may want to control who can see which records. For instance, if I have an order history table for five customers, each customer should only be able to […]

Locking Down your Applications   Click here to access the legacy version of this documentation. Application Security now allows even more option when securing applications. Option 1, Locking down an entire dictionary, and allowing only certain applications to be accessible, is the traditional method and is explained here. Option 2, allows all applications in a […]