I want to monitor and control Vaadin web application, and for that I need it respond to GET / POST HTTP outside Vaadin session handling.
I could do it as a separate service, but is there a simpler way within Vaadin?
Vaadin is optimized as an opinionated solution for UI. If you want to do generic request handling, then I would recommend a solution optimized for generic request handling such as JAX-RS or Spring #RestController.
Related
I have question related to authorization and spring security. To implement authorization checks in one of my services (under a Service Oriented Architecture environment), I was trying to see if I can use Spring-Security. While going through the Spring Security documentation, I read here that spring security uses spring's AOP internally.
Ref: You can elect to perform method authorization using AspectJ or Spring AOP, or you can elect to perform web request authorization using filters. You can use zero, one, two or three of these approaches together. The mainstream usage pattern is to perform some web request authorization, coupled with some Spring AOP method invocation authorization on the services layer.
We are already using Spring AOP in our service implementations. In my case, the requests that will be coming to my RESTful service will carry a custom built token object that should be processed to perform authorization checks.
Based on this, I would like to understand if I can simply use Spring and create an Aspect to catch an inbound request, extract and process the associated (custom built) token and continue/reject the request based on the result ? Do I need spring-security, given that the communication channel is already secured using HTTPS ?
Thanks,
SGSI
For a similar situation we did the following a long time back:
Used an HTTP filter to extract a token from HTTP headers for each request.
Stored the extracted header to thread context.
Added an aspect around service method calls to check the thread context for the token.
This strategy worked well for us. For last many years I have been using Spring Security since it has a more tested and comprehensive implementation for such problems.
If you wish to write your own token-passing implementation, you can check the source code for the Spring Security class SecurityContextHolder that provides multiple ways of passing security information on the execution thread.
I want to design my application in JSF 2.0 with single entry/exit point for all the requests and responses so that they can be routed through a single managedBean/controller.
The purpose of having this design is to catch my all business exceptions at common place and also it would be easy for me to check for the validation of session for each new request.
One of the option I see is ServletFilter but I am not sure if this would be the best approach with JSF 2.0.
The purpose of having this design is to catch my all business exceptions at common place
Just implement a custom JSF ExceptionHandler.
and also it would be easy for me to check for the validation of session for each new request.
This makes no sense. The container does it already by itself. I believe that you're concretely asking to check a session attribute representing the logged-in user. For that a servlet Filter is indeed the most sensible approach. Some may opt to use a JSF PhaseListener for that, but this is tight coupled to JSF requests and does not kick in on other requests.
We're putting together a series of services using ASP.NET Web API. One proposal is to implement a "choreography" type design pattern where all clients connect to one endpoint and get routed based on the content of the GET and POST bodies. Another proposal is to just call each service directly.
What are the benefits of using a choreography-type design pattern?
Personally, I prefer one URL for all my services. It seems simpler but a single endpoint for simplicity isn't a valid argument.
Update -
I'm open to using headers for the routing portion. We're at "conceptual level" design at the moment and I guess I didn't think about using headers before posting. The body will be JSON. I am proposing this be implemented using ASP.NET Web API 4. Based on the header, the choreographer will route to the appropriate endpoint for processing.
If you are going to route only based on the content of the GET and POST bodies then I would say that you would be reinventing SOAP which is now considered heavyweight and legacy.
If you include the HTTP headers in this decision then you will be more RESTFul which is a good thing. You might also checkout the Web API which might help you with this design.
I am quite familiar with ASP.NET MVC and know that a controller’s method can respond with XML and JSON apart from other things (i.e. behave like a restful webservice). I am just wondering whether I can make a controller method behave like a soap web service which responds with a SOAP XML response to a POST request? Maybe it is just question of responding with XML but this would be more like a restful web service. I want to avoid having to implement a separate web service project if possible. Any feedback would be very much appreciated. Thanks.
Christian
You don't need to implement a separate web service project. All you need is to add a WCF service endpoint (.svc file) to your current web project. Also you are saying that you expect SOAP response after a GET request which of course doesn't make much sense because in the SOAP specification requests should be POST.
I believe your thought is to create a single deployable MVC Web Application that can respond to both SOAP requests and RESTful requests (maybe even more?). I have thought about this myself, however there is no point in re-inventing WCF as it can do both without any additional programming. The ASP.Net MVC assemblies were not designed to function as a web service, and although it can, probably shouldn't be when other technologies exist that were designed specifically for that purpose.
A 3rd party site sends its notifications after my web application has completed some action in order to notify me of its success. Receiving a notification item requires a response back to the 3rd party server (URL) with the a containing the value "accepted".
I have never user SOAP and with the basic info found I'm a bit lost for the case of asp.net mvc. Are there any good links showing the principle of receiving and sending SOAP responses?
Tutorials / information may be presented in other languages such as java, asp.net (classic) or something. I need to get a general idea since googling on SOAP has not given me anything for the past few hours.
You need to learn a little about WCF. See the WCF Developer Center, especially the Beginners Guide.
What you want is to create a simple WCF service that corresponds to the WSDL that they will give you. You will need to implement only the operation (method) that they will call to notify you. You can host a WCF service in IIS along with the rest of your application.
The issue will be how to correlate the notifications with the page you're on in your MVC application.
I don't think this is specific to ASP.NET MVC really. If you have a WSDL for their web service, just use that to generate stub classes using either wsdl.exe or by adding a web reference to your project, then call the web service from your controller.
If I remember correctly SOAP is basically xml requests and responses.
You might want to look into WSDL (Web Service Definition Language) to avoid having to deal with raw data, and you would likely find a great deal of tutorials on wsdl as well.