XLr8Tools Update to fix zero-day exploit.

 There was a zero-day exploit of a Java library we use call log4j in our XLr8 Tools for Unidata and Universe databases. We have been using that library without incident for 17 years give or take for logging our Java errors. Nonetheless, here is an article that explains this exploit better than I can from PCMAG, enjoy.

Here is our changelog:

v4.17.2 - Dec 12, 2021

  XLr8Developer removed window.changed option since it is not used in Webix

  XLr8Developer added textarea height and width option to size boxes for this Webix control

  log4j update from 2.14 to 2.15

  

v4.17.1 - Nov 18, 2021

  XLr8Installer an option was added to force the creation of a directory file if the file does not exist.

  XLr8Commander right-click option was grayed out in error and is now working.

  

v4.17.0 - Nov 10, 2021

  XLr8Dictionary option added to display on the console dictionary editor reads, writes and compiles.

  XLr8Dictionary editor "Save and Compile Selected" button and menu option failed to write selected items and has been fixed.

  

v4.16.7 - Nov 08, 2021

  XLr8Commandinterpreter was renamed to XLr8Commander in all Java source points.

  XLr8Dictionary editor will no longer show null ids items that were causing errors in display and removal.

  

v4.16.6 - Nov 04, 2021

  XLr8Dictionary editor did not show I-descr that did not match internal values.

It was a good idea at the time

 Creating an HTML page with embedded JavaScript was and is still more art than science. Invariably we ask ourselves many questions:

• Does the page render fast enough?
• Do we have too many images that are slowing the load time?
• Have used the correct code and syntax that runs optimally?
• Does this form enhance the user experience or detract from it?

Having created code back in the early 2000s when HTML and JavaScript were very new, a lot of the syntax and the way things were done back then have changed. But the real question to ask is are we adapting to the new syntax or stuck in our ways?

We unfortunately until COVID-19 reared its ugly head most of us did not have the chance to evaluate if we need to change our coding style and syntax. With an unlimited amount of time and clients that no longer asked for constant changes, we changed our Javascript library from what we had been using for about 8 years to another one called Webix.

About 400 forms need to be updated to use the new library. Our code is program generated, so our driver program needed to be updated to generate Webix code. Moreover, all of the custom code written for the other library had to be adapted to the current library. A lot of code is dynamic so there are many things we need to do with the HTML DOM tree to finagle it so that we get the result we are looking for.

After getting all of these things changed, tested, and released to our customers we thought life was good. Then one of our clients pointed out that they were getting Violations in Google Chrome: "[Violation] Avoid using document.write()." Sure enough, when we turned on the developer tools it was there with this link. The thing we took away from the article was: "With this data in mind, Chrome, starting with version 55, intervenes on behalf of all users when we detect this known-bad pattern by changing how document.write() is handled in Chrome...[t]he script in the document.write() is parser-blocking..."

This technique is how we were able to add dynamic code to our static pages. For instance, if you were using the material UI and wanted to change to Webix contrast UI, we would have to change the form code to the correct cascading style sheets to handle those color and interface changes. On average, we had about 3 document.write() per form. The total hit for rendering the page was about 100 milliseconds according to Chrome. That means we are waiting for 1/10 of a second for Chrome to handle 3 dynamic code links. That is really bad.

It took a few days to digest what this meant for our code generator changes and updating all of our custom code where needed. Next, we need to figure out what code would work since our "Pacer" code would have to be replaced. We search the internet and found this JavaScript code. Of course, we did not use it exactly as they had but someone our staff had already written a dynamic link load code in our standard toolset. Our code generated has been updated to call the JavaScript function and the code has been tested and released to our clients.

Although we are pretty proud of our come, our clients did not notice that the forms loaded any faster. Nonetheless, we celebrated with another toast to code from the 2000s that should have been updated and removed as least in the year 2016 instead of 2021. Oh, by the way, our CEO owned a Pacer back in the day!

Programming in the 18th Century

Are we cutting the trees down with axes or two-man saws? Are we removing the bark with a draw knife? Are we making a log house to minimize our effort? Are we making lumber from a water-powered sawmill? Are we using a solid 12-inch iron hammer? Are we using iron nails?

These are all of the questions I have been answering for some 40 years of developing software in the multi-value world with our piss poor toolset and lack of quality tool vendors.

To refresh your memory a little about multi-value tools here we go. Using AE/ED line by line editor that one of my clients likened the editor to DOS Edlin. My personal favorite is using the editor ED in D3 and forgetting to flip the buffer so the changes did not take. Using UniQuery/RetrieVe syntax at a telnet prompt and my client thought I was using a variation of SQL. I was unable to add a logo to a bunch of forms in UniBasic, but I was proud that I could get it to print out on a laser printer on their network and the client was not impressed.

Our current database vendor has not bought any tools from vendors in quite some time but believes that they can create them from scratch. Their Visual Studio editor is half-baked, cannot compile code, and is missing the majority of features that no other tools vendor would get away with saying wait for the next release. Their front-end developer tool allows you to expose RESTful services to whatever framework you use to replace your telnet framework.

The problem is that most of the programmers using multi-value are over 40 years if not 60 years old. After you get over 40 years old you don't want to learn a new framework let alone these new-fangled tools built by database engineers that have not coded an application ever. Moreover, those programmers work for companies that have milked the multi-value technology for years and think why should I spend money where they cannot see an ROI.

I started developing tools 20 years ago at U2logic that some of my employees and the corporate staff were a mistake. They were somewhat right. The tools: database Editor, database software installer, database web developer, database resizer, database report writer, and database middleware were never a commercial success. However, what they did allow was a small company to develop web-based software that was innovative, pretty, functional, and damn near bug-free.

Our clients say can I have this report with these columns, these break-points, and with this heading with of course a logo. Using open-source BIRT running under Eclipse IDE with our database hookup, that report can be produced anywhere from minutes to days instead of weeks as before. And should the clients want the report in PDF, XLXS, DOCX, or HTML format, we write it once and BIRT uses emitters to produce those requested outputs.

Using Eclipse IDE running our UniBasic editor, a program can be changed and compiled in seconds without knowing how to FTP or what network drive we need to move the source code to. Our XLr8Editor allows you to see your compiler errors as you type which makes debugging the code much faster than the current solutions offered by our database vendor. Since all of the UniBasic code is indexed you can what routines you have already written that might accomplish this task without consulting an external document.

I could go on but you should see the point: Let's move out of our the 18th Century mindset with tools for our present day, or we do not and hope our programmers never die or retire. Either way, one of us will be coding faster, prettier, bug-free, using web interfaces, and have happy clients while the other is still flipping the frigging buffer.