So I have implemented the Asana Webhooks API as described in their documents. I can pass it a project ID and request a new webhook be created. The API successfully sends a authentication request to my application which returns the Security header as described in the Docs. Asana then returns the expected success response, outlining the newly created Webhooks unique ID.
Now if i take this ID and then query the Asana API to show me all configured webhook's on either the parent Workspace or the project resource directly it returns an empty data JSON Object or reports the resource doesn't exist, suggesting the Webhook Ive just created wasn't actually created, despite giving me the expected success response.
Also If I then make a change to a project it doesn't fire the webhook and I don't receive any events on my application.
Strangely everything was working on Friday but today (Monday) I'm experiencing these issues.
Any pointers would be good, Ive been working as the Docs suggest in terms of my request structure and am authenticating using a PAT, Ive even tried a newly created token.
Thanks,
Our webhooks use the handshake mechanism to make sure that it's possible to call you back, but there's always the possibility that subsequent requests can fail. Additionally (although we don't document this very well - there's an opportunity for us) we should immediately try to deliver a (probably) empty event after the handshake (it looks like {"events":[]}. This is kind of like a "second callback" that contains anything that has changed since you created the webhook.
If this fails - or if any subsequent request fails often enough - the webhook will get trashed. "Failure" in this context means returns HTTP response codes other that 200 or 204.
As for why you're having trouble querying the webhook itself, I wasn't able to repro the issue, so we'd have to dive deeper. It should be fine if you:
Specify the workspace
Optionally specify the resource
I tested this out, and it seemed fine. You also might want to directly query the webhook by id with the /webhooks/:id endpoint - note to use the id of the webhook returned by create, and not the id in the resource field.
If you created the webhook (specifically, your PAT or OAuth app was the one making the create request) you should see the information just fine. If you can get the webhook by id, you should see last_failure_at and last_failure_content fields which would tell you why the webhook was unable to make the delivery.
Finally, if you would like to contact us at api-support#asana.com and let them know more details (for instance, the ID of the webhook you're trying to look at) we can look at those fields from our side to see if we can identify what's going on.
Related
I am running Jira on docker. And making a simple rest API call to make a new project.
But I am getting an error "You must specify a valid project lead".
I AM indeed specifying a valid user called "userOne" that I have made on my server.
Can someone help me out what the problem is?
I have attached a picture of the POST request that I am making
and the response that I am getting.
Additionally: the user that I am trying to make as a the lead is an ACTIVE user,
The screeenshot for that is attached below too.[in case that is something that can cause problems]
userOne is the full name of your user. The endpoint is expecting the username (which is unique across the whole instance), try changing it to user1.
I am trying to build a Custom Connector in the Power Platform to connect to the BMC Helix (formerly Remedy) system to create work orders and such. I am using OAuth2 and was given a callback URL, auth URL, token URL, client ID and client secret.
I went to create a connector from scratch. I populated the fields, but I wasn't sure what to put for the 'Refresh URL', so I used the token URL there too.
I am trying to accomplish testing this connector and my successful test would be to get a JWT from doing a POST to the /api/jwt/login endpoint of BMC Helix. It should return a JWT which I can use to make subsequent calls.
Upon testing this, I go to create a connection, but a window opens (which I believe should be a prompt for authentication), but instead it contains an error saying 'unauthorized_client' coming back from the BMC Helix system at the /rsso/oauth2/authorize endpoint. It also contains a property within the URL of redirect_uri = https://global.consent.azure-apim.net/redirect.
Is there something on the Helix side I need to further configure? Not sure why I am getting this....
It sounds like you need TWO METHODS in your connector. A POST to call the token server, a GET (or another POST) to call the API (using the token received from Call 1).
One approach I've successfully used in the past is:
Use Postman to get your token server call working with OAUTH
Then use Postman to get your subsequent API calls working with the token appended
Save both requests to a single Postman collection
Export the Postman collection (as a V1 (deprecated) if I recall correctly)
Import this collection into PowerApps Custom Connector (create new/import from Postman Collection)
You'll have to massage it a bit after import, but it will give you a good headstart and you're starting from a known-good place (working Postman calls)
Good luck!
According to the documentation of the recent refactoring switch from user/team-based API to the workspace-based API, webhook payloads will soon have the owner property removed. Also according to this documentation, the webhook payloads already contain the workspace object:
The webhook payloads I receive do still contain the owner object (i don’t really care for that though), but they do NOT contain the workspace object. Is this wrongly documented, do I need to setup the webhook differently than before or what is going on here?
This is now an official bug. You can follow the public ticket here:
https://jira.atlassian.com/browse/BCLOUD-20239
In the meantime, I added the workspaceUuid as GET parameter to the URL that the webhook is calling. This way I receive it together with the webhook payload on my server for processing.
I am attempting to use the REST api of Jenkins. Jenkins requires a POST request to a URL to delete a job. This results in the following:
I tell my chosen Client to send a POST to the appropriate URL.
The client sends a POST and authorizes itself with username and password.
Jenkins deletes the job.
Jenkins returns a "302 - Found" with the location of folder containing the deleted job.
Client automatically sends a POST to the location.
Jenkins answers with "200 - OK" and the full HTML of the folder page.
This works just fine with Postman (unless I disable "Automatically follow redirects" of course).
Jersey however keeps running into a "404" at step 5 because I blocked anonymous users from viewing the folder in question. (Or a "403" if I blocked anonymous users altogether.)
Note that the authentication works in step 1 because the job has been deleted successfully!
I was under the impression that Jersey should use the given authentication for all requests concerning the client.
Is there a way to actually make this true? I really don't want to forbid redirects just to do every single redirect myself.
To clarify: The problem is that while Jersey follows the redirect, but fails to authenticate itself again, leading to the server rejecting the second request.
Code in question:
HttpAuthenticationFeature auth = HttpAuthenticationFeature.basicBuilder()
.credentials(username, token)
.build();
Client client = ClientBuilder.newBuilder()
.register(auth)
.build();
WebTarget deleteTarget = client.target("http://[Jenkins-IP]/job/RestTestingArea/job/testJob/doDelete")
Response response = deleteTarget.request()
.post(null);
EDIT: The "302-Found" only has 5 headers according to Postman: Date, X-Content-Type-Options ("nosniff"), Location, Content-Length (0) and Server. So neither any cookies nor any tokens that Postman might use and Jersey disregard.
Question loosely related to this one - if I were able to log the second request I might be able to understand what's happening behind the scenes.
EDIT2: I have also determined that the problem is clearly with the authentication. If I allow anonymous users to view the folder in question, the error disappears and the server answers with a 200.
I found the answer with the help of Paul Samsotha and Gautham.
TL;DR: This is intended behavior and you have to set the System property http.strictPostRedirect=true to make it work or perform the second request yourself.
As also described here, HttpURLConnection decided to not implement a redirect as it is defined in the HTTP standard but instead as many browsers implemented it (so in laymans terms, "Do it like everyone else instead of how it is supposed to work"). This leads to the following behavior:
Send POST to URL_1.
Server answers with a "302 - Found" and includes URL_2.
Send GET to URL_2, dropping all the headers.
Server answers with a "404 - Not Found" as the second request does not included correct authentication headers.
The "404" response is the one received by the code, as steps 2 and 3 are "hidden" by the underlying code.
By dropping all headers, the authentication fails. As Jersey uses this class by default, this lead to the behavior I was experiencing.
I'm using the one-time code flow with my google+ sign in button implementation, but the user_id in the response from the tokeninfo endpoint doesn't match the id_token in the object my javascript my javascript callback receives from the sign in buton.
In the sample code in the documentation, the the user_id in the tokeninfo object is checked against a request parameter called gplus_id, but the sample javascript doesn't send this parameter, so I have no idea if I'm checking against the right thing.
So, to be clear about the particular sections of code I'm talking about:
The one-time code is processed on the server using this sample code, and it uses a request parameter called gplus_id.
The code in this section sends the one time code to the server, but as I can see, it doesn't send a gplus_id
It looks like step 6 on the example page is incomplete, and is supposed to be sending the gplus_id, but isn't.
Take a look at the connectServer function (and the function that calls it) in https://github.com/googleplus/gplus-quickstart-java/blob/master/index.html for a more complete example of how to get the user's ID and pass it to the server for verification.
(And I'll try to ping the people responsible for the documentation to get it updated and consistent across the platforms in the quickstart examples. You can also track bug 573 to see progress on them fixing the documentation.)
NOTE: It is worth noting, however, that sending the gplus_id is a bit redundant. You're already trusting the code sent from the client, and you're getting the ID through steps derived from the code. So while passing and checking the gplus_id is a nice sanity check, it really doesn't gain you any additional security.