I am trying to deploy a Backend API on Wso2-APIM 2.6.0. This Backend API has its versioning in endpoint.
/v1/devices
Now if I add version while creating Wso2 API (coz Version field is mandatory), I will end up having two versioning mechanism in my URL.
curl -k -X GET "https://88.8.88.88:8243/device-management-api**/1.0/v1/**devices?limit=20&page=0&sort=id%2Cdesc" -H "accept: application/hal+json" -H "Authorization: Bearer AAA"
Is there a way I can not specify version in wso2? I guess I should be able to make changes to synapse-config to do the same.
Can someone please point me to the right location?
I am sure this is a very common issue everyone come across.
How do developers get around it? What is the norm in the industry?
Option 1 (recommended):
When you configure the endpoint for the API, configure it with the backend version included. Eg. Set the endpoint like this.
https://xxx.xxx.xxx.xx:yyyy/device-service/v1/
Then you can drop the "backend" version when you invoke. Eg.
https://88.8.88.88:8243/device-management-api/1.0/devices
This is recommended because you shouldn't expose the backend version to the user. Instead what you should expose is the APIM's API version.
Option 2:
Tick the Default version in the manage tab.
Then you can drop the version when you invoke. Eg. Both of these will work.
https://88.8.88.88:8243/device-management-api/v1/devices
https://88.8.88.88:8243/device-management-api/1.0/v1/devices
Related
We got strange behavior on API Manager.
We updated our API's swagger file inside WSO2 Publisher. And we deployed it to our dev environment. It has only 2 resources. Everything was working, we can send requests to our gateway endpoint url and we can get responses as expected.
Then, we just wanted to add only a "s" letter to one resource's path. We updated the swagger in WSO2, also we deployed our API in our dev env again. Now, this resource doesn't work with new path name. It responses as shown in the picture. Other resource is working. But this not. Strangely, it works by using our service endpoint url directly. We found a solution by creating a new 1.0.1 version of same API. Now all resources are working. If we downgrade the version to 1.0.0, again this resource doesn't work.
I'm exactly sure there is no line shifting, missing character, missing tabs or etc. I see the resources on preview on API definition page.
What is the problem? Is this a bug? I think the 1.0.0 is storing on somewhere like cache or etc.
I am using WSO2 API Manager (version 3.0.1) as front-end for accessing data via an API call to CKAN (version 2.8.2).
A private CKAN data set requires an authorization token as described here.
"When calling an API function that requires authorization, you must authenticate yourself by providing your API key with your HTTP request."
How is this accomplished in WSO2? Specifically, what configuration files/settings need to change to make this happen?
I see from this documentation that if configured in Eclipse using a tooling plug-in it can be accomplished with something like this (Step 23):
curl -k -H "Authorization: Bearer api-key-for-WSO2-goes-here" -H "Custom: Bearer api-key-for-CKAN-goes-here" https://my-wso2-host-goes-here:8243/test/1.0.0
However, these instructions require using Eclipse. But how can this be accomplished without Eclipse? I.e. what configuration files/settings need to be modified on the server or in the WSO2 API Publisher and/or the WSO2 API Dev Portal to pass the authorization token for CKAN through WSO2 API-M?
You do not have to use Eclipse for this. In the tutorial Eclispse plugin is used as a tool to generate the sequence easily. In that tutorial we needed a sequence
in the first place because the authorization header required by the backend is "Authorization". In WSO2 APIM this is a reserved header to pass the internally generated token. Therefore we first pass the backend token in a custom header with a different header name and then copy this value to Authorization header in the in-sequence.
The sequence would look like below.
<sequence xmlns="http://ws.apache.org/ns/synapse" name="authorization_header_exchange">
<property name="X-Authorization" expression="get-property('transport', 'X-Authorization')" scope="default" type="STRING"/>
<property name="Authorization" expression="get-property('X-Authorization')" scope="transport" type="STRING" description=""/>
<property name="X-Authorization" scope="transport" action="remove"/>
Refer [1] for more info.
However in your case you can send the api key in X-CKAN-API-Key along with the request itself without using a mediation sequence.
[1]. https://docs.wso2.com/display/APICloud/Sample+Mediation+Sequences#SampleMediationSequences-Passinganauthorizationheadertoyourbackend
I'm answering my own question...
TLDR
The answer by #naoko above is correct: to pass CKAN authorization through WSO2 API-M include X-CKAN-API-Key as a header with a value set to your CKAN user's private CKAN API key.
Long Version
Pass the CKAN API key like this:
curl -k -H "Authorization: Bearer wso2-app-key-here" -H "X-CKAN-API-Key: ckan-authorization-key-here" https://myWso2DeveloperPortal.com:8243/daas/3.0.1/action/resource_show?id=resource-id-of-CKAN-dataset-here
(Use -k if the host has a self-signed https certificate)
Where...
wso2-app-key-here is the application key found in the WSO2 Developer Portal.
ckan-authorization-key-here is your user account's private key in CKAN. (It can be found on your user profile page in the CKAN UI.)
resource-id-of-CKAN-dataset-here is the resource id of the dataset you want to query.
The resource_show method in this example will return metadata for the given CKAN resource. Other CKAN methods are invoked in a similar manner.
This is all thanks to CKAN for having an alternative to passing the key in a header named Authorize. In the case of CKAN, the variable X-CKAN-API-Key can be used. And this can be easily passed as shown above.
Mea culpa for not catching that in the CKAN docs in the first place (It's right there in my very own screenshot above!)...had I read thoroughly it would have saved a SO post for better or worse;)
Had CKAN not provided the alternative with X-CKAN-API-Key then this can be accomplished in version 3.0.0 as described in these pages:
"Passing a Custom Authorization Token to the Backend"
https://apim.docs.wso2.com/en/latest/Learn/APIGateway/MessageMediation/passing-a-custom-authorization-token-to-the-backend/
FWIW, I actually tried that before trying the X-CKAN-API-Key solution and it didn't work. Maybe I was doing something wrong. But since the X-CKAN-API-Key solution works for me I'm calling it done.
I am setting up the native windows Postman and trying to run the "Request Header" api provided in Postman Echo collection. I get the following error.
"Error: tunneling socket could not be established, statusCode=407"
I can see in the postman console that it is picking up the correct proxy server from environment. My proxy server requires authentication, how do I provide credential information. I tried to start Postman using the following command but it did not help.
postman.exe --proxy-server=userName:password#myproxy:8090
Unfortunately the proxy tab in Settings does not allow authenticated proxies.
Entering proxy info in the format "userName:password#myproxy" will cause everything before the '#' symbol to be removed.
You may already know, but since version 5.2, Postman includes a "Proxy" tab into the "Settings" section.
You should be able to configure your proxy on your system (if you are using Windows you can do it in Internet Options>>Connections>>LAN Settings) and then enable the "Use system proxy" in this tab.
After testing this method is helpful：
Windows- create a postman.bat file with the following content:
set HTTP_PROXY=http://USER:PASS#host:port
set HTTPS_PROXY=https://USER:PASS#host:port
start C:\path\to\Postman.exe
as I get this from here
In the "Global Proxy Configuration" section of the Proxy tab, setting the "Proxy Server" value to -
userName:password#proxyHost:proxyPort resolves the issue.
I could solve this problem for Postman and also for other local tools that are not capable of NTLM authentication against a proxy.
The solution is the open source proxy service/demon CNTLM that runs under Linux, macOS and Windows. The project has not been updated for a while but I could easily install and run it under Windows 10.
Best part is that it is able to check your proxy's capabilities and automatically find the latest NTLM version that the proxy supports.
http://cntlm.sourceforge.net/
You can add Proxy-Authorization header with value Basic base64encode($user:$password)
launch postman through :
vagrant#localhost:~/Downloads/Postman-linux-x64-7.6.0/Postman/app$ ./Postman
and set/unset proxy values
I am trying to use the Call SOAP HTTP Service UTF8 component to call the webservice in AbInitio graph.
But an additional header, X-Authorization is mandatory and needs to be passed.
From the WSDL, I have imported, I can see the SOAP env and body schema but cannot find a provision for passing the X-Authorization parameter.
Can someone please advise on how this can be achieved?
Please let me know if you need further info
On the graphic interface of the soap web service I know (obsolete oc4j), there is an auth. part to fulfill:
If using wget, then add --user ... --ask-password ....
wget --user <my user> --ask-password <my url>...
I need to specify HTTP 1.0 in a POST request via Postman. It defaults to HTTP 1.1. Does anyone know how to specify the version of the HTTP protocol, or am I out of luck?
Unfortunately, it's still not supported by Postman as of April 2019. Previous version of Postman used to be a browser extension and it wasn't possible to fine tune the request. Newer versions, however, run as standalone applications which could allow more low-level control of the request.
See the following comment quoted from the issue #6242 which was opened early April 2019 requesting an option to specify HTTP protocol version:
You'll be pleased to know that work is in progress for more low-level control over the request. Stay tuned.
As of June 2022, however, Postman haven't shared any updates on this.
Depending on what you need, you could use curl. It provides a set of options that allows you to control the version of the HTTP protocol:
--http0.9: Tells curl to be fine with HTTP version 0.9 response.
-0, --http1.0: Tells curl to use HTTP version 1.0.
--http1.1: Tells curl to use HTTP version 1.1.
--http2-prior-knowledge: Tells curl to issue its non-TLS HTTP requests using HTTP/2 without HTTP/1.1 Upgrade. It requires prior knowledge that the server supports HTTP/2 straight away.
--http2: Tells curl to use HTTP version 2.
Apparently this is not supported by Postman. There has been a report for this on the project's Github page (issue), but it doesn't look like this is gonna be implemented any time soon.
There are a couple of alternatives that support HTTP protocol version for Rest and Soap testing:
Tosca Testsuite: Tosca includes Webservice testing for Soap and Rest. Setting the HTTP protocol version can be done in the Webservice TestCase creation.
SoapUI: SoapUI also supports setting the HTTP protocol version
Not supported as of this date. You can try to copy the curl code by clicking on the Code link, and run it, specifying the http version by passing --http parameter to curl.
For example, to run curl in Windows 10, replace the single quotes with double quotes:
curl --http2 --location --request GET "https://myrequesturl...." --header "myTestHeader:test" --header "Content-Type: application/json" --data-raw "{"query":"","variables":{}}"