LANSA REST API Persistent Fields

This Q&A forum allows users to post and respond to "How Do I Do ....." questions. Please do not use to report (suspected) errors - you must use your regional help desk for this. The information contained in this forum has not been validated by LANSA and, as such, LANSA cannot guarantee the accuracy of the information.
Post Reply
jan
Posts: 26
Joined: Thu Sep 06, 2018 12:36 pm

LANSA REST API Persistent Fields

Post by jan » Mon Aug 19, 2024 3:32 pm

Hi,

I'm getting around the concept of LANSA REST APIs now but noticed that there was nothing in the available documentation that mentioned Session Management anymore. I guess this has been superseded by using JWT Tokens at this stage.

How can one persist a value over the server-side for REST APIs? Are we reliant on adding custom claims to the JWT Tokens now? How secure would it be for us to keep custom claim values there without the risk of somebody tampering with it?

And will Session Management still actually work with REST APIs? Can they be used in conjunction with JWT Tokens?

BrendanB
Posts: 134
Joined: Tue Nov 24, 2015 10:29 am

Re: LANSA REST API Persistent Fields

Post by BrendanB » Tue Aug 20, 2024 8:34 am

I dont think that there is a way to Persist values in a REST API.

If you are using JWT Tokens, then adding a value such as a GUID to the claim, and storing your persistent values in a table keyed by that GUID might be the best way (ensure that you delete from the table when the user 'logs out' or when a period of time has passed).

jan
Posts: 26
Joined: Thu Sep 06, 2018 12:36 pm

Re: LANSA REST API Persistent Fields

Post by jan » Wed Aug 21, 2024 10:49 am

Thanks for verifying the persistence in REST APIs Brendan!

With regards to the GUID, is it good practice to use the system variable *GUID or *GUID_DB to serve as the key to a table that will help track down persistent values?

BrendanB
Posts: 134
Joined: Tue Nov 24, 2015 10:29 am

Re: LANSA REST API Persistent Fields

Post by BrendanB » Wed Aug 21, 2024 3:42 pm

If you are going with a GUID, theoretically *GUID_DB should be used (36 chars, with '-' every so often).

to be more secure (especially if using as a claim in JWT tokens), you could also do:

Code: Select all

Define_Com Class(#XPRIM_Binary) Name(#CryptoKey)
#CryptoKey.FromRandomBytes ByteCount(32)

#myKey := #CryptoKey.AsHexString
this will give you a cryptographically secure string.

*GUID or *GUID_DB use the Mersenne Twister algorithm https://docs.lansa.com/15/en/lansa015/i ... 4_0120.htm which it should be noted can be predicted AFTER observing 624 generated numbers.

*GUID = '1b535744e0ba478f9546c4faa983c558'
*GUID_DB = '1b535744-e0ba-478f-9546-c4faa983c558'

(the difference is the 4 dashes).

i would preference using the #Xprim_Binary.FromRandomByes as this is more secure.

jan
Posts: 26
Joined: Thu Sep 06, 2018 12:36 pm

Re: LANSA REST API Persistent Fields

Post by jan » Tue Aug 27, 2024 12:08 pm

Thanks for the advice Brendan! The cryptographically secure string does seem more secure and sensible to use.

Post Reply