Forums - Thread Details
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 8 replies
  • Subscribers 321 subscribers
  • Views 3924 views
  • Users 0 members are here
Related

Where to change client_id and client_secret

Luisa Castano

I am a freelance software developer trying to send data to the sugarCRM endpoint of a client. This is my first time interacting with sugarCRM and it is not the principal focus of my project for the company-client, so I really just need it to work.

In order to authenticate, I am doing this:

curl -X POST -H Cache-Control:no-cache -d '{   "grant_type":"password",  "client_id":"sugar",  "client_secret":"",  "username”:"<username>",  "password”:"<password>",  "platform":"base" }' https://<companyname>.sugarondemand.com/rest/v10/oauth2/token

The answer is then:

Bad data passed in; <a href="https://<companyname>.sugarondemand.com">Return to Home</a>

My client has assigned a non-technical person to do all the sugarCRM setup and that person can not really help. I know the "username" and the "password" are correct, as well as the "grant_type", my only worries are the "client_id", the "client_secret" and the "platform". Where do I set these variables in the sugarCRM interface?

This is all I get when I enter "Settings -> Client OAuth":

To make matters worse, my client's sugar is in Spanish, which I fluently speak, but I have no idea how the sugarCRM translator decided to translate "client_secret" and "client_id" to Spanish and I don't know which ones are their values. Also, values for "platform" are "base", "mobile" and "portal". Which on is for which uses? Whichever I use, I keep getting the same error.

Any help will be greatly appreciated.

Thanks

  • 0

    Hi Luisa Castano,

    I encourage you to review this document for details directly from SugarCRM about this if you have not already.

    I hope this helps.

    If the instance is hosted by SugarCRM, a support authorized contact can file a support case to have a technical resource confirm REST v10 API authentication to the instance is possible using Postman and confirm whether there are any instance-specific considerations to consider.

  • 0 in reply to Patrick McQueen

    Hi Patrick,

    thanks for your answer, but it is not Postman. As you can see, it is a bash command which I am using. Actually, the exact same one recommended in the document you linked. The information regarding client_id and client_secret are:

    client_idStringThe client_id of "sugar" will automatically create an OAuth Key in the system and can be used for "password" authentication. The client_id of "support_portal" will create an OAuth Key if the portal system is enabled and will allow for portal authentication. Other client_id's can be created by the administrator in the OAuthKeys section in the Administration section and can be used in the future for additional grant types, if the client secret is filled in, it will be checked to validate use of the client id.
    client_secretString

    The client's secret key

    As you can read, it only says the client_id can be changed in the OAuthKeys section, but it does not state how, and you can see in the screenshot of that section that there is no section called client_id or anything similar in Spanish.

    Thanks, though.

  • 0 in reply to Luisa Castano

    Hi Luisa,

    I believe there is something malformed with the cURL request you are using. I think some of the quote characters are using are not ASCII (neutral quotes) and there are some left and right quote characters (U+201D) which would not be interpreted properly as valid JSON. When I try your cURL request I get the same error, but the following cURL request works fine for me.

    curl -X POST \
      localhost:8080/.../token \
      -H 'Cache-Control: no-cache' \
      -H 'Content-Type: application/json' \
      -d '{
        "username" : "admin",
        "password" : "admin",
        "client_id" : "sugar",
        "grant_type" : "password",
        "client_secret" : "",
        "platform": "base"
    }'

    Sugar only supports a limited part of OAuth 2.0 protocol for our REST API. The documentation suggests that there could be other OAuth 2 grant types but Sugar does not support them at this time. It is on our current roadmap and development work is in progress to implement a new identity management system for Sugar that will provide better support for more OAuth 2 grant types that will provide server to server authentication as well as delegated authorization (3 legged OAuth support).

    The parameters "client_id" and "client_secret" are not translated or changed when using Sugar in any other locale. They are fixed.

    You should not deviate from the example given to you where "client_id" is "sugar" and "client_secret" is blank.

    App Ecosystem @ SugarCRM

  • 0 in reply to Matt Marum

    Hi Luisa,

    Matt's response has the answer for your issue but not, I think, the exact cause. I too get that Bad Data error when using curl on the bash CLI (from Ubuntu) if I forget to explicitly state the content type.

    So in Matt's answer, I believe including the 

    -H 'Content-Type: application/json'

    section is what is making the call work rather than fixing any non-conforming characters. That is what I have found anyway.

    Took me ages to work it out the first time I was hit with it. I still get it cropping up from time to time when I lazily copy-and-paste bash commands from a previous piece of work without realising I have not used the correct one

    Good luck with your integrations with Sugar. If you get stuck again at all you'll find the community in here very helpful generally.

    Thanks,

    JH.

  • 0 in reply to Matt Marum

    Hi Matt 

    Are you able to confirm if the situation has changed since your reply to this please?

    Thanks in advance.

    .

    CRM Business Consultant

  • 0 in reply to Vincent Amari

    Situation is mostly unchanged. SugarIdentity (in Sugar Cloud) supports 3 legged OAuth but doesn't yet support registration of 3rd party apps. Once we support 3rd party app registration, then you'd be able to use the 3 legged auth grant types.

    App Ecosystem @ SugarCRM

  • 0 in reply to Vincent Amari

    Hi , just checking something on this one. We have a 3rd party currently linking into a CRM of ours. I've set them up with an OUATH via /#bwc/index.php?module=OAuthKeys&action=index.

    My thinking was that if they are using the sugar OUATH to generate the auth key, then if another party (myself or any of the main devs) generate using the same oauth login, we'd then cause the auth key being used by the 3rd party to be wrong and fail potentially.

    Is there a reason that you suggest to just use "sugar" and "blank" for 3rd partys when this option exists?

    Thanks,

    Daniel