The Base64 string for the authorization should have an equals sign (=) on the end.  Try adding that and see if it works.

Authorization: Basic VHlqRlpUV1V0WFg2VnllZjpPRXVmeDlhb2FLVHlmVmFB=

Are you running the service as LocalSystem or LocalService?  The LocalService is very restricted while the LocalSystem basically has full access to the machine, but it accesses the network with machine credentials instead of user credentials, so that might be the issue.  I would try running the service with a user account just to see if it works that way.

Thanks for that tip, Stéphane - that's new to me! 

Unfortunately, we have a lot of clients on PXP12, and the DIM CLASS doesn't work on that version since it wasn't added until PxPlus 2016.  I tried it on later versions, and it works well, and is easier to manage than building a string of elements for use with the WITH NUM clause of the DIM.  I typically use the WITH NUM clause, which I described on the other duplicate post in this forum.  But, going forward, I'll probably start using this DIM CLASS instead.

Here is a better example, which uses a comma-delimited list of the JSON elements that should be numeric.

0010 BEGIN
0020 LET arr$["string"]="123"
0030 LET arr$["numeric"]="123",withnum$+="numeric,"
0040 LET arr$["this.is.a.string"]="456"
0050 LET arr$["this.is.a.number"]="456",withnum$+="this.is.a.number,"
0060 PRINT "Withnum$= ",withnum$
0070 PRINT DIM(LIST EDIT arr${ALL} WITH NUM(withnum$))

run

Withnum$= numeric,this.is.a.number,
{
  "string":"123",
  "numeric":123,
  "this":{
    "is":{
      "a":{
        "string":"456",
        "number":456
      }
    }
  }
}

Use the "with num" option for JSON to specify which values are numeric.  Below is an example.

arr$["string"]="123"
arr$["numeric"]="123"
print dim(list edit arr${all} with num("numeric"))

{
  "string":"123",
  "numeric":123
}

Does it work if you actually include the filename in the URL?

08120  LET R$="GET /download/update/index.html HTTP/1.0"+$0D0A$

Search for "IOL=" in *winproc.dsp.  It is most likely line 8010 that has the IOList.

8010 IOLIST _obj_nme$,_obj_c,_obj_l,_obj_w,_obj_h,_obj_type$,init_text$,init_val$,_obj_tab,_obj_def$,_obj_dsp$,_obj_fcs$,_obj_sel$,_obj_msg$,_obj_hlp$,_obj_attr$,_obj_idx$,_obj_hotkey$,_obj_qry$,_obj_sec$,_obj_sts$,_obj_grp$,_obj_null$,_obj_tag$,_obj_tbl$,_obj_inp$,_obj_out$,_obj_valid$,_obj_class$,_obj_tip$,_obj_orig$,_obj_font$,_obj_color$,_obj_listbox_type$,_obj_sep$,_obj_scratch$,_obj_popup$,_obj_sizing$,_obj_logic1$,_obj_logic2$,_obj_popup_logic$,_obj_qry_bitmap$,_obj_qry_width,_obj_qry_tip$,_obj_qry_attr$,_obj_extension$,_obj_demand$,_obj_demand_logic$,_obj_background_logic$,_obj_persistence$,_obj_notes$,_obj_tbl_len,_obj_tvline_color$,_obj_autosz_width$,_obj_autosz_height$,_obj_automation_text$,_obj_hilight_colors$,_obj_props$,_obj_visual_class$

As a followup, updating the client to PXPlus version 17 resolved the issue - we haven't seen any crashes since the update. 

Thanks, Mike, for your detailed explanation of the versions available for the OS release, and thanks to James and Jason for the debugging suggestions!

Here's a simple example of creating a signature hash for an XML document, based on a Wikipedia example.  But, this only creates the signature and does not encrypt the signature data using RSA, which is what the XML signing requires.  To complete the process, you would need to finish building the required XML (most of which was included in your example in the <Signature> segment), and then create an RSA-encrypted signature value for that segment.  I don't know of any method of using RSA encryption directly within PXPlus, but maybe Mike can comment on that.  Mikes suggestion of using the XMLSEC utility might be the only method of handling the RSA part.


-;list
0010 BEGIN
0020 LET inv$=XML(ADD "Marge Simpson" TO inv$,KEY="Client")
0030 LET inv$=XML(ADD "847.63" TO inv$,KEY="Amount")
0040 LET inv$=XML(ADD inv$ TO $$,KEY="Invoice")
0050 LET sig$=CVS(HSH(inv$,256),"ASCII:BASE64")
0060 LET xml$=XML(ADD sig$ TO inv$,KEY="Signature",OPT="xmlns=""http://www.w3.org/2000/09/xmldsig#""")
0070 PRINT xml$
-;
-;run

<Invoice>
<Client>Marge Simpson</Client>
<Amount>847.63</Amount>
</Invoice>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">G9Q1/Lu96dgOVNd3ZChqZLCBUDgIPuAivTwVIngey2U=</Signature>
-;

You can do this in PXPlus using the HSH() function, and possibly the CVS() function to convert to Base64. 

I've worked on several web interfaces that require some sort of digital signature as part of the data (usually, as part of the HTTP data sent).  They are all very similar:  Take some chunk of data or a concatenation of various data fields, create a hash of that data using the private key, convert the hashed value to base64, then include the hashed value (signature) in the data being submitted.

The recipient also needs to know the public key which needs to be used to decrypt the signature.  In looking over the XML signing documentation, it appears that you must include the public key as a field in the XML data.  (For websites, you generally provide some sort of username/login, which the website then uses internally to retrieve the decryption key associated with your account)

The HSH function in PXPlus will allow you to encrypt the data in various formats using various keys (certificates) (https://manual.pvxplus.com/PXPLUS/functions/hsh.htm#format_1)

The CVS function can be used to convert the signature to base64 encoding (eg:  sig$=CVS(mydata$,"ASCII:BASE64")  ), or you can use the *web/base64 utility.

If you aren't able to get it working, let me know and I can try to generate a short example.

Mike - We had already done the 12.5 update before I read your comments about versions, and I mentioned it just to confirm that the 12.5 update didn't resolve the issue.  Sorry for the confusion - I should have made that more clear!  We understand that 12.5 probably has some issues running on RH7.9, so we're working on updating to 17 now.  Not sure if we want to do that just before a long weekend, tho, so we might wait until Tuesday.  I'll keep you posted.

Mike - Thanks for that info. I wasn't aware of these version issues since I don't handle the installs, so I appreciate your detailed explanation!

We did just update them a few minutes ago to the latest 12.5 build, but that didn't help, so we'll try installing v17 and see if that resolves the issue. 

James, like you, I've only seen an error 61 in relation to Windx installations.  This process is running as a cron process on the Linux server, so Windx isn't involved.  I suspect the error 61 relates to some permission denied at the OS level.

Jason, thanks for the suggestion on checking the 'IZ'. I did run the process and dump the PRM to a trace file, just to confirm that the 'IZ' parameter is enabled when run as a cron.  It is enabled, so the process shouldn't be encountering memory limits. 

We have a strange PXPlus crash occurring at one client, using a routine that is used at multiple clients. 

The routine gets an error 61 (Authorization failure) when issuing a LOCAL command to localize several variables.  At that point, the SETERR branch is taken, and the routine tries to close files.  The PXPlus session then crashes when closing one particular file (the same file every time). 

I don't really have a clue what would cause an error 61 on a LOCAL command!

- I've removed the LOCAL command that was getting an error.  The error then occurs on a different line that is also issuing a LOCAL command, and the session still crashes.
- I've renamed the particular file that is being closed every time the session crashes (thus leaving it in place on the hard drive), then re-created the file.  Still crashes.

Before the system crashes, I print the MSG(-1) to a trace file, but it is blank. 

We suspect a memory/swap file issue, so I also dump the contents of the Linux "free" command to text file immediately after the error 61.  The file shows that there is over 2megs of free memory at that moment, so it wouldn't seem to be an issue with allocating memory for the LOCAL command.  I don't know if the swap file is configured correctly, but it does show swap file available but not being used (or only a tiny amount of swap used).

The client is running PXPlus version 12.50 on a Linux server running RedHat 7.9. 

Any suggestions on how to resolve this, or other ideas on what to check?

Jeff, if you're using Nomads, you might be able to do this with a Dependency Definition.  The dependencies are very good at checking everything and updating the screen as needed anytime the user interacts with the screen.  I'd prefer the dependency since I hate to just put a WAIT on the message, since that prevents the user from doing anything for the entire WAIT time.  Displaying a message using a dependency would allow the user to continue working, and the message would just clear once Nomads had to do anything after the specified time had expired.  If the user didn't interact with the screen until long after the time had expired, the message would still be displayed since nothing happened to trigger the dependency checks.  You could get around this by adding a timeout check to the screen.  Leaving the message on the screen until the user interacts with the screen again might not be a bad idea, since it gives an indicator of what the user was doing before they took a long pause.

For example, I created a panel with several controls, including a multiline named ML1, a multiline named FLASH, and a checkbox named CHK1.  There is no logic associated with any of the controls.  I then added a dependency as shown below:

Condition=flashtim>0 or not(nul(ml1$))
Invert=N
Depend Logic=Execute tn=(jul(0,0,0)*86400)+num(dte(0:"%S"));if tn>flashtim then flash$=$$,flashtim=0 end_if;if not(nul(ml1$)) then let flash$=ml1$,flashtim=tn+5,ml1$=$$

When processing the screen, any text entered into the ML1 box will be displayed in the FLASH box for a minimum of 5 seconds, unless ML1 is changed to something else.  After 5 seconds, FLASH will be cleared as soon as Nomads does anything.  Almost any interaction with the screen (even just tabbing between controls, or clicking on the checkbox CHK1 even though it has no logic) will cause Nomads to check the dependencies, and reset the flash message if the time has expired.  As noted, you could also set a timeout of 5 seconds on the Nomads screen if you really wanted the message to be cleared after 5 seconds even if the user wasn't interacting with the screen.