I have deployed a botpress application to AWS (EC2) with Dokku, following the docs of botpress. To communicate with the bot I'm doing API calls to the IP address (52.xx.xxx.xx:3000).
This works fine when I'm running my RN app locally or when I test the API with Postmen. As soon as I release an APK I can't communicate with the API anymore, and I don't have a way to see why network requests are failing.
Since I'm not very experienced with servers, I'm assuming the problem lies somewhere in the server settings, thank you for any advice.
are you using HTTP? in that case use android:usesCleartextTraffic="true" in AndroidManifest.xml
In order to view remote documents from an HTTP URL, cleartext network traffic support is required. On Android 9.0 (API level 28) or higher, cleartext support is disabled by default and apps targeting Android 9.0 or higher will need to add the android:usesClearTextTraffic="true" flag in the AndroidManifest.xml file.
If you are only working with HTTPS files, this flag is not required.
Related
Running an ASP.Net Core application based on IdentityServer 4 on an AWS cluster,
after 14-21 days all outgoing HTTPS requests take 5min or more to finish.
After an investigation found that the WinHTTP Web Proxy Auto-Discovery Service dies with the following error: The endpoint mapper database entry could not be created. not sure if this is the issue or a side effect of something else that breaks lower in the OS.
Environment:
ELB with with an autoscaling group with two instances behind it, issue occurs on both
Windows Server 2019
Notes:
It is a custom AMI but the only difference with the instances that do not experience this is the product is running on it.
Happens on both .Net core 2.2 and 3.1 based versions of the application
Happens on both versions based on IdentityServer4 v2 and v3
The app is deployed self contained
The app uses Kestrel without a reverse proxy in front of it
Tried:
Enabled schannel: no errors in the schannel logs set on trace
No other notable errors in any of the EventViewer logs
Restarting the instance fixes the problem
When running curl.exe -v to an HTTPS site on the machine the request gets stuck on schannel: checking server certificate revocation
The clocks on the instances are OK
Restarting the app process does not resolve the issue
Disabling the HTTPClient in the code using the WinHTTP Web Proxy Auto-Discovery Service service still breaks the service.
For those running into this.
The root of this issue is the WinHTTP autoproxy (wpad) service which is used to autoconfigure proxy settings, WinHTTP 5.1 implements the Web Proxy Auto-Discovery (WPAD) protocol also known as autoproxy, and it must support DHCP. Now this is where the problem occurs, the AWS DHCP does not support DHCP option 252 (used by WPAD) which in turn causes the issue.
The resolution is to disable the WinHTTP service as it is turned on by default in Windows.
I am seeing this exact same problem on a bare-bones AWS Lightsail instance of Server 2019. I am simply using IIS as a reverse proxy with the URL Rewrite module.
Here are some details about my environment/scenario in case it helps narrow down some common factors.
I have zero .Net applications running on this box, it is simply a reverse proxy.
I have 2 web applications, and 2 websites setup in IIS, each is a reverse proxy for a different back-end API.
The websites in IIS on the reverse proxy use the same CA issued wildcard certificate as the back-end API's.
The back-end API's are also hosted in IIS (Server 2012 R2).
The back-end API's run in a PCI compliant environment so IIS Crypto has been used to tighten up encryption protocols/algo's. I have not used IIS Crypto on the reverse proxy yet, so as I type this I'm starting to wonder if there's an SSL aspect to this.
I have build and application with angular 5 and REST API with golang and hosted them on aws ec2 instance, I have installed ssl certificate to run the app and api on https. following is my url structure to run app and api ( api is running on 8080 port
app : https://mysite.maindomain.com
api : https://mysite.maindomain.com:8080
When I hit api after setting up the ip in host file on system it works fine but its not working with aws and redirects to https://mysite.maindomain.com:8080 when I hit any api like https://mysite.maindomain.com:8080/signup or https://mysite.maindomain.com:8080/get-user/10
Nor sure what is the issue here but everything else is working fine
I am using gin gonic as go framework and also have used RunTLS as recommended.
Not sure I fully appreciate the issue, but just in case, have you setup CORS on the API server (https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS).
If you run a browser application served from ORIGIN1, and the browser tries to access an API on DESTINATION2, the API server must state to the browser that it is indeed authorized to reply to a browser originating from ORIGIN1.
You can for example use https://github.com/gin-contrib/cors to add CORS support to your API server.
Good luck.
I am trying to deploy a simple HTTP API app on an Window Server 2012 and it's not working. The app is accessible internally (I can ping it within the server) but NOT externally. What do I need to do make the API server accessible via network? I disabled the firewall so it's not a firewall issue. I would usually use Linux, but I don't have a choice but use Windows this case. Please help!
I solved it by installing IIS and use it as a reverse proxy. So when a http request comes in from the internet, IIS it takes it and forwards it to my web app.. I am not sure this is the right way or not, but if it is, then it's pretty stupid as my web app should be accessible directly which would have been the case if I were using Linux.
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.