I've dug around and found the following but where not particularly useful (and why)
- Does GridGain support SSL connection between each cluster member? was
this wasn't so much useful as it didn't give much information on actually running and using the client
- http://atlassian.gridgain.com/wiki/display/GG60/HTTP+Client
unlike other parts of the documentation which comes with examples, the GridGain docs for HTTP REST client just shows you the fields and its properties
What I am trying to do:
I have a cluster over a virtual network running on separate virtual machines. I wish to set up a REST service so that I can hit an endpoint to store data. ie. curl POST to localhost:8080/store/ with a parameters object (or some variation of this situation, so long as I can do it over HTTP) and have that data stored into the GridGain cache
GridGain REST protocol is MemCached compliant, so you can connect to GridGain using any MemCached compatible client.
GridGain downloadable distribution has PHP HTTP and MemCached examples in examples/rest folder.
Related
My customer has 2 Windows Server 2019.
On both of them, an instance of a SOAP Web Service is running.
URLs:
https://host1.domainname.com/SOAPService
and
https://host2.domainname.com/SOAPService
Now, the requirement of the customer is to provide a single, unique URL that the clients can use to consume the SOAP WebService(s).
I read through several websites and if I got it right, I need a tool that is called "reserve proxy"... Using this tool, clients can access the webservice by using an URL such as https://host.domainname.com/SOAPService and the tool will automatically route the request to the available webservice.
Correct?
I also have an architectural question:
On which machine do I have to run such a Reserve Proxy?
Is it on host1 or host2 or do I need a dedicated machine (like a supervisor)?
If it is a dediciated machine, how can I apply high availability of this Reverse Proxy? E.g. is it possible to run 2 Reserve Proxies in parallel on different machines? Which tool could afford this?
Thanks
I got a webservice endpoint and I stumple upon how to correctly implement it.
It seems to be an parameterized exe-file which returns an XML Reply.
There is no documentation.
I am used to soap, wcf and rest but this is completely unknown to me, has anyone a guide or a best case how to implement such a service?
I can consume it with a HTTP GET but there are some questions left to me:
I know the questions are quite broad... But I could not find anything about it in the interwebz.
Is there a secure way to publish exe files as webservice?
Are there any critical downsides implementing such an interface?
Make I myself a fool and this is just an alias?
Example Url:
http://very.exhausting.company/Version/SuperStrange.exe?parameter=String
Web servers
What you call a webservice endpoint is nothing else than a web server listening on some host (normally 0.0.0.0) and some port on a physical or virtual machine and responding with some HTTP response to HTTP requests sent to that host, port and URIs that the web server cares to process.
Any web server is itself an application or a static or dynamic component of an application as the following examples illustrate:
JBoss, Glassfish, Tomcat etc. are applications, known as application servers, into which containers/servlets/plugins implementing web servers and corresponding endpoints are deployed. These listen on some port exposing generic web servers routing requests to those containers and their servlets;
a fat jar started with java -jar on a JVM which deploys a vert.x verticle featuring a vert.x HttpServer listening on some port is nothing else than a web server;
an interpreter such as node.js parsing and executing JavaScript code based on the express module will most likely deploy a web server on some port;
finally, a statically or dynamically linked application written in languages such as C++ or Go can expose a web server listing on some port.
All of the above cases feature different deployment mechanisms, but what they deploy is essentially the same: a piece of software that listens for HTTP requests on some port, executes some logic based on request and returns HTTP responses to the caller.
Your windows exe file is most likely a statically linked application that provides a web server.
Protocols
So we know you have a web server as it reacts to an HTTP GET. How does it relate to REST, SOAP etc? Effectively, REST, SOAP etc are higher level protocols. TCP is the low level, HTTP is based on top of that and your server supports that. REST, SOAP and everything else that you mention are higher level protocols that are based, among others, on HTTP. So all you know is that your application (web server) supports HTTP, but you do not know which higher level data exchange protocol it implements. It definitely implements some, at least a custom one that its author came up with to exchange data between a client and this application.
You can try to reverse engineer it, but it is not clear how would you find out about all possible endpoints, arguments, payload structures, accepted headers etc. Essentially, you have a web server publishing some sort of an API, but there is no generic way of telling what that API is.
Security
The world around you does not have to know how the API is published. You can put any of the above 4 web server implementations behind exactly the same firewall or a reverse proxy with SSL termination exposing just one host and port over SSL. So there is no difference in security, with respect to the world, whether you deploy it as exe or as a war into JBoss. This is not to say, that your exe file is secure: depending on how it is implemented it may allow all sorts of attacks, but again, this is equally true for any mechanism.
The REST API for Kafka Connect is not secured and authenticated.
Since its not authenticated, the configuration for a connector or Tasks are easily accessible by anyone. Since these configurations may contain about how to access the Source System [in case of SourceConnector] and destination system [in case of SinkConnector], Is there a standard way to restrict access to these APIs?
In Kafka 2.1.0, there is possibility to configure http basic authentication for REST interface of Kafka Connect without writing any custom code.
This became real due to implementation of REST extensions mechanism (see KIP-285).
Shortly, configuration procedure as follows:
Add extension class to worker configuration file:
rest.extension.classes = org.apache.kafka.connect.rest.basic.auth.extension.BasicAuthSecurityRestExtension
Create JAAS config file (i.e. connect_jaas.conf) for application name 'KafkaConnect':
KafkaConnect {
org.apache.kafka.connect.rest.basic.auth.extension.PropertyFileLoginModule required
file="/your/path/rest-credentials.properties";
};
Create rest-credentials.properties file in above-mentioned directory:
user=password
Finally, inform java about you JAAS config file, for example, by adding command-line property to java:
-Djava.security.auth.login.config=/your/path/connect_jaas.conf
After restarting Kafka Connect, you will be unable to use REST API without basic authentication.
Please keep in mind that used classes are rather examples than production-ready features.
Links:
Connect configuratin
BasicAuthSecurityRestExtension
JaasBasicAuthFilter
PropertyFileLoginModule
This is a known area in need of improvement in the future but for now you should use a firewall on the Kafka Connect machines and either an API Management tool (Apigee, etc) or a Reverse proxy (haproxy, nginx, etc.) to ensure that HTTPS is terminated at an endpoint that you can configure access control rules on and then have the firewall only accept connections from the secure proxy. With some products the firewall, access control, and SSL/TLS termination functions can be all done in a fewer number of products.
As of Kafka 1.1.0, you can set up SSL and SSL client authentication for the Kafka Connect REST API. See KIP-208 for the details.
Now you are able to enable certificate based authentication for client access to the REST API of Kafka Connect.
An example here https://github.com/sudar-path/kc-rest-mtls
I'm trying to test connectivity to couchbase server using the .NET sdk.
I've tried to get a test key in order to do it, but I'm getting "null" (instead of getting an exception mention that couchbase server is done).
I've also read this:
http://www.couchbase.com/docs//couchbase-manual-2.0/couchbase-getting-st...
But it doesn't say anything about testing connectivity from an application code.
Is there any way of testing connection to couchbase server via code ?
The couchbase client sdk manages the connections for you, whatever node urls you pass to it during construction it attempts to authenticate to, if the client can't authenticate to one of the nodes then it throws ConnectException (I'm using the JAVA sdk but I imagine .NET is very similar).
So really you don't have to test the connectivity, the smart client handles that. After construction you can ask the client to list all the available servers
client.getAvailableServers();
Or for a more detailed status of your nodes and statistics do:
client.getStats();
I would like to know the difference between IBM HTTP Server and Wepsphere Application Server. Also i am planning to use WAS. Do i still need the IBM HTTP Server?
From here:-
IBM HTTP Server
IBM® HTTP Server is a full-featured web server that is included with
other products such as IBM WebSphere® Application Server at no charge.
You can use this web server for projects that do not warrant the
expense of a priced and supported HTTP server. The IBM HTTP Server is
based on the Apache HTTP Server and provides a rich set of Apache
features in addition to IBM enhancements.
From here:-
Wepsphere Application Server
IBM® WebSphere® Application Server offers options for a faster, more
flexible Java application server runtime environment with enhanced
reliability and resiliency. It supports single server environments and
medium-sized configurations, as well as dynamic web applications
requiring web tier clustering over multiple application server
instances.
Do i still need the IBM HTTP Server?
Wiki has the answer for it:-
It works with a number of Web servers including Apache HTTP Server,
Netscape Enterprise Server, Microsoft Internet Information Services
(IIS), IBM HTTP Server for i5/OS, IBM HTTP Server for z/OS, and IBM
HTTP Server for AIX/Linux/Microsoft Windows/Solaris. It uses port 9060
for connection as the default administration port and port 9080 as the
default website publication port. In case you install more WebSphere
instances these values will be changed.
A http server is used for routing web requests to a WAS in a typical enterprise scenario. If you are building small apps, and do not need ejbs, just use the http server. If you need ejbs, just use WAS. However, if you need functionality like routing requests to WAS because you do not want the user to hit the WAS directly for security reasons, then use HTTP in front of WAS.
WebSphere is an implementation of J2EE (originally Java 2 but versions handle up to J6EE). This varies from a normal web server in that the latter typically had the task of running scripts or programs using operations that were quite expensive for CPU load. Modern web servers do not have as much penalty but Java based solutions still have their advantages.
For test/dev environments, one does not need to have a web server in front. One can go directly to a WebSphere port (often port 9080) that provides a Java web implementation and not have the administrative burden of the care and feeding of a web server. On the other hand, IBM recommends using a web server for production (especialy for larger production loads). If one does use a web server, there are several that are supported. IBM HTTPS Server is a blue-washed version of Apache (there are some modules that are not supported but there are also lots of extra features to bind easily with WAS).
All the answers are good so let me give my cents ,
Websphere as other java applications, was made to work with dinamic contents .
apache or IHS that is apache IBM plugins can handle with all kinds of http/https requests , static , dinamic , proxy ,cache at the client tags, balance and so on ...
just using apache over java aplications is not the best ,
the best is allow apache handle all static downloads without call it from application server ,
like images and fixed htmls and left application server handle the just dinamic contents .
at this way we can optimize the environment , so development should create a pattern to dispose static and dinamic at different virtual direct like /jsp for dinamic and the rest as static , if not apache cache can be used instead for not overload the application server .
to make the story short , apache is so powerful ans can help a lot the application server sparing the work , a simple and effective usage is done to forward the port using default port 80/443 for http/https instead usual high ports on java application servers , make the apache deliver https is a best option too , instead left java application server care of it , so there is a lot of reasons to use Apache or IHS in front of application servers.