I'm running Ws02 products in docker containers
I have a strange problem. I publish an API in publisher, subscribe to it using the store and access the API using the curl command. It works fine. The DB is also running in a separate mysql container and Im persisting the DB data to a volume. However, if I shutdown the containers (docker-compose down) , bring it back up and access the API again, I get a 404 error with the following errordetails .Any idea?
errorCode":900000
errorDescription":"Not Found""
errorDetails":"The requested resource is not available
404
In API Manager, some API data is persisted in the File system as well. You can see the artifacts located at "/repository/deployment/server/synapse-configs/default/api. You need to make sure this is not replaced when the docker container is restarted.
Related
We are facing an issue on our application which uses google big query with OAuth authentication. When we run the application on docker container during runtime we get an authentication URL on the docker console like below :
Please open the following address in your browser:
https://accounts.google.com/o/oauth2/auth?access_type=offline&approval_prompt=auto&client_id=330834658013-dg6niu0iihdcatin3c3mi6haqebrjinm.apps.googleusercontent.com&redirect_uri=http://localhost:61984/Callback&response_type=code&scope=https://www.googleapis.com/auth/bigquery%20https://www.googleapis.com/auth/cloud-platform%20https://www.googleapis.com/auth/drive
If we open the URL outside the container in the browser. We do not get the response and application get failed.
We tried to run the application other than docker container, we found that It automatically redirect to the browser and successfully get the response after that an folder named as 'credentials' containing StoredCredentials file is created locally which get referred next time for authentication.
As described above, due to authentication is not done by URL on docker container. The credential folder is also not created. Could you explain the resolution on priority.
We tried to run the application other than docker, It is running successfully. As it automatically redirect the URL and completes the authentication. Same is expected on docker container as well.
I have a GCP project with a pipeline that scrapes a website at regular intervals. It has a cloud scheduler set up that posts to a Run container using an HTTP request (the container does the scraping). However, when I start the scheduler, the Run container logs just show a warning that says "[some_timestamp] POST 404 695 B [execution_time] Google-Cloud-Scheduler [Cloud_Run_URL]". I was confused because the scheduler posted the request to the right Run container, but the container is throwing a 404 error? What might be happening here?
If more information is needed, I will post it. Thanks.
Not the container is throwing 404.
A service, your web server on the container throws the 404.
So the request hits the container, then the webserver, but the requested URL doesn't work, and the web server returns 404. Look for your application errors, or if the path exists on the given URL.
Currently there is no outage occurring with any GCP services, which you can check in this status page. I suggest you try to emulate your Cloud Run container locally following this guide and using the Cloud Run emulation tool to test if the issue originates from your application instead of Cloud Run.
According to this thread comment, the 404 error might be returning from your web server and it is logged in Cloud Run. In this documentation page there are Cloud Run error codes and their meanings in addition to more troubleshooting procedures.
I am trying to deploy API Manager in a simple HA configuration. I'd like the entire API Manager setup on server A, and just the API Gateway on server B.
I'm trying to follow the instructions on the following link: http://docs.wso2.org/display/Cluster/Clustering+API+Manager
My question is, how do I remove the store and publisher from server B, as instructed by this sentance: "To set up each API Manager component in separate servers, simply remove the unwanted Jaggery apps from the deployment directory. For example, to set up only API Gateway in a severer, remove the store and publisher Jaggery apps.".
I have SVN Deployment Synchronization set up as per the following link with server A the master: http://docs.wso2.org/display/Cluster/Configuring+Deployment+Synchronizer
If I remove the store and publisher from jaggeryapps on server B, won't the deployment sychronizer just put them back the next time I restart server B?
Those are webapps, you can simply delete the jaggery webapps from AM_HOME\repository\deployment\server\jaggeryapps.
Deployment synchornizer won't put back the webapps again. You have to again deploy both jaggery apps in the same folder
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 apologize in advance if the question is ridiculous.
I have an asmx service running in Azure (HTTP - no SSL).
I have a WPF app that loads a X509Certificate2 and adds it to the request by doing the following:
X509Certificate2 cert = new X509Certificate2("...");
webRequest.ClientCertificates.Add(cert);
In the web service I get the certificate by
new X509Certificate2(this.Context.Request.ClientCertificate.Certificate)
And then I load a cert (that I have both uploaded to the Azure control panel and added to my service definition file) by using the following sample:
var store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
store.Open(OpenFlags.ReadOnly | OpenFlags.OpenExistingOnly);
X509Certificate2Collection certs = store.Certificates.Find(X509FindType.FindBySubjectName, certName, true);
And then I validate by doing the following:
clientCert.Thumbprint == certs[0].Thumbprint
Now unfortunately I get an exception (System.Security.Cryptography.CryptographicException: m_safeCertContext is an invalid handle) as soon as I do
Request.ClientCertificate.Certificate
So I have a few questions. How do I avoid the exception. This answer states I need to modify an IIS setting, but how can I do that in Azure?
In any case is this even the proper way to do certificate authentication?
Thanks!
You can use command scripts to modify IIS, in combination with appcmd.exe.
For a quick example (disabling timeout in an application pool), take a look at this sample by Steve Marx.
In this example, you'd call DisableTimeout.cmd as a startup task. For more info on creating startup tasks, you can watch this episode of Cloud Cover Show. There should be a lab on startup tasks in the Platform Training Kit as well.
Just remember that any type of IIS configuration change should be made via an automated task at startup. If you manually change IIS via RDP, those changes won't propagate to all of your instances, and won't remain persistent in the event of hardware failure or OS update.
You can remote into your azure instances to manage IIS. As for a way to do it globally for all instances at once, I'm not sure. That would be an interesting side project though.
http://learn.iis.net/page.aspx/979/managing-iis-on-windows-azure-via-remote-desktop/