Visual LANSA Forum

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?

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).

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?

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:
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.

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