I have created a sandbox account for using Docusign APIs. As a first step of it... see the link of tutorial I am trying to Send an electronic signature request via email (topic no. 4 in the link)
My request url and parameters are as specified. But it is giving ERROR 401 Unauthorized
I am seeing in Request screenshot, you are I think passing IntegratorKey (16a82645-5c5a-****-****-***********) in the Authorization Header, which is wrong. In Authorization header you need to pass OAUTH token. You can generate OAUTH token with below steps:
There will be an UnAuthenticate link on the top of the page with green background, text will look like below
You are authenticated against the Demo environment. Unauthenticate,
So, can you please click "Unauthenticate", then it will show button as "AUTHENTICATE USING SANDBOX ACCOUNT", once you click this button then a popup will come and it will have a blue button as "GET OAUTH2 TOKEN", click this button, which will open a popup and ask you to enter your Demo/Sandbox credentials. Enter your credentials and then try above API call, it should work. If it does not may be some stale cookies/session will still send old credentials to DocuSign so then try it in Incognito or Inprivate browsing.
Related
I am new to APIs and have made my first OAuth 2.0 calls to the Vimeo API.
I was able to reach the Vimeo login that allows authorization. However, when I login with my username and password, I am not able to click "allow". I've tried both Postman and Insomnia clients and get the same issue. If I click "Don't Allow" the window simply turns blank. I'm wondering what might be causing this hang-up where I cannot click "Allow" and get back my access token
Image of Window (Insomnia Client).
Please let me know if you need any code or more images in order to troubleshoot.
Thanks from a newbie,
-Josh
Could you open a ticket here, https://vimeo.com/help/contact.
We'll need to triage this with your account info.
I will explain the scenarios here
1) When user click on link facebook button facebook permission dialog is bypassed and returns back directly on redirect uri(http://localhost:3000/ in my case) with code and state.
2) I am successfully able to exchange the code return above with access token.
3) I used facebooks access token debugger to analyze the token above and shows be proper scopes i need.
4) After this i fetch ad_accounts id, page token and page ids using this token.
5) when i use this token to create campaign for ads i get the following error.
FacebookAds::ClientError (Invalid parameter: Terms of Service Not Accepted (fbtrace_id: Ch/RdwGB+D3))
I use ruby facebook-business-sdk.
My app is in development mode and not live yet.
I can see both facebook login and marketing api green live in my app dashboard.
It makes sense to me that i am getting "Terms not accepted error" as user is never prompted to permissions dialog to permit my app for token.
I also observed that if add scope params to facebook login uri, the user is prompted to permission dialog.
I must be missing some configuration here, i have not yet submitted my app for review.
Any help/clue is appreciated.
Slack provides the ability to make a Direct Install to install your application.
When you save your Direct Install URL, Slack will attempt to send a simple HTTP GET request to your declared URL. If it doesn't detect a HTTP 302 redirect pointing back to a fully qualified slack.com/oauth/authorize URL (see below), you'll receive an error letting you know.
...
First Slack sends the user to your Direct Install URL:
GET /slack/direct_install HTTP/1.1
Host: example.com
Then your server kindly redirects back to Slack's OAuth 2.0 authorization page:
HTTP/1.1 302 Found
Location: https://slack.com/oauth/authorize?client_id=12345.67890&scope=channels%3Ahistory%20users%3Aread&state=abcdefg
Resulting in the user jumping right into authorization. One point of friction removed.
You may continue to generate your own time or context sensitive state parameters and specific, pre-registered redirect_uri values as needed.
How does this integrate with my own apps user authentication? As I read it, the Direct Install URL must always 302 redirect to the Slack OAuth page. If the user isn't logged in to my application when they click the "Install" button, what am I meant to do?
My best guess is that I should:
Always redirect to the Slack OAuth URL and generate a state parameter to keep track of the request.
When the user finishes their authentication, they are redirected back with the code and state parameters.
If they aren't logged in, ask them to log in, and retain the OAuth code and state parameters. Once the user logs in, continue with the OAuth authentication process.
Is that right? Is there a way to force the user to be signed in to my app before trying to install the Slack app?
On a security note, for this to work with session cookies, I think they would need to be set to SameSite=lax, not =strict. The cookie wouldn't be passed from a cross domain request when they are set to strict.
I think you have a couple of options:
1) Don't use it.
The "Direct install" feature is a shortcut to the standard "Slack Button" installation process. Since in your case the user needs to first log into your app anyways, I think it would be more user friendly to also provide the Slack button in the same context on your webpage.
2) Return an error
If you detect that the user is not logged into your app, you could just return an error to Slack, e.g. http code 500. Slack should then also return an error to the user (not sure how it looks though). If you combine that with a clear message on your Slack App install page about the requirement to first login to your app that could work. This would be the easiest to implement, but also the least user friendly approach.
3) Request login to app after Slack login
After you completed the Oauth process and recognize that the user is not logged into your app you could request the user to login to complete the installation process. The disadvantage here is that your app would already be installed and could be left in an unusable state if the user failed to login at this point.
4) Halt Oauth process for user login
As you suggested you could halt the Oauth process after receiving the authorization code and request a user login to your app. Then continue the Oauth process after a successful user login. This can work if you need to take into account that the authorization code will expire after 10 mins. I do not see any way of forcing the user to login before he clicks on the direct install button.
I want to use the Instagram API to show my own content on my own website. I can see in their documentation that content owners can display up to 20 pieces of media on their site while the app is in Sandbox mode.
I've created an app on my account and I am trying to use their Client Side Implicit Authentication to generate an access_token.
I hit this URL and login to my account:
https://www.instagram.com/oauth/authorize/?client_id=MYCLIENTID&redirect_uri=www.mysite.com&response_type=token
When I submit the login form, I am brought to an Instagram 404 page that says:
Sorry, this page isn't available. The link you followed may be broken, or the page may have been removed. Go back to Instagram.
What am I missing? Do I even need an access_token? Before they changed their API last November I was able to use just the client_id in my requests. I suppose that's not possible anymore?
I think you need to include http://.../ for your redirect_uri. So it would be: https://www.instagram.com/oauth/authorize/?client_id=MYCLIENTID&redirect_uri=http://www.example.com/&response_type=token
But of course that means you will also need to add http://www.example.com/ as the Valid redirect URIs in "Manage Clients" on Instagram.
I am learning to use dropbox APIs and got confused when came up with the token flow.
As guide indicates, the flow should be like this:
the app redirect the user to a Dropbox webpage, i.e. .../oauth2/authorize
user logs in and approves the app
redirect back to the app. At this point, the app gets an access token.
However, when i requested the URL:
.../oauth2/authorize?client_id=xxx&response_type=token&redirect_uri=xxx
I was directly redirect to the destination with
REDIRECT_URI = "#access_token=xxx&token_type=bearer&uid=xxx"
And the "approve step" was skipped, i.e I got an access token without being allowed.
Is it a bug or my fault?
Any help would be appreciated :]
In certain cases, when the user has already approved the app to access their account previously, they will be automatically redirected through the app authorization flow.
If you want, your app can prevent this behavior from happening by using the force_reapprove parameter, documented for the /oauth2/authorize page here:
https://www.dropbox.com/developers/core/docs#oa2-authorize