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.

From Telnet to Web: A Short Story

Let's go through a brief history of moving to the web through our eyes. Of course, we only used Unidata back then. U2logic was a VAR for Unidata the company. Nearly 100% of the work we did back then was to maintain Telnet applications (green screen) and enhance them. Today 100% percent of our work is Web-based application development. 

We starting looking at going to the web in the late 1990s. There was not much in the way of tools or technique. It was tough to get any traction until we found an ISP that would host our site. We created the site using HTML and a little JavaScript. By the way. Cascading Style Sheets was just invented and we could not figure it out so we embedded style in the HTML. We had a CGI interface. We read information from a flat file and posted it from our database to the web and read back the data to our database. 

We found Redback back around 1999. Redback only ran on Internet Explorer version 4 using the Microsoft web server. The Redback code was kludgy and our code was even worse. Nonetheless, we starting learning how to talk to the Web and how clients would react to entering data and running reports. 

Shortly thereafter Unidata replaced Redback with Redback Open containing Redback Objects (RBO). This time we had an executable that we could talk to our database. RBO’s were a major step up when communicating with our database. Nonetheless, the problem was all of the code we created with Redback we had to throw away. The two systems were not compatible. Well, that did not stop us. We converted most of our applications to Redback RBO's.

There were a few severe problems with Redback RBO’s. Redback required us to restart our Microsoft web server at least once a week or it would just stop working. We had to run a manual purge to clean up temporary files that Redback created because the Redback garbage collect did not delete all of the files and would continually slow down.

One of U2logic's staff suggested we write our own middleware to solve Redback’s issues. We thought the idea was crazy, but what the heck. Though and behold around 2006 we created U2WebLink which supported Unidata and Universe. This software used the same ideas as Redback's RBO. U2Weblink middleware which was written in Java ran using UniObject for Java and Apache Tomcat as the webserver. We got to keep most of UniBasic code, HTML, and JavaScript a very surprising fact for us all. 

Today we are still using U2WebLink. The current version runs on Java 15 and Apache Tomcat 10. Moreover, U2Weblink supports an open-source reporting tool call BIRT from Eclipse.org that can produce PDF, HTML, DOCX, and XLSX output. We developed an API that allows us to call UniBasic Subroutines without creating an object for interface purposes. U2Weblink is highly scalable and has been tested with up to 15000 users. Since we built our monitoring system from within it does not take up any noticeable resource and gives you a picture of how the system is running. We stopped trying to develop our own JavaScript library routines back in 2008. Currently, we use a JavaScript library called Webix.