I have a simple CRUD API for a Spring Boot service based on this example.
The API is provided with the following definition:
#RepositoryRestResource
public interface PersonRepository extends CrudRepository<Person, Long> {}
From a curl client, I can get the list of users using the following implicit GET command: curl localhost:8080/persons.
From Java's perspective we just called the remote equivalent of Iterable<Person> persons = personRepository.findAll().
The question is whether spring can auto-create a remote implementation (client) of the same API without the need to manually type paths or know the method type (like needed when using RestTemplate)?
Example of an such a client usage:
PersonRepository personRepository = new PersonRepositoryClient(http://localhost:8080");
Iterable<Person> persons = personRepository.findAll(); // findAll does a remote call as if it was local.
How can I get to such a client "generated" implementation"?
* I know that passing the URL directly contradicts the service discovery architecture, but it's just for the sake of understanding how to get to a well defined client. The same client can be used within a service discovery architecture, by discovering the URL instead of manually setting it.
Try Feign Client. It provides autogeneration of HTTP request handlers for your Java interfaces. To make it work, you need to include Spring Cloud, standard Spring framework doesn't have this feature.
Related
I have api.jar with interfaces annotated with Spring annotations like org.springframework.web.bind.annotation.GetMapping and so on. This api is used as a maven dependency. I would like to generate Rest client basing on given interfaces or use this interface as a source for some kind of proxy object to consume rest endpoints without manual implementation (restTemplate object..)
I have an application that exposes an endpoint using HttpInvokerServiceExporter from Spring. I have been trying to investigate whether or not this is at risk from the Java (Apache commons-collections) serialisation exploit (as detailed here).
I have been trying to generate payloads that can be sent to the endpoint for testing, but I haven't managed to get a definitive answer so far. I have checked out the ysoserial project for generating payloads but I believe the problem with this is that the HttpInvoker expects the serialised Object to be of type RemoteInvocation, which is not what ysoserial generates.
So my questions are:
Is a Spring endpoint configured like this at risk?
How can I generate a payload that would exploit it, so that I can validate that I have closed the exploit after my fix?
I have found the answer to my own questions:
Yes. I have successfully managed to exploit my server using a simple http post to the Spring endpoint.
Spring Http Invoker expects the object it receives to be a RemoteInvocation instance, which contains a method to be executed on the server side (i.e. a method that you are exposing on some interface). It has the following constructor:
public RemoteInvocation(String methodName, Class[] parameterTypes, Object[] arguments)
so to use the exploit you just have to put the object that ysoserial generates into the Object[] arguments. This will result in it being unserialised before attempting and failing to execute the method on the exposed interface and therefore it will execute the command you specified.
I'm trying to use Spring Cloud to consume a generic REST service from a Cloud Foundry app.
This service is created using Spring Boot, as follows:
package com.something;
#RestController
public class DemoServiceController {
#RequestMapping("/sayHi")
public String sayHi() {
return "Hello!";
}
}
This works fine - I can access http://www.example.com/srv/demo/sayHi and get "Hello!" back.
Next, I created a user-provided service instance using the CF-CLI and bound it to my app. I can now see the bound service in VCAP_SERVICES.
cf cups my-demo-service -p '{"url":"http://www.example.com/srv/demo/"}'
cf bs my-demo-app my-demo-service
Next, as described here, I added this bean to my app's Spring config, with the connector-type set to my original controller (I have a reference to it as well).
<cloud:service id="myDemoService"
service-name="my-demo-service"
connector-type="com.something.DemoServiceController"
/>
Now when I auto-wire "myDemoService" into my app,
#Autowired
private DemoController myDemoService;
I get an error:
No services of the specified type could be found.
I've made sure to include all required dependencies, including spring-cloud-spring-service-connector and spring-cloud-cloudfoundry-connector.
What's going wrong here? Am I giving the wrong bean parameters? Any help is much appreciated.
Spring Cloud Connectors won't know what to do with this service, as each supported service must be of a known type (MySQL, Postgres, Redis, MongoDB, RabbitMQ, etc). Setting the connector-type to your Controller class won't do what you want.
What you will need to do is to create a custom Connectors extension. Here's an example of a project that does that: https://github.com/cf-platform-eng/spring-boot-cities.
I'm developing a restful web service that will be consumed by an Android application later on.
Right now, I'm seeking a way to secure the access to my resources:
I found several ways for implementing that on the net, but I can't figure out what is the most appropriate one.
For example, I found that Oauth specifications are more convenient for third-party applications which is not my case.
So what are the most suitable ways for securing jersey APIs, and I'll be glad if someone can provide me with any tutorials/documentations on that.
I'm using a Glassfish v4 server and the Jersey JAX-RS implementation.
After looking at different options I used an authentication filter and basic auth. Very easy to implement.
Some example code:
You need a filter
public class AuthFilter implements ResourceFilter, ContainerRequestFilter {
...
}
And a security context:
public class MySecurityContext implements SecurityContext {
...
}
And a user class:
public class User implements Serializable, Principal {
...
}
Finally, you can add the filters you need like so: (pass your ResourceConfig object to this function)
private void prepareFilters(ResourceConfig rc) {
rc.getProperties().put("com.sun.jersey.spi.container.ContainerRequestFilters",
getClassListing(new Class[]{
AuthFilter.class
}));
rc.getProperties().put("com.sun.jersey.spi.container.ContainerResponseFilters",
getClassListing(new Class[]{
CORSFilter.class, //You might not need this
GZIPContentEncodingFilter.class //You might not need this
}));
rc.getProperties().put("com.sun.jersey.spi.container.ResourceFilters",
getClassListing(new Class[]{
RolesAllowedResourceFilterFactory.class
}));
}
BTW, you can add #Context SecurityContext securityContext; to your resource class(es) or the individual methods for more fine grained access control. The SecurityContext will be injected into the context of your resource so you can access the User object per request with
With this setup you can annotate your REST methods with #PermitAll, #RolesAllowed, etc which gives you a good level of control over your RESTful interface.
I just finished my stateless (without sessions) user auth and management with Jersey.
Let me know if you want a full example or if you want to give it a try yourself ;)
The simplest way would be using the Java EE build-in Container Managed Security model to secure your rest resources as described in this tutorial. It allows you to configure the security based on users and roles stored in a database or file realm in the web.xml or the the classes themselves.
The disadvantage would be that you must start a session, extract the JSESSIONID and send it in each of your requests so that the server can verify it, but that makes your services more 'stateful' and violates the statelessness of the rest architecture.
Another way would be implementing custom security by using WebFilters, like sending the user name and password with each of your requests and verity them based on the information in a special db. If the information doesn't match the information stored in the database a redirect or a special error code can be returend in the Response object.
The best approach I think is using OAuth2 as described in this specification. Dependend on what kind of client you are using (desktop, web page, mobile client) there are different workflows and apart from that lots of benefits like creating tokens for special scopes of your application (read-only or full access,...). Google provides many different apis that can be accessed by the same account. If an applications only needs data from the calendar api, the requested token only gives you access to this special api and not to the entire resources of the account (like mail data, notes, etc). Another point would be that the security handling is decoupled from the client and no password must be stored in the client application.
You can either implement everything on your own or use a open source project like this. It provides a description on how it works and the code is very good but it has many dependencies to spring frameworks. For my use case I've startend replacing them by vanilla Java EE 7 code and create a solution based on the idea of this open source project. The reason behind the replacements was that it's more future-proof and it avoids class loader problems during the deployment.
In the Android app a Authenticator can be implemented for secure storing of the token.
I am in a situation where I have a nascent rest api architecture where each method has tons of ceremony (validation, db connection acquisition/release, authentication), raw request/response objects as the parameters, and hard-coded json strings as the output. I want to use spring mvc to help with at least some of these issues (auth & db stuff i'll need to hold off on). This would render a lot of the current architecture unnecessary. This is pretty easy except for one feature of the current architecture: dynamically adding api calls.
The entry point (servlet) for the architecture reads from an xml file that contains the path for a request and a corresponding class to load. The class must implement an interface that contains an 'execute' method which has the logic for the request. The servlet calls this execute method after loading the class. This allows dynamic extension of the api as follows. The app is packaged as a jar together with the associated config (xml) files and given to a client. The client includes this jar in his project, creates a class that implements the aforementioned interface, and adds a mapping from request url to that class in the included xml file. He then runs the app and gets access to both the original api and his custom api.
Example:
Client is given app.war, interface.jar and custom-mappings.xml. app.war contains the implementation of the core api (rest webservice), and interface.jar exposes the interface BaseController that has the method 'execute' (app.jar also uses this interface in its controller). Client then defines his own class as follows.
package custapi.controllers;
public class ExtendedController implements BaseController {
public void execute(HttpServletRequest request, HttpServletResponse response) {
// LOGIC
}
}
He compiles this class and adds it to app.war. Next, he updates custom-mappings.xml with the following entry.
/custcall/mycall
custapi.controllers.ExtendedController
He then deploys the app. The controller provided with the core api receives the request /custcall/mycall, looks it up in custom-mappings.xml, finds the class is custapi.controllers.ExtendedController, loads that class, and finally runs its 'execute' method. This allows the logic defined by the client to be run.
Ideal:
Current architecture is replaced with spring-mvc. That is, there is no more 'super' controller that parses requests and delegates to the appropriate class and, finally, method. Spring handles this. For the app that uses this new architecture, the client would receive the app.war and the spring mvc deps that expose controller annotations. The client would then create a new spring mvc controller (taking advantage of validation, parameter -> pojo mapping, object -> json conversion), compile it, and add the resulting class file to app.war. His controller would then become an extension to the core api exposed by the app. When the app is deployed, he would be able to make a request /custcall/mycall like before and have it execute the logic he defined. This ideal scenario allows clean code for the core api (which I and others programmed) and an extended api. (A downside to this approach is that the client is tied to spring. In an even more ideal scenario, the client would use framework-agnostic annotations which are mapped to spring annotations by the app. I'm not sure how easy this would be.)
I'm not sure how the above would be realized with a spring-aware controller without sacrificing the benefits of spring. I don't believe the client could simply define another spring-aware controller (correct me if I'm wrong on this). The only solution I can think of is to have a spring-aware controller that has a wildcard path (e.g., /cust_rest/*) which acts exactly the same as the current controller. The client would not get any advantages that spring has to offer, but the core api would be a lot cleaner. I was hoping there was a better solution, however. Ideally the client would get the benefits of spring without having access to the core api source code. Any ideas on this, or is my solution the best that can be hoped for?
Thanks.
(NOTE: For both scenarios, I am only guessing how the client actually gains access to the dependencies/interfaces and deploys. I have only had access to the core api project for one day, and so my understanding of it is not complete.)
Related: Runtime loading of Controllers for Spring MVC and dynamically mapping requests/URLs
The above question looks pretty similar to mine. Replies are sparse (second one is just off topic, I believe).
Provided you setup classpath scanning properly there's no need for interface. Your clients can just annotate classes with #Controller #RequestMapping("/foo/bar"). Even if this class is located in its own jar it will still be scanned. If this is a REST service consider using #RestController instead to avoid having to place #ResponseBody on each handler method.
Use spring security to do declarative authentication & authorization (what you're doing now is programmatic security)