V.14.1 still crashes on invalid XSLT

The bug I wrote about some time ago with invalid XSLT still exists in v.14.1

That time it was missing the <tbody> in a <table>. This time it was an <input> inside a <tr>. Obviously wrong, I know, but apparently whichever version it was written in back in 2010/2011 allowed it and today, when I wanted to do an edit, the editor crashed.

The <input> was moved to the <td> within the <tr>.

Advertisements

Lansa Editor still rewrites my code

A follow-up to the other post from last year, I have now experienced this in a new and disturbing way.

I realize that this code is not pretty but it was just a quick job that I would fix later. In this case, I added some javascript that would append an HTML element with an attribute. The javascript used double-pings (“) and the attribute would then use pings (‘):

2017-02-14_090415

Unfortunately, when checking in the changes the Lansa Editor changed the pings to double-pings, rendering my code buggy.

Switching technology services

I have now had the help from Lansa support for a very specific problem. We have a number of solutions, some of which use the XHTML technology service, some the PPC_XHTML technology service.

None of these solutions use more than one technology service.

PPC_XHTML is no longer supported by Lansa so when we upgraded to v.14 this presented a problem. Support found a way to make it work and we continued, making only minor adjustments to the code.

Now we have been upgraded to v.14.1 and something broke in the process.

It can still be made to work but we can only have either XHTML or PPC_XHTML working at the same time. Due to a deadline we will live with that for a short time and then we will start the migration of the PPC_XHTML solutions.

The work-around is this:

Getting XHTML to work: Use Tools -> Import to import the v.14.1. weblets. Done.

Getting PPC_XHTML to work: Use Tools -> Import to import the old v.12 weblets. Check out the specific design weblets made for our solution. Check out the WAM that we need to work with. Done.

So, not bad but not optimal either. That is of course the problem using a technology that is no longer supported.

An example of the JSM HashService

The documentation for some of the functionality in Lansa is sparse, at best. The HashService in Lansa Integrator is one such area (documentation currently here), so here is an example I have that works:

It is important to read up on cryptography first and a short and good guide can be found here.

Define Field(#JSMXHDLE1) Type(*CHAR) Length(4)
Define Field(#JSMXSTS) Type(*CHAR) Length(20)
Define Field(#JSMXMSG) Type(*CHAR) Length(512)
Define Field(#JSMXCMD) Type(*CHAR) Length(512)
* WVALUE is the value to be hashed
Define Field(#WVALUE) Type(*CHAR) Length(255)
* WHASH is the hash returned
Define Field(#WHASH) Type(*CHAR) Length(64)
* WSALT is the salt for the hashing
Define Field(#WSALT) Type(*CHAR) Length(64)
* WINPUT is the value sent to the hashing function = WVALUE + WSALT
Define Field(#WINPUT) Type(*CHAR) Length(319)
* Open service
Use Builtin(JSMX_OPEN) To_Get(#JSMXSTS #JSMXMSG #JSMXHDLE1)
Execute Subroutine(CHECK) With_Parms(#JSMXSTS #JSMXMSG)
* Load service
#JSMXCMD := 'SERVICE_LOAD SERVICE(HashService) TRACE(*YES)'
Use Builtin(JSMX_COMMAND) With_Args(#JSMXHDLE1 #JSMXCMD) To_Get(#JSMXSTS #JSMXMSG)
Execute Subroutine(CHECK) With_Parms(#JSMXSTS #JSMXMSG)
* Set
* * WVALUE
* * WSALT
* See https://crackstation.net/hashing-security.htm
* WSALT should be unique for each WVALUE
* WSALT should be at least as long as the result value
* - for SHA-256 that is 256 bits
#WINPUT := #WVALUE + #WSALT
#JSMXCMD := 'HASH FIELD(WINPUT) DIGEST(SHA256) SERVICE_EXCHANGE(*FIELD)'
Use Builtin(JSMX_COMMAND) With_Args(#JSMXHDLE1 #JSMXCMD) To_Get(#JSMXSTS #JSMXMSG)
Execute Subroutine(CHECK) With_Parms(#JSMXSTS #JSMXMSG)
#WHASH := #JSMXMSG
* Unload service
Use Builtin(JSMX_COMMAND) With_Args(#JSMXHDLE1 'SERVICE_UNLOAD') To_Get(#JSMXSTS #JSMXMSG)
Execute Subroutine(CHECK) With_Parms(#JSMXSTS #JSMXMSG)
* Close service
Use Builtin(JSMX_CLOSE) With_Args(#JSMXHDLE1) To_Get(#JSMXSTS #JSMXMSG)
Execute Subroutine(CHECK) With_Parms(#JSMXSTS #JSMXMSG)
* Check routine
Subroutine Name(CHECK) Parms((#JSMXSTS *RECEIVED) (#JSMXMSG *RECEIVED))
If Cond('#JSMXSTS *NE OK')
Use Builtin(JSMX_CLOSE) With_Args(#JSMXHDLE1) To_Get(#JSMXSTS #JSMXMSG)
Menu Msgtxt('Java service error has occured')
Endif
Endroutine

In this example I have chosen SHA256 which I believe is OK. Avoid MD2 and MD5 if possible, as collisions has already been found, and as SHA1 has a theoretically attack described I would avoid that one as well, even if it is default for the HashService. SHA384 appears to also be supported and could be used.

The HMAC algorithms would be even better but there I ran into a problem. I am running on Lansa v. 14, I think that the documentation is for v. 14 SP1, and there is no HMAC parameter in the HashService on my machine. Also in the documentation, there are the CONVERT and CREATE commands, the last of which should give me a good random unique salt, but the are not present on my machine.

Anyway, the code above works.

A bug in the editor

It turns out that the error I got trying to access the XSLT source (not the missing shortcut, the crash) was due to a bug in the editor. I had a

<table>
<xsl:choose>
...

with no <tbody>. Yes, I know.

But the editor checked the XSLT and appears to think it is fine. Then the renderer took over and crashed, due to the missing <tbody>.

Fortunately I found the XSLT in the temp cache so with the supplier’s help I could regenerate the XSLT (deleting all my work) and reinsert my code, now with the <tbody> tag.

Done.