i am receving classfication failures for requests that are deployed on apigee :
{
"fault": {
"faultstring": "Classification failed for host intigral-api-prod.apigee.net",
"detail": {
"code": "CLASSIFICATION_FAILED"
}
}
}
The CLASSIFICATION_FAILED error usually means that one component of the request path is not correct.
The request path is comprised of:
{scheme}//{host}/{proxyBasePath}/proxyPathSuffix
The scheme is "http" or "https".
The host is the host alias that corresponds to the virtual host. In your case, the host is intigral-api-prod.apigee.net
Given that your as using that host, your API Proxy should be deployed to the environment prod.
So your request path begins with:
http(s)://intigral-api-prod.apigee.net/{proxyBasePath}
Check the following:
(1) The scheme (http, https) is allowed in your API Proxy; that is; it is included in the ProxyEndpoint HTTPProxyConnection VirtualHost list defined in your proxy endpoint.
(2) The API Proxy is deployed to the environment prod.
(3) The proxyBasePath portion matches the ProxyEndpoint HTTPProxyConnection BasePath defined in your proxy endpoint.
Also check that your proxy is actually deployed in the environment you're accessing. If you've made a mistake in your design/code, it will often undeploy.
We got the same error for many times because of the proxy is not deployed into the server properly.
Related
I use asp.net Identity with AzureAD as an external Identity provider in my Balzor server side app. In development environment (localhost) logging in works fine. When I deploy the app to an on premise server in a docker image behind Nginx, it does not. Microsoft sends the error message AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application. I have added the proper reply URL to Azure portal. As far as I can tell, the request uses http, while https should be used, which causes the error.
Since Nginx handles secure transport, the headers need to be forwarded, so I configured Nginx and enabled Header forwarding in Startup.ConfigureServices:
services.Configure<ForwardedHeadersOptions>(options =>
{
options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
options.ForwardLimit = 1;
options.KnownProxies.Add(IPAddress.Parse("123.xxx.xxx.xxx"));
});
and at the very beginning of Startup.Configure:
app.UseForwardedHeaders();
app.UseHsts();
// should not be necessary but I tried with and without
//app.UseHttpsRedirection();
When I enable logging, I think I see that the correct header is forwarded from Nginx:
...
Header: X-Forwarded-For: 123.xxx.xxx.xxx
Header: X-Forwarded-Proto: https
...
To me it looks like ChallengeResult() in ExternalLogin.Post is not using the forwarded headers and sends http://my.domain.ch/signin-oidc instead of https:// as reply URL, which causes the error.
I ran out of ideas what else I could try, any suggestions please?
After some digging I found the mistake: I did add the wrong proxy IP. Since my asp.net app is hosted on docker, I had to add the IP address of the docker image as proxy, not the IP of the server which hosts nginx and docker. In fact, I added the default network used by docker
options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("172.17.0.0"), 16));
I have 2 web services running on my machine (inside docker containers, but I think it doesn't matter), they are reachable by following addresses:
my.ip:1111
my.ip:2222
I launched nginx server on port 80 and I would like to configure reverse proxy to access my services by following aliases:
my.ip/app1
my.ip/app2
So, I added these entries to my /etc/nginx/conf.d/default.conf:
location /app1/ {
proxy_pass http://my.ip:1111/;
}
location /app2/ {
proxy_pass http://my.ip:2222/;
}
Proxy redirects corectly, because the main pages of web services are visible, so I know that the correct service tries to launch, but all .css/.js/etc resources are unavailable. Services get 404 on all resources, because they try to download them from "/" path, instead of "/app1/" (or :1111/)
Example from devtools console:
GET http://my.ip/app.js net::ERR_ABORTED 404 (Not Found)
(this resource is available on http://my.ip/app1/app.js or http://my.ip:1111/app.js)
I have read a lot of answers about this topic here, but none solution works for me. Any help will be appreciated, thanks!
I have two device which can be accessed only using internal network.
To access it externally i have installed nginx in raspberry device and added a redirect within nginx like
location /device1
{
return 301 http://192.168.0.1:80
}
Similarly device2 i have added and now i have used ngrok and exposed the localhost:80 externally.
Problem:
If i am in the same network of device1 and device2 i am able to connect it.
If i change my network i am able to access the nginx default page.
Now If i append device1 it says page not found.
Solution Required:
How do i connect device1 and device2 from different network.?
Why is this required say for example i am running a application in amazon i want to connect to my internal device ip and access the data.
You need to use nginx as reverse proxy for that. The very minimal configuration is
location /device1/
{
proxy_pass http://192.168.0.1/;
}
With this configuration request GET /device1/some/other/path will reach your device as GET /some/other/path. If you remove the trailing slash of http://192.168.0.1/ string, same request will reach your device as GET /device1/some/other/path. What you are trying to do commonly called "proxying something under some URI prefix", and depending on what you are proxying under this prefix, there can be various issues.
I currently have a hello world service deployed on /svc/hello, and I've added a dentry to my namerd internal dtab as /svc/app => /svc/hello.
I've also deployed an nginx service that will serve as my ingress controller, and forward all traffic to the relevant services. Eventually it's going to do header stripping, exposing admin services only to developers in whitelisted ip ranges etc, but for now I've kept it really simple with the following config:
server {
location / {
proxy_pass http://app;
}
}
However, those nginx pods fail to start, with the error
nginx: [emerg] host not found in upstream "app" in /etc/nginx/conf.d/default.conf:3
What do I need to do to get the nginx services to be able to forward to the app service via linkerd?
I'am not sure that this is possible, use linkerd with nginx ingress.
Look on this case, https://buoyant.io/2017/04/06/a-service-mesh-for-kubernetes-part-viii-linkerd-as-an-ingress-controller/
May be it can help you.
I was actually able to solve this by looking at a different post in the same series as what Girgoriev Nick shared:
proxy_pass http://l5d.default.svc.cluster.local;
That address does cluster-local name resolution in Kubernetes, and successfully finds the Linkerd service.
I am using an Ubuntu machine with an Ubuntu guest OS. On the guest OS, I ran my OpenDaylight controller, making the topologies with Mininet and viewing them in the OpenDaylight GUI at localhost:8080. Next, I used Postman REST API Client extension on my Chrome Browser to make a GET request to my ODL Controller:
localhost:8080/restconf/operational/opendaylight-inventory:nodes/
I got the proper response to it in XML format. Now, I have to pass my request through NGINX proxy to 3Scale and get authentication using the app_id and app_key parameters. The request is then to be forwarded to the ODL controller so that I gan get the proper response.
I have already downloaded the proxy config files from NGINX. What modifications must be made in these files? What should be the request I enter in the Postman Client to get the same response as before?
You should only need to change the location of the nginx_.lua file in nginx_.conf
If you want to change the port that Nginx listens on, you will also need to change the listen directive in the server block, to your desired port e.g
server {
lua_code_cache off;
listen 81;
Also, you will need to ensure that there is an upstream block for your backend, e.g
upstream backend_localhost {
server localhost:8080 max_fails=5 fail_timeout=30;
}
but if you have entered this in the proxy configuration wizard that should already be there.
That should be all that you need to change/check.
The request in Postman should target Nginx instead of the ODL Controller, and pass in the application credentials e.g if Nginx is running on port 81
localhost:81/restconf/operational/opendaylight-inventory:nodes/?app_id=<YOUR_APP_ID>&app_key=<YOUR_APP_KEY>
Hopefully that should clear up any doubts. However, you can always email us at support#3scale.net if you have any further questions or add any comments here.