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
Related
I am doing a POC with my team as we are introducing WSO2 components and am working with the API Manager 3.0.
I seem to be having issues loading the WSO2 API Manager / API Publisher on the defined URL;
https://[ip address]/publisher
The page is not loading and I keep getting a spinning circle.
Steps I have taken:
Stop API Manager at command prompt with [Ctrl + C] command
Modified deployment.toml file specified paths for the localhost to our IP Address, API [publisher, gateway and store] URL values to use our IP Address as well.
Changed carbon.xml and api_manager.xml
Start API Manager with wso2server.bat --run command
Issues are as follows;
api_manager.xml values are reset to localhost and not the IP Address I modified it to.
The API Publisher page is not loading and I am not able to get to the API Publisher login page.
I am an administrator on the Windows Server hosting this, so all changes are made as admin.
First of all, APIM 3.0 has a new config model, where all configurations are available (only) in deployment.toml. All other configurations are populated based on that, and shouldn't be changed manually.
Second, you don't need to replace all occurrences of localhost to IP as many are local calls.
Third, the correct URL should have the port, unless you have a reverse proxy in front of API.
eg. https://[ip address]:9443/publisher
Sounds good and thanks for the input. I will give this a try and post back to the thread.
I am using the IP and Port for now with no reverse proxy but plan to add one, once I can get through this part.
Much appreciated.
I am using the desktop version of Postman at a client site to test an API. However, I am unable to access any SSL sites in Postman, such as the Git Hib API: https://api.github.com/users/karlgjertsen
However, I can make the same API call through Chrome, so this is Postman specific.
I assume it is down to proxy settings, but I am not sure how to view or update these in Postman. Has anyone had any experienced something similar?
I turned OFF both Global Proxy Configuration and Use System Proxy in Settings->Proxy tab in Postman and it started to work.
This solved my issue :
The option "Respect HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environment variables." was selected by default in the proxy settings. I turned off this option and it worked for me.
Follow these steps on postman -
Go to file=>Settings => Proxy (Tab) and uncheck the "Use System Proxy" checkbox. That should work
Posting as the other solutions presented in this thread did not work in our corporate environment. We have a proxy configured on the network which uses Windows Default Credentials (username and password) for authentication. For whatever reason the browser knows how to pass these details with each request but postman does not by default.
Solution was to update the Default Proxy Configuration under settings -> proxy -> Default Proxy Configuration -> Tick 'This proxy requires authentication' then enter Windows Username and Password. Leave Use the system proxy and Add a custom proxy configuration settings disabled.
From the Windows start menu go to Change proxy settings and configure the host and port there.
This turned out to be a local security policy that was applied to the machine in use. The local SSL proxy had a policy applied and it would not allow me to make a secure connection unless it was through a web browser.
I am configuring our API Manager, but running into troubles authenticating via OAuth, seems to be an issue with the API Key Manager. I haven't dug into it yet, but does this come with the API Manager (as I have assumed) or is this a separate installation?
I had the same issue when using the wso2 api manager on a Amazon hosted machine, turn out that Thrift was not working correctly because some problem with multicasting and broadcasting.
What I did to get it working was to switch from ThriftClient to WSClient. If you have a huge amount of requests coming in then Thrift is the recommended solution from wso2 but in any "normal" case you will not have any differences between thrift and WS.
Here is how you switch:
Shut down the API Manager
Open up <api manager install dir>\repository\conf\api-manager.xml
Find ThriftClient
Change this to
<KeyValidatorClientType>WSClient</KeyValidatorClientType>
Start the API Manager
You may get some Warnings while starting up but, try it before you jump to the conclusion that it doesn't work.
Hope it helps!
you can use APIM manager product in a distributed setup as keymanger,gateway,store,publisher..but all functionality come in a single distribution.. ..
Go through the documentation for further guides
I was facing the same issue. Everything started when I created my own jks in order to use SSL without a self-signed certificate. I successfully created the jks and changed it in the carbon file. When I started the server, everything seemed ok; but when I used SOAPUI to test an API call, I got this (in the logs of the api manager):
APIAuthenticationHandler API authentication failure due to Unclassified Authentication Failure
I started digging what was the problem by enabling Debug level in the log4j.properties file, and then tried again a tested with SOAPUI and I got:
APISecurityException: Could not connect to <my api ip address> on port 10397
Then, I read the comment of OneMuppet and I checked that file and I found that the Thrift config has a host option, so I uncommented it:
<KeyValidatorClientType>ThriftClient</KeyValidatorClientType>
<ThriftClientPort>10397</ThriftClientPort>
<ThriftClientConnectionTimeOut>10000</ThriftClientConnectionTimeOut>
<ThriftServerPort>10397</ThriftServerPort>
This Line --> <ThriftServerHost>localhost</ThriftServerHost>
<EnableThriftServer>true</EnableThriftServer>
Save, restarted the server and everything start working correctly.
I got the same below issue after my installation, when i try to invoke the api service it is throwing below error:
900900 Unclassified Authentication Failure Error while accessing backend services for API key validation
After some random checks i have seen the axis2.xml file in /repository/conf/axis2 there it is refering a differnt ip's instead. I change these ip's to my local ip and restarted. The issue is resolved now.
I was facing the same issue. when I was trying to setup API Manager as an API Gateway in a different machine as per the steps given here,
https://docs.wso2.com/display/AM250/Publish+through+Multiple+API+Gateways
Once the setup is done and when I am trying to use this gateway URL, I was getting the below response,
{"fault":{"code":900900,"message":"Unclassified Authentication Failure","description":"Error while accessing backend services for API key validation"}}
After changing the KeyValidatorClientType value to WSClient from ThriftClient on the <api manager install dir>\repository\conf\api-manager.xml
It started working fine. And I was able to get the expected response.
If you changed the admin password, then you also have to update the repository/conf/api-manager.xml file with the new password. The 2 places I have changed (so far) are:
<AuthManager>
and
<APIKeyManager>
but there are other admin usernames in that file. No doubt, I'll get to them....
I have a web service running under IIS7 on a server with a host header set so that it receives requests made to http://myserver1.mydomain.com.
I've set Windows INtegrated Authentication to Enabled and everything else (basic, anonymous, etc) to Disabled.
I'm testing the web service using a powershell script, and it works fine when I run it from my workstation against http://myserver1.mydomain.com
However, when I run the same exact script on the IIS server itself, I get a 401-Unauthorized message.
In addition, I've tried installing the web service on a second server, myserver2.mydomain.com. Again I can call my test script fine from BOTH my workstation and from myserver1.
So it seems the only issue is when the client is on the same box as the web server itself - somehow the windows credentials are not being passed or recognized.
I tried playing with IE settings on myserver1 (checked and unchecked 'Enable Windows Integrated Authentication', and added the URL to Local Sites). That did not seem to have an effect.
When I look at the IIS logs, I see the 401 unauthorized line but very little other information.
I see basically the same behavior when testing with IE (v9) - works from my workstation but not when IE is running on the IIS server.
I found the answer after several hours:
By default, there is something called a LoopbackCheck which will reject windows authentication if the host header used for the site does not match the local host's name. This behavior will only be seen when the client is on the local host. The check is there to defeat possible reflection attacks.
More details here:
http://support.microsoft.com/kb/896861
The kb item discusses ways to disable the Loopback check, but I ended up just switching from using host headers to ports to distinguish the different sites on the IIS server.
Thanks to those who gave assistance.
Try checking the actual credential that is being passed when you are running on the server itself. Often times you will be running on some system account that doesn't have access to the resource in question.
For example, on your box your credentials are running as...
MYDOMAIN\MYNAME
and the server will be something like...
SYSTEM\SYSTEM_ACCOUNT
and so this will fail because 'SYSTEM\SYSTEM_ACCOUNT' doesn't have credentials.
If this is the case, you can fix the problem in one of two ways.
Give 'SYSTEM\SYSTEM_ACCOUNT' access to the resource in question. Most people would avoid this strategy due to security concerns (which is why the account has no access in the first place).
Impersonate, or change the credentials of the client manually to something that does have access to the resource, 'MYDOMAIN\MYNAME' for example. This is what most people would probably go with, including myself.
I have a FinalBuilder project where I deploy an ASP.Net website to a remote folder, configured as a website in IIS.
As part of my build script, I want to use the FinalBuilder action HTTP Get File to help determine whether my deployment was succesful.
I'm having difficulty, because the website is configured (under IIS 6) to use Integrated Windows Authentication, and anonymous access is not enabled.
Now the HTTP Get File action, has only a handful of properties, one of which is a security section, containing a UserName and Password. Great I thought! I can just put some valid credentials in there, which FinalBuilder will impersonate, whilst retrieving my file.
It turns out I was mistaken. I receive the following error:
Error retrieving url : Socket Error # 10061
Connection refused.
If I run the action without setting the Security Username and Password, I get the following error:
Error retrieving url : HTTP/1.1 401 Unauthorized Response Code : 401
Here are some facts to help with the context of my problem.
I'm running FinalBuilder 6 Professional, upon a Windows Server 2003 installation, and deploying my ASP.Net website to a remote IIS6 server within our corporate LAN.
If I configure IIS on the remote server to allow Anonymous access, I can run the HTTP Get File action without error. However, running this particular site with anon access is not acceptable in our situation.
Can anyone help suggest a workaround?
For a definitive answer, I think the Finalbuilder Forum is probably your best bet.
My guess, though, is that the HTTP library used by FB doesn't support Windows authentication, and is failing because no common authentication method can be negotiated. Since HTTPS isn't supported either by the 'HTTP Get File action', the possible workaround of allowing basic authentication on your site isn't a good idea, as you would be passing credentials over the network in plain text.
The only remaining workaround I can think of (other than waiting for a future FB release), is creating your own FB action to retrieve the file. Using the .NET Framework System.Net.WebClient, that should be trivial. Just start with a standalone EXE to make sure everything works, then refactor it into a 'real' action using FinalBuilder Action Studio (if that's even required: spawning an external EXE may work just fine in your case).