I installed wso2 3.0 in windows 7. Also i have installed correctly all prerequisites. I think correctly because i followed tutorials and i din't get any error at all.
Following Running the product part of tutorial i start the server and i don't get any error.
When i try to open by IP http://192.168.56.235:9446/carbon it shows certificate error. I confirm certificate and after that it shows Error 403-Forbidden.
I have tried three times with three different machines with windows 7,10 and ubuntu 16.10
It's the same result!
What am i missing?
I really appreciate any help!
Thank you
https://192.168.56.235:9446/carbon url is intentionally blocked in the IoTS 3.0.0, This port belongs to mqtt broker and there is no UI capability for this. In order to access IoTS console go to https://IP:9443/devicemgt.
In addition, the certificate error that your getting might be related to untrusted certificate that comes by default with the pack, which you need to trust in the local browser before you access the node.
This doc: https://docs.wso2.com/display/IoTS300/Running+the+Product#f86e2494c1ef43a6b6c430abef6d47b8, has the instruction on how to run the product in windows and linux (Please note the environment variables that are passed through when starting it on windows)
Related
I'm trying to install Qlik Sense Desktop on Windows Server 2012 R2. The problem I believe is with the name entered as hostname during installation.
I tried using the hostname during installation process as the name of the server machine as well as the the ip address of the windows server but I get below error message whenever I try loading the Qlik sense hub app after installation
This site can’t be reached
If you're logged into the server, try https://localhost/qmc rather than the hostname. That should always work unless the services have failed to start up or something.
If you can get in there, then you can amend the accepted hostnames in the Virtual Proxy settings in the "Host Allow List" section.
If you can't get in there, it's possible it's trying to use the hostname you entered to connect between services - your best bet is to do a full uninstall and re-install - and probably keep the default hostname it proposes as this should always work and you can add additional hostnames at a later date.
Are the services up and running ? Have you see if one of the ports used by QlikSense are available or were used by other application ?
I am new to WSO2 identity server and going through their documentation for samples. But after running the server when i hit the browser with below url
https://localhost:9443/carbon/admin/login.jsp
i am getting empty page only (I have added the https security exception as well).
Do i need to do anything additionally ? for the admin user (admin/admin)
I found the solution. We need to setup only the tested jdks that are mentioned in their page. But it should also support later versions too. Looks crazy some time. I have used the latest jdk 8.161 for wso2 is 5.0.
Run WSO2 from command line and check out the logs for end points or wso2 services Port already in use: xxxx error before java.net.BindException: Address already in use (Bind failed) which may caused by other startup process and kill them.
On linux will be:
sudo kill -9 `sudo lsof -t -i:xxxx`
(where the xxxx is the port number)
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 coded a web service using the Axis 2 framework and I can successfully invoke it using a test client (SoapUI) on the local machine after publishing the application in JBoss 5. I can post to the WS endpoint from the local machine and get the expected response.
Now i want to allow other machines to access the web service.
i changed the "localhost" to "my own fixed IP" adress at the end point location, and turned firewall off, but impossible to access the WS.
Note : windows Xp SP3.
Any idea ?
Thanks in advance !!
Please ensure you follow below steps
For example, if your ip is 10.132.243.54
List item
Checking if your IP is pingable by other systems
Instead of running with eclipse, run your jboss from your
command-prompt
start jboss-server suffixing -b in run.bat. The command is run.bat
-b 10.132.243.54
Access the WS from SOAP-UI using IP and not using localhost
If your IP is still not pingable, turn off the firewall, after
following above steps
Sorry for the late reply, However this would solve the problem i guess
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.