EMA: {"error":"invalid_grant" }

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

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

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

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

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

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

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.

All comments

nick.zincone

Hi @YW,

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.

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.

moragodkrit.chumsri_1,

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

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>'

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

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

<Name value="Consumer_4"/>

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

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

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

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

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.

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

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.

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

Regards,

Yongguang