A common desire among organizations that adopt the Fluid user interface (UI) is the ability to keep the Classic UI for administrative users. The loudest argument backing the need for the Classic UI for admins is that the Fluid UI does not have breadcrumbs. The response to this argument is that the adoption of Fluid is more than just mobile-enabling the application, but it also entails leveraging the new Fluid navigation paradigm which means using homepages, tiles, navigation collections, search, etc., to give users an avenue to perform the transactions that they need to perform. A proper adoption of the Fluid UI means leveraging these tools to “create your own navigation” for not only self-service users, but admin users as well. While I don’t necessarily have a dog in this fight, I would like to provide a proof-of-concept example on how one can go about keeping administrative users Classic in a Fluid environment.
A recent comment I received made me go back and revisit my “Implementing Google Authenticator in PeopleSoft” post where I discuss the code involved to get Google Authenticator working in PeopleSoft. Revisiting this post made me realize that I never actually shared the source App Designer project with the community. I would like to use this post to share the plug and play POC project that I use to enforce component-level 2FA with Google Authenticator in PeopleSoft applications.
One major drawback of the response-manipulating servlet filters that I have showcased on this site is that the delivered compression functionality needed to be disabled for them to work. This involved unchecking the “Compress Responses” checkbox on the web profile configuration page in the PIA. Disabling this functionality causes a performance impact because of the resulting large response messages that get sent to the client. I recently got a comment from Jonathan Rehm explaining how he has achieved GZIP compression within a custom servlet filter. I decided to integrate the code he shared into a standalone response compression servlet filter. This servlet filter can co-exist with any other custom filters that you may have deployed. I will demonstrate how to deploy this custom response compression servlet filter in this post.
Some of the servlet filters that I have previously demonstrated make use of configuration data that originates from the PeopleSoft application. This configuration data consists of things like which fields to mask and what components to restrict access to. This data is ultimately what controls how the servlet filters behave. In this post, I would like to discuss how I go about communicating configuration data from the PeopleSoft application to the web server and the techniques that I use to manage this data. First I will go over the design, installation, and use of a caching utility that I wrote to manage the configuration data. Last I will discuss how I integrate my servlet filters and PeopleSoft application with this solution.
I’d like to share a demonstration of a field-level data masking solution that I’ve created for PeopleSoft. This project showcases a lot of the techniques that I have discussed throughout the year on this blog with respect to creating a secure PeopleSoft application with a good user experience. This bolt-on solution provides a user interface to configure what fields to mask, the conditional ability for end users to unmask data, and a way to track the sensitive data exposure throughout the system.
The HTML element IDs that appear on PeopleSoft pages follow an officially undocumented naming convention. It would be nice to know the exact naming convention that is being used on these HTML element IDs so that there would be no uncertainty when it comes to DOM manipulation with injected client side code. Fortunately, there have been many PeopleSoft experts in the past that have demonstrated how the HTML element IDs on PeopleSoft pages typically have their record and field names present in the ID. It is worth noting that not all fields follow the RECORDNAME_FIELDNAME naming convention. This is true for fields that have a value set for the page field name in the page field properties in App Designer. An example of this would be the National ID field that appears on the relationships page.
Modifying or transforming response data generated by the web server is a great use of servlet filters. I read a nice Stack Overflow thread that discusses the idea of injecting text into the head of an HTML response using a servlet filter. The code provided in this thread is a great example of how to modify HTML response data that gets sent to the client. I made some slight modifications to this code so that I can inject custom scripts and styles in the HTML responses generated by the PeopleSoft web server. This servlet filter will be a bolt-on solution to achieve global script and style injection in PeopleSoft. Below are the steps to configure this servlet filter for the PeopleSoft web server.
In this post I will provide a step-by-step tutorial on how to send SMS text messages in PeopleSoft. I will be consuming Nexmo’s SMS API to send SMS messages. There are many SMS API services similar to Nexmo and there is no particular reason that I chose Nexmo over the other providers for this tutorial. I have some experience with using other providers and the quality of service is comparable across the board. There will be four main steps in this tutorial: creating a Nexmo account, importing Nexmo SSL certificates, importing custom objects, and testing the service.