Bearer Token in CLOB

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
jyoung
Posts: 642
Joined: Thu Jan 21, 2016 6:43 am
Location: Oklahoma City, OK USA

Bearer Token in CLOB

Post by jyoung » Thu Jan 24, 2019 8:19 am

I'm integrating with an API that does bearer authentication. I need to store the bearer token so that I can use it in subsequent requests.

Because the token can be pretty large, I have created a CLOB based field to handle it (wk_WorkforceAuthToken).

Code: Select all

if ((#Request.Response.IsSuccessfulRequest) *AndIf (#Request.Response.IsSuccessHttpStatusCode))
#Reader.SetSourceHttpResponse httpresponse(#Request.Response)
#wk_WorkforceAuthToken := #Reader.ReadStringWithName( "access_token" )
endif
The problem is that when I try to set the field, I get an error stating "type CLOB is not assignment compatible with expression Reader.ReaderStringWithName("access_token").

I could make the token a string type, but I am worried that the token will blow out the length.

Whats the best way to deal with this?

Thanks,
Joe

dannyoorburg
Posts: 152
Joined: Mon Jan 04, 2016 9:50 am
Location: Australia

Re: Bearer Token in CLOB

Post by dannyoorburg » Fri Jan 25, 2019 9:34 am

Hi Joe,

a LANSA String field can hold up to 64k, what makes you think your token might exceed this?

I just googled a but and it looks like a larger size would hit other limitations long before it hits LANSA's field length limit.

( https://stackoverflow.com/questions/260 ... -jwt-token )

But I might be wrong...

Breaking it into pieces to create a file to store as a CLOB sounds a bit cumbersome.

Danny

jyoung
Posts: 642
Joined: Thu Jan 21, 2016 6:43 am
Location: Oklahoma City, OK USA

Re: Bearer Token in CLOB

Post by jyoung » Fri Jan 25, 2019 9:48 am

I initially started this using a work field defined in the repository.
I created a new field as a string type and had to supply a length, but really had no idea what to put there.
That immediately made me concerned about blowing the length of the field, so I started looking at CLOBs.

I was wanting something that was re-usable and the use of a field was required because I was planning on returning the token from a Function and needed something to "exchange" back.

I ended up tweaking the design a bit by using a RP instead of a Function, thereby not requiring a field to exchange.

Now I can store the token in a PRIM_DC.Unicode string that I can easily add as a bearer token.

Joe

EDIT:
For some reason, I think of Functions when I need usability on the server. I think because they naturally handle the lists and fields that get in a Server Module. I am beginning to embrace RPs on the server, but really wish there was a way to map a component array, much like a list map. But that's another discussion. :D

Post Reply