I referred this tutorial to restrict certain ip in jboss and Spring Boot application.
http://www.mastertheboss.com/jboss-web/jbosswebserver/how-to-restrict-access-to-jboss-web-application-by-ip-or-host
But the tutorial is not complete. Where should I place those codes? Are there any other methods to do that?
If any one know any other methods please mention that here. Thanks in advance.
IMO the Valves mentioned in tutorial are the ways to customize tomcat embedded into the Jboss application. Note that this tutorial is really old - from 2014, probably JBoss has changed since then.
I remember back that times JBoss indeed included Tomcat inside to handle the web requests, so probably there was some kind of server.xml of tomcat.
Now, there are other ways:
Place the application behind some proxy that would restrict the access. Probably its the best approach if your environment supports that.
Use filters inside the application. You can create a web filter and register it in spring boot application regardless whether its a Jar with embedded server or WAR that you're planning to deploy on JBoss. This can be really flexible but on the other hand it includes some java coding and will consume some resources of your application. You can use this approach if you don't have spring security in your application and you don't want to introduce one, otherwise read (3).
Kind of paraphrase on 2 but used with spring security, that has the filtering facility built in: here is how you can do that. Note that besides the actual Java code used for implementation, 3 and 2 are pretty similar.
I'd approach this problem in the following way:
If the IP where connections are accepted is subject to change, I'd configure reverse proxy like nginx. This would mean you don't have to redeploy or restart your application if the IP address changes. Please see this guide for details on how to configure nginx: https://docs.nginx.com/nginx/admin-guide/security-controls/controlling-access-proxied-tcp/
Otherwise I'd refer to this article: https://access.redhat.com/solutions/18412 describing the following configuration in WEB-INF/jboss-web.xml:
<valve>
<class-name>org.apache.catalina.valves.RemoteAddrValve</class-name>
<param>
<param-name>allow</param-name>
<param-value>127.0.0.1,127.0.0.2</param-value>
</param>
</valve>
</jboss-web>
To me this concern should be handled on infrastructure level, not in application container. I would suggest to look into AWS Security Groups or equivalent concepts in other cloud providers.
If you are running it in private cloud/bare metal, you should investigate to restrict it on transport layer your infrastructure provides. There should be some possibility to configure firewall rules.
Related
We are currently developing a web application for college and we would like some advice from a more experienced developer.
We have a backend using Hibernate to operate on a MySQL database. Another project is the web UI that uses the API delivered by the backend (registering user, fetching data associated with certain profiles etc.). We use the JSF framework (RichFaces) for the UI. Everything is built using Maven.
The technology we can't decide on is for the communication between UI and logic modules. The first option is to use ApacheCXF to provide SOAP webservices that UI can be a client of. The second option is to use EJBs to invoke backend methods from the UI module.
What approach is more widely-used? As far as we read on the Web, using EJB is faster than SOAP webservices. On the other hand, we don't have any experience with EJBs using Tomcat (we would prefer using Tomcat since it seems to be a cheaper option, however we don't know what we would have to do in order to use EJBs with Tomcat). Additionally, working with webservices since the beginning will allow us to add support for different platforms (for example, Android).
Another aspect which we are discussing is about how should the application be deployed. The alternatives we have considered right now are:
Deploy it as a single WAR project (which would solve the problem we have about communicating the UI with the backend of our application).
Deploy two WAR projects in the same server using webservices for communication between the projects. (We have a prototype using this approach deployed on a Tomcat server)
Deploy a WAR project and EJB project.
Deploy an EAR project which would contain the references to the WAR and EJB projects. (We have a prototype using this approach deployed on a Glassfish server)
The project right now is starting, so we will only be handling a couple hundreds of users right now. However, if the project succeeds we would need to deal with a couple million of users.
Any advice would be appreciated. Thanks.
Edit: So any advice about how the project should be deployed? Is it necessary to use EAR? Is there any advantage if we deploy the project as an EAR module?
Edit 2: We found the advice we needed on this thread: Deploying java applications (Tomcat/Glassfish)
First things first. I would avoid using Web Services if there's no need for it. If you feel that you might need to call this system from external programs and platforms, then go for it. Even then, I would only use the web service interface for external integration, and still have an internal EJB implementation.
EJBs are awesome for enterprise applications. I would highly recommend that you look into that. They provide support for EJB Pooling, Transactions, Aspect oriented programming, Security, Stateful sessions, Java Messaging, JNDI etc. And you can inject them directly inside a Managed Bean (JSF). You said that you will eventually handle millions of users, so I assume that you will want your application to run as fast as possible, I don't think SOAP web services will be a good fit. Remember that SOAP web services encode messages as text, so if your application will be sending binary files etc, then you'll suffer significant performance issues.
As far as deployment goes I would go with an EAR, or a WAR for the JSF and and EAR backend. you can use Injection to pull the classes you need, even remotely, from multiple web applications and other EAR apps.
I'm not sure why you say Tomcat is Cheaper. Glassfish open source edition is a fully functioning JavaEE6 Server and its free. JBoss is also JavaEE compliant and is free. both of them are used in lots of production environments. I find glassfish to be much more user friendly, and would recommend it to EJB noobs :)
I also started with Tomcat, but now I don't use it at all. why use the servlet container only, when you can have the whole shabang? hope this helps.
we use ApacheCXF at work and its has SOAP and Restful. Reliable and relatively easy to setup. I am not sure why you want to use glassfish maybe it's preference but you can implement your projects in eclipse too. It's really that is up to you and your team and the requirements and skill sets your team may have to build and support, that a side CXF webservice+apache + eclipse with maybe two war files would be a good path.
I wouldn't use web services in this case. You can use managed beans as controllers.
Put the logic into EJBs, views into rich faces and control the flow using managed beans.
If you use maven you can generate a project with the structure of EAR (war for web module and jar for ejbs). I don't remember the name of an archetype but you can find it easily.
I have an existing Java application (Spring based) that currently does NOT have a web interface, nor does it run in a web container. It packages up nicely with a start program and just works.
What I need to do is add an administrative web interface for some administrative type things, retrieving real time metrics, and perhaps some graphs to give the users a warm fuzzy feeling knowing that everything is working. As we are a Spring shop, and some of our web applications already use Spring MVC it only makes sense to us, however, I'm not happy with the suggestions I've had from our internal Spring folks on how I should procede.
What would be the ideal way to bolt on this web interface?
Convert my application to a web application and have a web container launch the application. I not too keen on this approach is the web tier is really secondary to the primary application.
Create a separate project that packages as a war, embed Jetty in my existing app and have it load the war. I think I can use the context loader listener to make the root context of my application the parent to the web application spring context. This would involve breaking up my Maven project into 2 projects I believe. I can't use an existing web technology for communication between the web tier and the primary application as my primary application is not web enabled.
Embed Jetty and put the Spring MVC stuff directly in my app. While I've done this approach before, it does involve some ugliness - for instance exploding the JSP tag libs into my jar.
Any thoughts on some clean separation here?
Also of note, my current jar contains some utility applications which some shell scripts launch. Going a pure WAR route would make this not so easy, since I can't juse point java at my war file and choose a class to execute.
Thanks.
If it's true that web is just a minor addition the application, migrating it to WAR and deploying in servlet container might be an overkill. Embedding web server/servlet container looks much simpler, although it doesn't have to be Jetty or Tomcat. You can use web server built into JDK or write one on top of netty or even raw sockets. But that's a hell to maintain.
Yet another solution to springs to mymind when reading:
web interface for some administrative type things, retrieving real time metrics, and perhaps some graphs
Maybe you don't need an interface, but monitoring infrastructure instead? Check out JMX (Spring has great support for JMX) - and write a second web application that simply connects to your standalone Java app via JMX and displays the metrics in fancy way. Another approach is to expose JMX via Jolokia, which translates JMX to REST services.
This approach has several advantages:
monitoring API is universal, and you get it for free
you don't have to use web client, monitoring application is completely decoupled,
finally changes to your original application are minimal. Check out this proof of concept: 1, 2.
It really depends on the structure of your existing Java/Spring app and how much of an API it provides. I've done something similar to this and I approached it by creating a separate Spring MVC project and then specified the existing Java app as a JAR dependency.
This is easy with Maven (or Ivy, etc) and provides nice decoupling. The trick is to be able to write service classes in the Spring MVC app which then access data via your dependent Spring app via a simple DAO class. That's why I stated at the beginning, that it depends on the structure of your original Java app. It has to be able to provide an API for data access that you can then plug your DAO (impl) into.
If this is not easily done, then the next option I'd suggest is simply converting your Spring app to a Spring MVC app. I've worked on another app where we did this. Using Maven, its possible to specify that the build can create either a war file or a jar file (or both). So it can be deployed as either a webapp (via war) or a normal app (via jar). Yes, the jar version has a bit of bloat but its a worthwhile compromise.
The question of embedding Jetty or using Tomcat via a war file is a completely separate issue that has its pros and cons. It shouldn't affect the approach you take in architecting the web app in the first place.
I would like to use the Config Admin service to manage configuration for my services. Since I'm just starting to use OSGi, I would like to introduce it step by step. So, I would like to keep some of my applications as they are now, without executing them inside an OSGi framework. But, I would also like to be able to use the Config Admin service from these legacy applications, so they can also get configuration information as other OSGi services.
Is it possible to do with OSGi? By looking at the specs, I've found a specification for Foreign Applications Access. I don't know if it's related to my problem. If it is possible, where I can find resources about how to make my legacy applications interact with the Config Admin service.
I precise that I'm using Apache Felix in the case it's implementation specific.
Thanks
Basically what you want to have is code the can run inside as well as outside OSGi. When in OSGi you want to leverage the config admin service. Is that correct?
So a good solution for this is following the principle of dependency injection. You code should not load configs, instead it should expect the config to be injected. For example use a setter where you need a config attribute. Outside of OSGi you can use spring or hand code injections to set the configs. Inside OSGi you could use an Activator or a blueprint context. Both will be inactive when you do not run in OSGi so it does not hurt to always have them.
See my first Apache Karaf Tutorial for how this works. The tutorial only shows the setup for OSGi but it is easy to see what you would need to do outside OSGi to configure the example.
Karaf Tutorial Part 1 - Installation and First application
I have a java server application that would like to provide Http
interface to for administrative tasks such as monitoring and
configuring it at run-time and such.
I have some idea that JMX would provide me with a neat standard
interface that if I implement, I would provide a nice standard
management interface that ALL types of management console applications
can use to administor my Server application.
I am wondering if Jetty has a part to play in all of this running
in-process (embedded) into my java application?
what do you think is a best way of managing/monitoring my java application using a web interface?
Appreciate your help
We added a jmx rest interface option in jetty some time ago that might be useful here.
http://webtide.intalio.com/2011/05/jetty-jmx-webservice/
It could easily be pulled from for an admin like interface for management or presentation purposes.
JMX would allow you to expose configuration points for your application. This is required if you desire a programmatic/automated way of configuring your application. Using JMX to configure application is not desirable for a naive users. It is not very likely that they would know how to use JMX. Instead a graphical console would appeal to them. They can simply see what they need to configure, refer any reference material or help and just do it.
It is desirable that you have both the options; a web console and also the JMX way for programmatic access.
Secondly, you dont need a any third party server to JMX-enable your application. You simply create an instance of MBeanServer and it will host your mbeans.
I'm working on an OSGi-based application that uses org.osgi.service.http.HttpService which does not support the use of Servlet Filters.
Before I realised that I wouldn't be able to use Servlet Filters I was planning to apply a couple of existing Filters. These Filters set the appropriate HTTP headers to:
prevent caching of responses
control rendering in IE8 with the X-UA-Compatible header
What are my options here? I don't want to use meta elements to control caching since that technique is unreliable. Using a meta element to set the X-UA-Compatible header is probably acceptable, but I'd still be interested in alternative approaches.
You can use dm Server to deploy WAR files directly into an OSGi environment. WARs that run in dm Server are fully WARs and fully bundles.
There is work underway to standardize what it means to be a WAR on OSGi. This spec is called the OSGi Web Container. Work is progressing very nicely and I'm a good way along with the reference implementation for it. I'll be making the alpha code of the RI available in 4-5 days along with a blog entry detailing the usage. Keep an eye on the SpringSource blog at blog.springsource.com.
I unfortunately can't link to dm Server because I'm a new user :(
This issue for adding servlet filter support offers some potential workarounds.
Also:
Pax Web [extends] OSGi Http Service
with better servlet support, filters,
listeners, error pages and JSPs and
some others in order to meet the
latest versions of Servlet specs.
Since Eclipse 3.5 you can define filters using the org.eclipse.equinox.http.registry.filters extension point.
Regarding Pax Web:
Examples on the paxweb/Examples page don't work.
For example, I enter this command:
pax-run scan-file:jar:mvn:org.ops4j.pax.web.samples/provision!/sample-helloworld-wc.bundles
than point my browser to:
http://localhost:8080/helloworld/wc
result:
Error 404 NOT_FOUND
Also, it is not clear for me from the documentation, if Pax Web would work inside of non-OSGI servlet engine, e.g. WebLogic, WebSphere.
Pax web will not yet work inside a non-OSGI servlet engine (bridged mode). Apache Felix has a good solution for this at http://felix.apache.org.