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.
Related
I deployed to test the last release of WSO2 5.11.0 in Docker container. I did not change anything in the default configuration except the hostname and callbackURL for the "Console" and "My Account" service providers to match my hostname.
Access to the carbon console is fine. But when I try to reach https://<hostname>/console or https://<hostname>/myaccount, I can fill my login and password, then I have a blank page without anything.
Any idea is welcome. Thank you.
Taking the answer from comments:
If you change the host/port of the server after one fresh pack startup, you have to follow the steps in stackoverflow.com/a/65353673/10055162 manually. On the other hand, if you change the host/port before the fresh IS pack server startup these changes applied automatically.
Out of the steps in stackoverflow.com/a/65353673/10055162,
You should have missed step 5 which causes you to see a blank page.
Navigate to : Resident IDP > Inbound Authentication Configuration > OAuth2/OpenID Connect Configuration and change Identity Provider Entity ID accordingly.
Further, these value changes can't be done via deployment.toml.
I can reproduce the same issue, upon initial startup with what I believe is a correct configuration:
When adding an HTTPS ProxyPort config of 443
[server]
hostname = "identity.myorg.io"
...
[transport.https.properties]
proxyPort = 443
Upon initial startup, the Resident IdP erroneously sets the Identity Provider Entity ID to https://identity.myorg.io:443/oauth2/token.
This means that when accessing -> https://identity.myorg.io/console|myaccount the same issue as described by the OP is encountered.
Manually changing the IDP EID to remove the :443 fixes it. The server should do this automatically for port 443.
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 developing an application using kerberos authentication in a double-hop scenario : the client is connecting to a server witch needs to use the client's credentials to connect a SQL server.
I already did it using GSoap and GSS-API from kerberos MIT release; but I would have liked to use winHTTP to handle the authentication.
Yet, when I try to use winHTTP with GSOAP WINHTTP PLUGIN (gsoapwinhttp on code.google), the delegation is blocked by the Domain Controller. I want to keep this Active Directory configuration :
When I look at GSS-API kerberos ticket I found several flags allowing delegation such as fowardable or deleg_req_flag :
So my question is : Can I modify the winHTTP flags to have to allow delegation without changing the Domain Controller's configuration ?
Edit :
I'm using the option WINHTTP_AUTH_SCHEME_NEGOTIATE in setCredentials and WINHTTP_AUTOLOGON_SECURITY_LEVEL_LOW in setOption to be sure to use Kerberos or NTLM as specified in Microsoft website WinHttpSetCredentials.
Using Fiddler I checked the HTTP connection and it is using Kerberos but I still can't delegate to my next server.
I tried to use almost every possible options of setOption such as WINHTTP_ENABLE_SSL_REVERT_IMPERSONATION or everything that could look like delegation but I have a strange error when using this option :
End of file or no input: message transfer interrupted or timed out (629s recv send delay)
I tried to set a different recv_timeout but still the same error.
.
I've studied this type of kerberos-delegation problem a lot. You are experiencing the Kerberos double-hop problem. In that active-directory configuration screenshot you provided, you must configure delegation; right now delegation is not set. First item to try is open delegation,to do that select the radio button: Trust this computer for delegation to any service (Kerberos only). You set this on the computer account in AD which needs to use the client's credentials to connect a SQL server - not on the domain controller account. If your application is actually running on a domain controller, then that is a known issue and unsupported configuration which won't work - please move application to a member server of the domain.
Regarding those flags allowing delegation such as fowardable or deleg_req_flag shown as being set in the Fiddler trace, I'm not sure why they are shown as set, but they might have been set from the wrong account. From the account of the screenshot you posted, Kerberos delegation is not configured at all.
In your scenario, you must set Kerberos delegation on the computer account which is running the WinHTTP process, in the example shown below, that would be "Server1".
In the Kerberos Delegation properties of that account, you can specify either open delegation (top radio button as I stated above), or constrained delegation to the process on Server2 to which Server1 may forward the user credentials (the Kerberos service tickets).
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 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....