Does the Jetty Servlet container use OpenSSL, and is it vulnerable to the Heartbleed bug?
I think it should not be impacted as it is supposed to use its own implementation of SSL but I don't know enough of what's going on under the hood to be sure.
From older Jetty docs:
This is an overview of how to configure SSL for Jetty, which uses Sun's reference implementation for the Java Secure Sockets Extension (JSSE).
I would imagine this still holds, though depending on your use case you may want to wait for a more authoritative answer (or ping Jetty devs directly).
EDIT: bumping this up from the comments below. This question has been answered on the jetty-users list:
http://dev.eclipse.org/mhonarc/lists/jetty-users/msg04624.html
Related
I was using jetty 7.6.5 version in one of my project and now we want to upgrade to jetty 9.4.7. And found that multiple class have been removed or changed in 9.4.7 version.
Example:
httpClient.setConnectorType(HttpClient.CONNECTOR_SELECT_CHANNEL);
ExecutorThreadPool pool = new ExecutorThreadPool(execSvc);
httpClient.setThreadPool(pool); httpClient.setTimeout(1000);
This code does not work on jetty 9. Please help how to fix it
Let's answer your questions first:
Connector types do not exist in the same way as it did in Jetty 7.x. The default is NIO based.
Executors / ThreadPools can only be set on the constructor. (Don't set small thread pools!)
There are many flavors of timeout you can set from the HttpClient itself, do you want idle timeout? connection timeout? dns lookup timeout? etc... Check the javadoc for details.
There are also per-request timeouts available. Again, check the javadoc for details on which kind you want.
Going from Jetty 7.6.x series to 9.4.x series is a huge jump. You are skipping nearly 8 years of heavy development and change in your usage. (7.x is 2009 vintage to 9.4.x is new to 2017)
The techniques and mechanisms you were using in the past are likely no longer present anymore.
This is because HttpClient has been updated significantly for HTTP/1.1, HTTP/2, ALPN, Unix Socket, FCGI, WebSocket, etc.
The most significant is to treat the new HttpClient like a web browser, start it once, and leave it running, perform as many requests as you like against it. The worst thing you can do for yourself is to start it, perform a request or two, then stop it. This kind of usage is not supported and can lead to strange issues with memory/threading/etc. Start it once when you first need it, don't stop/shutdown that HttpClient instance till your application stops.
There is an old OC4J server where 200+ web services are deployed. Now all have been ported to weblogic. The question is whether can I check if anyone is still accessing the webservices deployed in oc4j. Can't rely on app logs as this is quite old (not much standard followed)
If anyone is accessing is it possible to understand who is it?
PS: Am a newbie please help me in understanding this (if possible) in detail.
Much appreciated.
You can use a tool like TCPDump to locate in real-time traffic on the LAN where the destination and port number match the host/port of the running OC4J
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I had to "sporadically" work with Heimdal / MIT Gssapi for kerberos authentication over past couple of years. I had to build an application that was to be used as a web-service running on a Linux box, and serve client applications like browsers, running on Windows and/or Linux Desktops and Workstations. Surely not the easiest of beasts to tame. Eventually when summarizing my work, I could record that the difficulties emanated due to challenges in multiple dimensions. Getting started with gssapi programming is truly a challenge just because of poor documentation, and practically non-existant tutorials. Googling mostly results in either some theoretical discussion on what's kerberos, or leads to content written with presumption that you already know everything besides some particular semantic issue.
Some really good hacks around here contributed to help me, I therefore suppose it would be a good idea to summarize the stuff, from a developer's perspective, and share it here as some sort of a wiki, to give something back to this fantastic place, and fellow programmers.
Haven't really done a wiki like this before, and I am surely no authority on GSSAPI nor Kerberos, so please be kind, but more than that please contribute and correct my mistakes. Site Editors, I am counting on you to do your magic ;)
Getting your project completed successfully will require 3 specific things to be done correctly:
Setup of your test environment
Setup of your libraries
Your code
As I said already, such projects are beasts, just because all the three haven't been put together on the same page anywhere.
Ok So let's begin at the beginning.
Unavoidable theory for a newbie
GSSAPI helps a client application to provide credentials for a server to authoritatively identify the user. Extremely useful because the server applications can modulate their served responses if they wish to, as per the user. Very naturally therefore both - the client and the server applications must be kerberized, or as some would state kerberos-aware.
The kerberos based authentication, requires both the client and server applications, to be members of a Kerberos Realm. KDC (Kerberos Domain Controller) is the designated authority that rules the realm. Microsoft's AD servers are one of the most popularly experienced examples of a KDC, though you can of course be using a *NIX based KDC. But surely without a KDC there can be no Kerberos business at all. Desktops, Servers & workstations joined into the domain identify each other as long as all of them remain joined into the domain.
For your initial experiments, setup the client & server applications in the same realm.
Though Kerberos Authentication can surely be also used across realms by creating trusts between KDCs of these realms, or even merging keytabs from different KDCs that do not trust each other. Your code will not really need any change to accommodate such different and complex-sounding scenarios.
Kerberos Authentication basically works via "tickets (or tokens)". When a member joins the realm, the KDC "grants tokens" to each of them. These tokens are unique; time and FQDN are essential factors for these tickets.
Before you even think of the very first line of your code make sure you have got these two right:
Pitfall #1 When you setup your development and test environment, make sure everything is tested and addressed as FQDN. For example if you want to check connectivity, ping using FQDN, not IP. Needless to say therefore, they must necessarily have the same DNS service configuration.
Pitfall #2 Make sure all the host systems - that are running your KDC, client software, server software have the same time server. Time synchronization is something that one forgets, and realizes to be amiss after a lot of hair-splitting, and head-banging!
Both, the client and server applications NEED kerberos keytabs. So if your application is going to run in a *NIX host, and be a part of a Microsoft Domain, you have to get a kerberos keytab generated, before we start to look at the remaining preparatory steps for gss programming.
Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability at is an absolute must-read.
GSS-API Programming Guide is an excellent bookmark.
Depending upon your *NIX distribution you can install the headers & libraries for building your code. My suggestion however is to download the source and build it yourself. Yes, you might not get it right at one go, but it surely is worth the trouble.
Pitfall #3 Make sure that your application is running in an Kerberos aware environment.
I really learnt this the hard way, but maybe because I am not so smart. In my earliest stages of gssapi programming struggle, I had discovered that kerberos keytabs were absolutely necessary for making my application kerberos-aware. But I simply couldn't find anything about how to load these keytabs in my application. You know why?!! Because no such api exists!!!
Because: The application is to be run in an environment which is aware of the keytabs.
Ok, let me make this simple: Your application that is supposed to do the GSSAPI / Kerberos things has to run after you have set environment variable KRB5_KTNAME to the path where you have stored the keytabs. So either you do something like:
export KRB5_KTNAME=<path/to/your/keytab>
or make use of setenv to set KRB5_KTNAME in your application sufficiently before the very first line of your code that uses gssapi is run.
We are now ready to do the necessary things in the application's code.
I understand there are quite a few other aspects that must be reviewed by the application developer, to write and test an application. I know of a few environment variables, that can be important.
Can anybody please shed some more light upon that?
I'm new to JMS. I'm using ActiveMQ CPP (C++ version), but most probably my questions are language agnostic:
I saw that using didn't worked
failover:(tcp://N.N.N.N)?timeout=1000
while this works
failover://(tcp://N.N.N.N)?timeout=1000
When this change occurred and why?
According to TCP configuration, there's option connectionTimeout, but I don't see in a code. Do I miss something?
Connection options (e.g. connnection.closeTimeout) in case uri looks like failover:://(tc://N.N.N.N?a=b)?x=y should be applied to tcp or failover. Is there good link describing these options in depths?
Thanks
See the ActiveMQ-CPP URI configuration reference here:
http://activemq.apache.org/cms/configuring.html
There are some differences in the URI parsing between the C++, Java and .NET clients due to the available SDKs of each language.
Tim
www.fusesource.com
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What's the best tool that you use to monitor Web Service, SOAP, WCF, etc. traffic that's coming and going on the wire? I have seen some tools that made with Java but they seem to be a little crappy. What I want is a tool that sits in the middle as a proxy and does port redirection (which should have configurable listen/redirect ports). Are there any tools work on Windows to do this?
For Windows HTTP, you can't beat Fiddler. You can use it as a reverse proxy for port-forwarding on a web server. It doesn't necessarily need IE, either. It can use other clients.
Wireshark does not do port redirection, but sniffs and interprets a lot of protocols.
You might find Microsoft Network Monitor helpful if you're on Windows.
Wireshark (or Tshark) is probably the defacto standard traffic inspection tool. It is unobtrusive and works without fiddling with port redirecting and proxying. It is very generic, though, as does not (AFAIK) provide any tooling specifically to monitor web service traffic - it's all tcp/ip and http.
You have probably already looked at tcpmon but I don't know of any other tool that does the sit-in-between thing.
I tried Fiddler with its reverse proxy ability which is mentioned by #marxidad and it seems to be working fine, since Fiddler is a familiar UI for me and has the ability to show request/responses in various formats (i.e. Raw, XML, Hex), I accept it as an answer to this question. One thing though. I use WCF and I got the following exception with reverse proxy thing:
The message with To 'http://localhost:8000/path/to/service' cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher. Check that the sender and receiver's EndpointAddresses agree
I have figured out (thanks Google, erm.. I mean Live Search :p) that this is because my endpoint addresses on server and client differs by port number. If you get the same exception consult to the following MSDN forum message:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2302537&SiteID=1
which recommends to use clientVia Endpoint Behavior explained in following MSDN article:
http://msdn.microsoft.com/en-us/magazine/cc163412.aspx
I've been using Charles for the last couple of years. Very pleased with it.
I second Wireshark. It is very powerful and versatile.
And since this tool will work not only on Windows but also on Linux or Mac OSX, investing your time to learn it (quite easy actually) makes sense. Whatever the platform or the language you use, it makes sense.
Regards,
Richard
Just Programmer
http://sili.co.nz/blog
I find WebScarab very powerful
Check out Paros Proxy.
JMeter's built-in proxy may be used to record all HTTP request/response information.
Firefox "Live HTTP headers" plugin may be used to see what is happening on the browser side when sending/receiving request.
Firefox "Tamper data" plugin may be useful when you need to intercept and modify request.
I use LogParser to generate graphs and look for elements in IIS logs.