Passing Body Content in Post Snap
Hi,
This is a very novice question, but I am having trouble with a post request snap. This is just to authenticate with the RingCentral platform to receive a token for API consumption. I am able to...
Forum Discussion
It appears to be an application permission issue, you can see those in the “Security” section below where you set your authentication, they have explanations for them all here but this is getting more into RingCentral-specific items, which I don’t have any real experience with, unfortunately.
Now that you have those items working, you MIGHT be able to get password auth working, I did some messing around with it, but again since I don’t have a working Sandbox Account, I can’t verify, that setup would be similar to this setup, but would require you to select “password” as your Grant type, in this case, I’m using a dummy phone number 555-555-5555, but for me even with my normal login credentials to the console, I don’t have it working and it seems to be due specifically to the account itself, not the application. The important piece here again is “Send Client Data as Basic Auth header” it’s what sends the client id and secret to the password endpoint within the header of the request. You’d have to go back to your old application for this to work and make sure you set the client id and secret appropriately for the request. This ONLY makes a call to the token endpoint, but I just used the same url for both the auth and token config.
For specific endpoints and permissions/scopes, you may need to look at that specific endpoint documentation to know specifically, but for instance, I don’t see “Edit Account” in my options, so my new account must not be set up well enough. for the Password setup. You might be able to add all available scopes from the “Security” section to your other setup to get it working fine, though.
Okay I get the same permissions error when switching back to a password grant type.
I have to stress that this does not happen when I follow the process in Postman, which leads me to believe that it is on the snapLogic side, or something between the data exchange specifically with the snapLogic post snap and RingCentral.
I also have to point out that this permission is not even an option in RingCentral. Finally the idea of just giving full permissions to the app in Ring Central is problematic, because in order to promote your app from the Sandbox to Production you have to test all permission scopes explicitly on top of meeting additional criteria before your app is eligible for promotion to production. So we really dont have the option of of giving a broad scope of permissions. Even if it did work, it leads to potential problems down the road.
Do we need to start looking at converting this thread into a ticket and escalating it?
As I was typing the ticket out, I realized that I was making an endpoint call using a POST snap that should have been a GET snap. With the type of account we used (an Ouath2.o account) I no longer needed the post snap at all. I did not realize that until now. The way we have always built these pipelines out is to setup a POST snap to get a token back, but this account type takes care of that for you
Once I compensated for that fact and switched to a GET snap with the same account, it worked as expected.
Thank you both so much for all of your help. I apologize for getting mixed up and hanging on to the POST snap like that and that it took me so long to realize what was going on at the end there.
Again thank you @ddellsperger and @ptaylor!
Best,
JamesHappy that we could resolve things, the OAuth2 Accounts are a little complex because there’s so much to them, but they’re very powerful with more and more services.
I still strongly suggest looking into the OpenAPI Snap if you’re going to be doing a lot of calls through RingCentral and are trying to do some investigating. There’s a link to the swagger specification which is OpenAPI compatible at the top of this page and you can simply use that OpenAPI snap and it provides suggestions for the paths within the spec in place with the methods that you need. You’d just have to update your redirect URI if you use
authorization_codefor the Open API OAuth account (ending inopenapirather thanrest).Are you setting the scope within postman? if so, you can add it as an auth endpoint config with
scopeas the key and the items you have in scope as the value. Forauthorization_code, I believe you’ll need it in both the token and auth endpoint configuration, it’s worth having it in both for password authentication just in case, but again their documentation doesn’t specify the scope anywhere from what I had seen.If this doesn’t work, or you’re not specifying the scope, I think escalating to a ticket might be beneficial.
No the permission scope is set in the application that you create on the RingCentral side and then you are provided with a client ID and secret for the application. Is there a way to convert this post to a ticket? There is a lot of relevant information here.
I think you could just link this thread in your ticket.
Sorry for the delay in response. Would the OpenAPI snap help us avoid some of the 401 errors I am still seeing on the RingCentral app analytic side? In order for an app to be promoted into production it has to have a <5% 4XX return code on all used end points for that app. I have this pipeline set to run every hour, but it looks like the call frequently fails with a 401, but then it retries and is successful, as best as I can tell.
Please let me know if this needs to be a different thread. I just noticed this morning that we are not meeting this last requirement.
Thanks,
JamesI would assume your 401 errors have corresponding failed pipeline runs, if that’s the case, you might be able to investigate the specific causes of those, but I don’t think OpenAPI vs. Rest would really help you there.
You could set the snap retry policy to include auth errors in addition to connection errors, but it all depends what the actual 401 error is that’s coming back, and there should be respective failed pipelines that might help to figure out the specific conditions that are failing.
that’s the thing. I don’t see any corresponding failed pipeline runs? Is there something I need to change to get it monitor at a “lower level”?
Because I chose password for the grant_type, I did not check the auto refresh token option. Could that be the reason I see 401 errors on the RingCentral side? It looks like the it retries 3 times on the SnapLogic side. So could it be the 401 is being thrown because it tries to use the token it already has, but it is expired, so then requests a new token and all we see on the SnapLogic side is a successful run because after getting a new token on the 2nd try, everything works.
you should have auto refresh enabled, it should still work with the password grant. You should still be getting a refresh token back from the request, you can confirm it with the account edit view, it should have
Value is encryptedfor the “Refresh token” like the below screenshot
Okay I enabled that yesterday afternoon. So far on the Ring Central side, the 401 errors have diminished. In fact today(03/18) there is a 100% success rate running that pipeline every 59 minutes.
This may be an obvious question and I think I know the answer, but just for clarification, with the auto refresh enabled does that enable a background process to run on the account to refresh the token at the needed interval to prevent the account from having an expired token (independent of the state of a specific pipeline that may utilize that account)?
yes, the process looks for all OAuth accounts that are nearing expiration or expired, with a valid refresh token and does the authentication token refresh. It does periodic checking and looks for tokens that will expire before the next check of expired tokens and will refresh all of those tokens accordingly. In the case of your situation, if it doesn’t refresh for 7 days (which is the max life of a refresh token) it would then have to start from the initial password token request.
