We are using Azure Data Factory to source data from an On-Premise JIRA installation. I've managed to get a number of pipelines to work using the JIRA API, but am hitting a wall when trying to source the Organization object.
There's an undocumented API call that can be made, though:
/jira/rest/servicedeskapi/organization
This will display the following message when attempting to run from a browser:
"This API is experimental. Experimental APIs are not guaranteed to be stable within the preview period. You must set the header 'X-ExperimentalApi: opt-in' to opt into using this API."
Using Postman, I set things up with the additional header, and I manage to get a resultset:
Using the same ADF copy data job I used for all my other API Calls, however, does not seem to work. I'm using the "Additional Headers" field to add a Bearer token we retrieve from our keyvault, like so:
#{concat(
'Authorization: Bearer '
, activity('Get Bearer token from Keyvault').output.value
)}
This works fine for all other API calls. I figured adding the extra header would be as simple as simply appending another line like so:
#{concat(
'Authorization: Bearer '
, activity('Get Bearer token from Keyvault').output.value,
', X-ExperimentalApi: opt-in')
}
However, that ends up throwing an error:
"ErrorCode=UserErrorInvalidHttpRequestHeaderFormat,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Failed to set addtional http header,Source=Microsoft.DataTransfer.ClientLibrary,''Type=System.ArgumentException,Message=Specified value has invalid HTTP Header characters.
Parameter name: name,Source=System,'"
I tried wrapping double quotes (and escaping them) around the key/value pairs, but that did not work. I tried removing the comma, but somehow that leads to the REST API thinking the extra header is part of the Bearer token, as it then throws an "Unauthorized" exception.
I can get the API to return data if I use a WEB component without any issues, but it'd be nice if I somehow would get this to work within the Copy data activity.
Any help is greatly appreciated!
The approaches that are tried to achieve this might be the incorrect way to provide multiple headers while using copy data activity.
I have used HTTP source with a sample URL which accepts Authorization: Bearer token. However, giving additional header (even though it is not required) is working same as using just Authorization header.
To pass multiple headers, pass each header separated by a new line. I have used the dynamic content with string interpolation (#{...}), instead of using #concat.
Authorization: Bearer #{pipeline().parameters.token}
X-ExperimentalApi: opt-in
You can see the following debug input how the additional headers are passed.
As an alternative, since there are only 2 headers to be given, you can configure the Authorization in the linked service itself and use the X-ExperimentalApi as a single additional header in Additional Headers section of the copy data activity.
Related
Is it possible to dynamically (automatically) set request headers for REST request using Postman Interceptor? We are currently setting multiple headers for each new request in a collection manually, we'd like to automate this if possible. How to achieve and please provide an example? thanks in advance.
p.s. I am not talking about writing a pre-request script unless we can write a global script that will be automatically used when we create each new request. The solution needs to be fully automated so we don't need to manually write the header key/value pairs for each new request. The key names will be the same each request and the values will be the same as well (environment variables).
using v4.10.7 of Postman for Mac.
I need to setup HTTP headers (Authorization) on the REST Client (Post method) in Pentaho. But whenever I supply Field=Authorization and Name=Basic ASDFjfhnsdfjjfh34jbsdaAKJFasdfioHJ= in the headers section, it is not working properly.
Below is the error message
Error finding field [Authorization] in incoming stream!
Can some one please help?
Found the trick. Pass on the Authorization header as a parameter to the REST Client. Then use that variable inside the Headers field. We cannot provide it directly since it expects them to be sent forward rather than initiated within the REST Client.
In order to accomplish this and pass authentication to the header, you have to add the Authorization request header to the "Generate Rows" step (which should be one of your first steps before your REST Client step) as another field. Then set the type to "String" and then the value to the actual authentication value. Then in the "REST Client" step, go to the Headers tab and add "Authorization" in BOTH the Name and Field columns for row 1, or click "Get Rows" and remove everything but header info that you need.
This could be WAY easier in my opinion but this is how you have to pass it in.
Hey guys I am trying to call Docebo's REST APIs and I am finding it hard to understand the method for it. Basically, Calling an API requires you to place an X-Authorization Parameter in the request header. The Docebo documentation on implementing this is just a paragraph that is very confusing to read. A similar question has been asked and answered here :
Docebo - constructing authorisation header
I read the code but couldn't quite grasp the explanation as there was little and the code very difficult for me to understand. I have two questions-
1)What is the X-Authorization parameter?
2)How does one compute the X-Authorization parameter to add to the request header to make calls to the Docebo API?
Detailed explanation of how the code works would be great! Thanks in Advance!
Hey I finally figured it out.
What is the X-Authorization parameter?
It is the parameter that has to be added to the header of the request. This header is used to authenticate the call to an API and the server first checks for this parameter to know whether the call is coming from a trusted source. This kind of requests that have a custom X- headers are called pre-flighted requests that require the sender to first send an HTTP OPTIONS request. The server responds with a list of allowed actions that can be performed. Only if the origin(of the sender) is allowed to have the specific header/Have access to the server resources, the request is actually executed.
How does one compute the X-Authorization parameter to add to the request header to make calls to the Docebo API?
It is as follows :
First take a look at the API documentation of Docebo for the specific API you want to call. It will have a list of parameters that the call requires. Then, you need to have the API keys from docebo handy since both of them are used in generating this X-Authorization parameter.Then proceed as follows :
1)Suppose you have n parameters that the call needs.Do the following :
SHA1 encoding of the following string between the brackets - (param-1,param-2,param-3.....param-n,secretKey).Don't forget the commas! Take the SHA1 hash generated in this step and proceed to step 2
2)A UTF-8 base64 encoding of the following string between the brackets-
(PublicKey:hash from step 1).Again, don't forget the colon! and you will obtain an alphanumeric string.
3) The X-Authorization parameter is - Docebo code(notice the space between Docebo and the code).
4)Add the parameter named X-Authorization to the request header before sending it and you will receive the response.
Hope this helps..
CONTEXT:
I have an Ember.js 1.1.0-beta.1 application that exchanges JSON data with a Rails-API server (Rails 4). JSON data exchange is accomplished with Ember-Data 1.0.0-beta.2 and Active Model Serializers 0.8.1 (AMS). I'm using the default recommended configurations for both Ember-Data and AMS, and am compliant with the JSON-API spec.
On any given RESTful call, the client passes the current authentication token to the server. The authentication token is verified and retired, and a new authentication token is generated and sent back to the client. Thus, every RESTful call accepts an authentication token in the request, and provides a new authentication token in the response that the client can cache and use for the next RESTful call.
QUESTION:
Where do I put the authentication token in each request and response?
Should it be part of each object's JSON in request and response? If so, where is the token placed in the existing object's JSON structure (which has nothing to do with authentication)?
Or should they be placed in the HTTP header for each request and response object?
What is "The Ember Way" that one might eventually expect to find in the new Ember Guides Cookbook?
MORE CONTEXT:
I'm already familiar with the following links:
#machty 2 Embercasts: http://www.embercasts.com/episodes/client-side-authentication-part-2
#wycats tweet: https://twitter.com/wycats/status/376495062709854209
#cavneb 3 blog posts: http://coderberry.me/blog/2013/07/08/authentication-with-emberjs-part-1
#simplabs blog post: http://log.simplabs.com/post/53016599611/authentication-in-ember-js
...and am looking for answers that go beyond these, and are specific to Ember-Data + AMS.
With the exception of the need to pass a new token back to the client in the response via Ember-Data, assume my client code is otherwise similar to the #machty Embercast example on GitHub: https://github.com/embercasts/authentication-part-2/blob/master/public/js/app.js
Thank you very much!
I've got a similar stack - ember, ember-data and rails-api with AMS. Right now, I'm just passing the authentication token (which I store in localStorage) in a header (though you could pass it on the query string) by modifying the RESTAdapter's ajax method.
My initial thought would be to avoid resetting the token on every request. If you're particularly concerned about the token being sniffed, it might be easier to just reset the token on the server at a regular interval (say, 10 minutes). Then, if any request from the client fails due to an old token, just fetch the new token (by passing a'reset token' that your server gives you at login) and replay the initial request.
As for where to put the token, there isn't really an "Ember Way" - I prefer passing it in a header since passing it in the query string can mess with caching and is also more likely to be logged somewhere along the way. I'd definitely avoid passing it in the request body - that would go against what ember-data expects, I'd imagine.
I have built something similar, although I do not reset the token unless the user signs out.
I would not put it in the request body itself - you are just going to pollute your models. There probably is no Ember way since this is more of a transport issue. I pass the token using a custom HTTP header and/or a cookie. The cookie is needed to authorize file downloads, which can not be done through ajax, although the cookie works for ajax calls too. In your case I would use a cookie and have the server set it to the new value each time. However, your scheme of resetting the token on each JSON request is not going to work on simultaneous requests. Is this really necessary? If you use TLS you probably don't need to worry so much. You could also timeout the token so that if there are no requests for 10 minutes a new token is generated.
i've been researching/creating a REST api, in the backbone.js to php context.
i understand the concept of HTTP verbs and when they should be used
GET - select
POST - create
PUT - update
DELETE - delete
i also understand the concept of passing an identifier as a semantic url, e.g.
GET http://api/users/123
DELETE http://api/users/123
in these cases the "123" is the id the business logic will use to get/delete a user.
but what about the POST and PUT contexts? when sending a request to
PUT http://api/users/123
the api will update user id 123 with the supplied parameters, here's where my question arises.
i would assume the input parameters to update with would be sent as PUT parameters. in php syntax this is represented as: file_get_contents('php://input') (this is the same for delete requests.)
when testing this via backbone.js it works perfectly.
but when i try and create a new element with
POST http://api/users/
i would assume the input values would sent as POST parameters/ in php syntax this is represented as $_POST. but this does not work.
after some testing, and reading up on rails style REST apis (which is what the backbone docs suggest), i realized that all request variables are sent the same way. if i change my code to use file_get_contents('php://input') to get the request parameters for every request type, backbone works perfectly.
is this standard fair for REST apis? or just "rails flavored" ones?
PUT, POST, PATCH, etc (everything but GET and DELETE*) accept request bodies. Generally data is passed as either:
A URL encoded string of name/value pairs (exactly the same as a URL querystring) that is decoded and parsed by the server into $_POST (or similar depending on your web framework of choice). This typically relies on the presence of a Content-Type header set to application/x-www-form-urlencoded (browsers do this by default when forms are submitted). If you see the data in file_get_contents('php://input') but not $_POST it's very likely this header is not present or is set to another value. If you're using Chrome, you can see what headers and body the client is sending in the Network tab of the dev tools.
The other popular request body format is to use Content-Type: application/json and then write out a JSON string to the body. This can be accessed via file_get_contents('php://input') and then parsed with a JSON parser.
* Note on DELETE: it's a little unclear whether or not using a request body with DELETE is allowed or a good practice.