question

Upvotes
Accepted
3 1 1 1

EMA: {"error":"invalid_grant" }

Hi,

We have been receiving the following error message using EMA API. Not sure why:

loggerMsg TimeStamp: 18:06:39.070 ClientName: ChannelCallbackClient Severity: Warning Text: Received Channel warning event on channel Channel_3 Instance Name Consumer_3_1 RsslReactor 0x0x7e9240 RsslChannel 0x(nil) Error Id -1 Internal sysError 0 Error Location /r/emalib_dbg/Cpp-C/Eta/Impl/Reactor/rsslReactorWorker.c:3375 Error Text Received HTTP error 400 status code with data body : {"error":"invalid_grant" } . loggerMsgEnd


Thanks,

elektronrefinitiv-realtimeelektron-sdkrrtema-apielektron-message-apic++
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

I have faced the same issue and dug deeper. According to what I found retrieving an auth token using the refresh token always fail. So authentication logic falls back to using username+password combination with the given warning.

Code:

  
                   
  1. ReactorTokenSession.java:361
  2.  
  3. else
  4. {
  5. _sessionState = SessionState.REQ_AUTH_TOKEN_USING_REFRESH_TOKEN;
  6. _restAuthRequest.grantType(RestReactor.AUTH_REFRESH_TOKEN);
  7. _restReactor.submitAuthRequest(_restAuthRequest, _restConnectOptions, _authTokenInfo, _errorInfo);
  8. }
Upvotes
Accepted
7.6k 15 6 9

@yongguang.wang

Thanks for the log.

Based on your log, it seems to be the issue on the server-side rather than EMA. I’m not sure why the server replies with the invalid_grant because EMA already sends a new request to get a new Access Token with grant_type = refresh_token, and it also sends a valid refresh_token with the request message.


--- REST REQUEST ---


<!-- Time: 22:31:01:808 -->

URL: https://api.refinitiv.com/auth/oauth2/v1/token

HTTP method POST

HTTP header data:

Accept : application/json

Content-Type : application/x-www-form-urlencoded

HTTP body data: grant_type=refresh_token&username=GE-XXXXXXXXXXXXXXXXX&client_id=XXXXXXXXXXXXXXXXXXXXXXXXXXX&refresh_token=XXXXXXXXXXXXXXXXXXXX

Request timeout: 90


--- REST RESPONSE ---


<!-- Time: 22:31:04:547 -->

HTTP header data:

Date : Thu, 14 Jan 2021 03:31:04 GMT

Content-Type : application/json

Content-Length : 29

Connection : keep-alive

X-Amzn-Trace-Id : Root=1-5fffbaf5-31xxxxxxxxxxxxxx498c58c3

X-Served-By : region=us-east-1; cid=43a92xxxxxxxxxxxxxxxxxxxb3205a29

X-Tr-Requestid : xxxxxxxxxxxxxxxx84-3f45af9e7bfe

HTTP body data: {"error":"invalid_grant" }

Protocol version: HTTP/1.1

HTTP status code: 400


--- REST REQUEST ---


<!-- Time: 22:31:09:552 -->

URL: https://api.refinitiv.com/auth/oauth2/v1/token

HTTP method POST

HTTP header data:

Accept : application/json

Content-Type : application/x-www-form-urlencoded

HTTP body data: grant_type=password&username=GE-XXXXXXX&client_id=1fc3b1f559e44d2381c5ffa004909af9c47fb12f&scope=trapi.streaming.pricing.read&takeExclusiveSignOnControl=true

Request timeout: 90


--- REST RESPONSE ---


<!-- Time: 22:31:09:969 -->

HTTP header data:

Date : Thu, 14 Jan 2021 03:31:09 GMT

Content-Type : application/json

Transfer-Encoding : chunked

Connection : keep-alive

Content-Encoding : gzip

X-Amzn-Trace-Id : Root=1-5fffbafd-395d75a2277d9a6417d43767

X-Served-By : region=us-east-1; cid=73ef8666607743fca9aec424574aba15

X-Tr-Requestid : b9395c54-cf7d-479b-b0a7-aa92d476c011

HTTP body data: { "access_token":"eyJ0eXAiOXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-hj2Uiaerqyg8GVvUdOSGzLJ4bunAZCnURln2kozY6Q", "refresh_token":"653XXXXXXXXXXXXXXXXXX", "expires_in":"300" , "scope":"trapi.streaming.pricing.read", "token_type":"Bearer" }

Protocol version: HTTP/1.1

HTTP status code: 200


--- REST REQUEST ---


<!-- Time: 22:35:10:079 -->

URL: https://api.refinitiv.com/auth/oauth2/v1/token

HTTP method POST

HTTP header data:

Accept : application/json

Content-Type : application/x-www-form-urlencoded

HTTP body data: grant_type=refresh_token&username=GE-XXXXXXXXXXXXXXXXX&client_id=1fc3bXXXXXXXXXXXXXXXXXXXXXb12f&refresh_token=65372b05-436b-48c3-9fe2-275e996c03b0

Request timeout: 90


Anyway, after it gets the error, EMA immediately sends a new request with a grant_type password to get a new Access Token instead; therefore, this should not cause a delay in your application. I think that is the reason that EMA treats this kind of message as a warning.


I would suggest you open a case with the RDP server support team and provide them the log to contact the RDP Gateway team to verify what happens at the time reported in the log. As you said previously, this works without warning before, so it is clearly the server-side change.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Upvotes
9.7k 49 38 60

Hi @yongguang.wang,

The error indicates that you likely do not have valid OAuth grant credentials. When you registered for this service, did you receive a Welcome email that provided you a username and password? If so, did you go through the Quick Start Guide to ensure you have proper access?

thanks.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Upvotes
7.6k 15 6 9

@yongguang.wang

Are you testing with the EMA C++ example from the RTSDK package?

If it's one of our examples, Can you let me know the command-line arguments you use to run the example?

You can also try your account with the 113_MP_SessionMgmt example; it is an OMM Consumer application example that demonstrates the basic usage of the EMA library in accessing

and parsing OMM market price data from Refinitiv Real-Time - Optimized.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Hi @moragodkrit.chumsri_1,

I got exactly the same behavior with EMA C++ Linux sample Consumer 113. Thanks!

Upvotes
7.6k 15 6 9

@yongguang.wang

Have you modified any codes before running the app? Or you just build it and then run the app with -username <RDP Username> -password <RDP Password> -clientId <appkey>


Can you try the below curl command with your account on the Linux box? It can help confirm that your login is valid.


curl --location --request POST 'https://api.refinitiv.com/auth/oauth2/v1/token' --header 'authorization: ' --header 'content-type: application/x-www-form-urlencoded' --header 'accept: application/json' --data 'grant_type=password&username=<RDP Username>&scope=trapi&takeExclusiveSignOnControl=true&client_id=<Your App Key>&password=<RDP Password>'

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Thanks a lot, moragodkrit.chumsri_1!

No code changes.

I just executed the curl command and got a long string of access_token.

Please let me know if you get more info about it.

Regards

Upvotes
7.6k 15 6 9

@yongguang.wang

-What version of RTSDK you currently use?

-Did you found the issue after running the application for a while? or you found the error immediately after starting the app?


As far as I understand, the error message is related to the token management that the Reactor fails to use the refresh token grant type to renew the access token, and the Reactor tries to use the password grant type instead. The 240 seconds is the default token reissue interval and 10 seconds is the default retry internal using the password grant type.


Anyway, I can't replicate the issue with the latest version of RTSDK 2.x. I leave it running for a while, and it can run and get the refresh token as usual.


To verify the issue at the application level, please turn on the REST API log. There is the message log for the REST API call that EMA interacts with the RDP Authentication service.


Please add the following log to EmaConfig.xml; if you are using example 113, it should be added under the Consumer_4 section.

<Consumer>

<Name value="Consumer_4"/>

<ChannelSet value="Channel_4"/>

<Logger value="Logger_1"/>

<Dictionary value="Dictionary_1"/>

<XmlTraceToStdout value="0"/>

<RestEnableLog value="1"/>

<RestLogFileName value="Restlog.txt"/>

</Consumer>

You can find additional config from EMACPP_ConfigGuide.pdf provided under folder Docs from RTSDK package.

Ema will generate Restlog.txt under the running directory; it contains the REST API messages EMA sends and receive from the server. We can review the parameters from the log. If it appears to be an incorrect message from EMA, you can directly open a case to the EMA development team.



icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Hi moragodkrit.chumsri_1 ,

Thank you very much for you info!

We are using Electron SDK 1.5.

You are absolutely right that the error message shows up 4 minutes after startup.

I will try the config changes you suggested above.

Regards,

Yongguang Wang

Hi moragodkrit.chumsri_1 ,

I added your suggested config entries and got the following error log.

Regards,

Yongguang Wang


loggerMsg

TimeStamp: 15:30:55.073

ClientName: ChannelCallbackClient

Severity: Warning

Text: Received ChannelDownReconnecting event on channel Channel_4

Instance Name Consumer_4_1

RsslReactor 0x0x2502fd0

RsslChannel 0x(nil)

Error Id -1

Internal sysError 0

Error Location

Error Text </r/emalib_dbg/Cpp-C/Eta/Impl/Transport/rsslSocketTransportImpl.c:7915> Error: 1004 HTTP Tunneling not supported for this platform.

loggerMsgEnd

Have you modified any other configuration in EMAConfig.xml?


Basically, the configuration I just provided is just a config to log the REST API connection, and it does not relate to the REST connection to the Streaming Server. The log seems to be the connection issue between the example app and the Refinitiv RealTIme-Optimized.

Is there any Restlog.txt generated in the running directory?

Do you still found the issue when restoring the configuration to the original config?

Can you download and try the example from the latest version of RTSDK 2.0.0.L1?

Hi moragodkrit.chumsri_1 ,

No other modifications.

Is EMA v1.5 still supported?

What does the following error message mean?

Error Text </r/emalib_dbg/Cpp-C/Eta/Impl/Transport/rsslSocketTransportImpl.c:7915> Error: 1004 HTTP

Regards,


Yongguang Wang

Hi moragodkrit.chumsri_1 ,

I just tried 113 using RTSKD2.0.0 and got the same error. Please see the error log appended below. Should we just ignore it since it is only a warning?

I also have the Testlog.txt file. Please let me know if we can extract any info from it.

Regards,

Yongguang


loggerMsg

TimeStamp: 22:27:01.031

ClientName: ChannelCallbackClient

Severity: Success

Text: Received ChannelUp event on channel Channel_4

Instance Name Consumer_4_1

Connected component version: ads3.4.2.L1.linux.tis.rrg 64-bit

loggerMsgEnd



loggerMsg

TimeStamp: 22:31:04.547

ClientName: ChannelCallbackClient

Severity: Warning

Text: Received Channel warning event on channel Channel_4

Instance Name Consumer_4_1

RsslReactor 0x0x1a18740

RsslChannel 0x(nil)

Error Id -1

Internal sysError 0

Error Location /local/jenkins/workspace/ESDKCore_RCDEV/OS/RH8-64/rcdev/source/rtsdk/Cpp-C/Eta/Impl/Reactor/rsslReactorWorker.c:3441

Error Text Received HTTP error 400 status code with data body : {"error":"invalid_grant" } .

loggerMsgEnd




Sorry, I can't download or open the file.

Anyway, It sounds like that your application can run after receive the warning? If so, I believe that EMA may try to get the token again after failing and generating the warning. If it's the case, I believe that you can ignore the warning message.

Hi moragodkrit.chumsri_1 ,

Thank you very much for you reply!

After the "grant_error", there are still updates flowing down. But, we are not sure about the state of the connection and whether the performance of the connection is down-graded. I think we still need to know the root cause of the warning and even better to fix it.

I can email the Restlog.txt to you

Regards,

Yongguang

Upvotes
7.6k 15 6 9

@yongguang.wang


Version 1.5 still supports, but the error message seems to generate when setting the wrong ChannelType. Actually, I want you to test using the setup explained in Quick Start Guide and then add the following config to the Consumer config you currently use.


<RestEnableLog value="1"/>
<RestLogFileName value="Restlog.txt"/>


If you currently use RTSDK 1.5 and example 113 use Consumer_3, you must add it to Consumer_3.


The original error shows that you are using Consumer_3, but the latest message you provided seems to be Consumer_4 instead. This causes incorrect Channel settings in this case. Note that I use Consumer_4 because the codes in Consumer.cpp from RTSDK 2.0 use Consumer_4 by default.


You can find the following codes to see the difference between the codes from different versions of Consumer.cpp(RTSDK2.0 vs. 1.5). Note that the structure of the EmaConfig.xml has been changed in the latest version.


From RTSDK 2.0 package


// use the "Consumer_4" to select EncryptedProtocolType::RSSL_SOCKET predefined in EmaConfig.xml
        EmaString consumerName = "Consumer_4
        if (connectWebSocket)
        {
// use the "Consumer_5" to select EncryptedProtocolType::RSSL_WEBSOCKET predefined in EmaConfig.xml
            consumerName.set( "Consumer_5" );
        }

From 1.5 package

    // use the "Consumer_3" to select EncryptedProtocolType::RSSL_SOCKET predefined in EmaConfig.xml
        EmaString consumerName = "Consumer_3";

        if (connectWebSocket)
        {
            // use the "Consumer_4" to select EncryptedProtocolType::RSSL_WEBSOCKET predefined in EmaConfig.xml
            consumerName.set( "Consumer_4" );
        }


The original problem you found is that the application found an invalid_grant error when the application re-requests the access token. It’s not the first time the app tries to get a token, so I suspect that EMA might send incorrect grant_type with some invalid parameter to the Authentication Server, there is the reason we need to turn on the REST log file. Also, I suggest you update to the latest version of RTSDK or test it with the latest version because if the problem does not occur with the latest version, it could be some bug, and it is already fixed in the latest build.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Hi moragodkrit.chumsri_1 ,

Thank you very much for your reply.

I added your suggested config entries to Consumer_3. But the parameters were not accepted by v1.5 app using Consumer_3 to and got the following error log.

We use v1.5 company wide and we try to be consistent. This "grant error" did not happen before. It just appeared in recent weeks. We did not change our code at all.

Regards,

Yongguang Wang


loggerMsg
TimeStamp: 23:14:57.856
ClientName: EmaConfig
Severity: Error
Text: unsupported configuration element [RestEnableLog]; element ignored
loggerMsgEnd

loggerMsg
TimeStamp: 23:14:57.856
ClientName: EmaConfig
Severity: Error
Text: unsupported configuration element [RestLogFileName]; element ignored
loggerMsgEnd

loggerMsg
TimeStamp: 23:14:57.856
ClientName: EmaConfig
Severity: Error
Text: unsupported configuration element [RestEnableLog]; element ignored
loggerMsgEnd

loggerMsg
TimeStamp: 23:14:57.856
ClientName: EmaConfig
Severity: Error
Text: unsupported configuration element [RestLogFileName]; element ignored
loggerMsgEnd

loggerMsg
TimeStamp: 23:14:59.185
ClientName: ChannelCallbackClient
Severity: Success
Text: Received ChannelUp event on channel Channel_3
Instance Name Consumer_3_1
Connected component version: ads3.4.2.L1.linux.tis.rrg 64-bit
loggerMsgEnd


@yongguang.wang

The message was generated from the server. I can think of two possible causes for the issue.


1. It's some bug in RTSDK 1.5.0, and EMA sends invalid parameters when it tries to get a new Access Token. And it may occur in some specific scenario, so it's not happened previously. Anyway, I can't replicate it in my env, so I can't confirm.


2. It's a problem on the server-side. If you often found the issue, you might need to open a case with RDP Support to verify the request message that the server receives from your EMA application. The team should check what parameter the application sends to the server and cause the error message.


Actually, I'm using 1.5.1.L1, and it's the first version that introduces the EMA configuration to log the REST API message. It was created to investigate the issue, like the error you found. I would recommend you to use 1.5.1 or update it to 2.0.0.L1 instead. There are many changes in EMA internal codes. It may help resolve the issue as well. Note that when you found any issue in 1.5.0 and it is still reproducible in the latest version, the Development team will fix it based on the latest version's codes rather than fix it in the version you are using.

Hi moragodkrit.chumsri_1 ,

Please let me know how should I sent the Restlog.txt file to you. By email?

Regards,

Yongguang

@yongguang.wang

It looks like the file contains some sensitive information; therefore, It gets blocked by the system.

Can you send an email to moragodkrit.chumsri@refinitiv.com? Hopefully, the email system will not block the attached file.

You can also use https://thomsonreuters.sendthisfile.com/ to send the file to me.

Click below to post an Idea Post Idea