Typically when writing a web-app we want to perform validation on both client side to offer immediate feedback and on server-side to ensure data integrity and security. However, client-side browser apps are typically written in JavaScript. Server-side can be written in Java, Php, Ruby, Python and a host of other languages. When server-side is backed by something like node.js, it is really easy to re-use the same validation code on both client and server, but if server-side is based on Rails or Django (or whatever other framework you can name), what's the best way to make sure the validation code are kept on sync? It seems a bit redundant to have to re-implement the same code in multiple languages.
If you keep the following persepective in mind, it may seem okay to duplicate certain validations.
Let's break validations into two parts. A) Business Validations e.g. "Amount in Field X should be greater than $500 if if checkbox Y is checked" B) Basic data validations e.g. datatype checks, null checks etc. (We may debate that every validation is business validation but that is purely context specific).
Category A: It is part of your business logic and should be kept only on server side.
Category B: Validations of this type are potential candidates to be placed on the client side. But keep in mind that browser side validation can be bypassed. This does not imply that you should not have validations on browser side at all but such validations should be considered merely a bonus to save network roundtrip from server. Server must re-perform these validations.
In nutshell, validations should not be considered as unit of reusable code across tiers. Their objective varies and should allow redundancy.
Hope this helps.
From projects I've seen there's three general strategies:
Fully duplicate client-side and server-side validation. This would require two different codebases in the case of javascript frontend and java/c#/ruby backend. You'd have to manually keep the logic of both in sync.
Do minimal client-side validation. Check for only very basic stuff. Have server side do the full validation. Have server side pass a validation-errors object of some kind back to the client and have client logic to translate that into UI messages (error messages, red borders, etc). Asp.net MVC framework is roughly an example of this model.
Use ajax to make validation calls into your server side when the user changes or leaves each control. This can allow all your validation on the server side, and will reduce the feedback wait time for the user, but can increase client to server side traffic immensely.
In my experience, option 1 is generally less of a pain point than maintaining the extra code and complexity required for option 2 and 3.
Our architecture allows for validator code-sharing: Our back-end is JAVA. Front-End is JavaScript/TypeScript (Angular if that matters). The JAVA back-end did all business stuff. For reporting MySQL to user and some utility user preferences we also had a minimal back-end written in NodeJS/Express.
To re-use the validation, we changed some endpoints from JAVA to NodeJS, then the NodeJS did the validation and internally passed the request body to the JAVA. (by system-call or non-public API). Then we removed the validation from JAVA code. NodeJS/Express mostly acts as a proxy, it also checks for requests validity.
That way we could share TypeScript codes/classes between Front-End and our minimal Back-End.
The overheads added:
need to run a NodeJS back-end separately from main back-end (one extra process to manage/watch)
need to expose a way to call your methods/APIs internally in the system (and make sure they are not public as they'll no longer have validators)
some extra Nginx routing
i build this serve side validation endpoint:
import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.ObjectMapper;
import lombok.AllArgsConstructor;
import org.hibernate.validator.HibernateValidator;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;
import javax.validation.Validation;
import javax.validation.Validator;
import javax.validation.ValidatorFactory;
import java.util.List;
import java.util.Locale;
import java.util.Map;
import java.util.stream.Collectors;
import static java.util.stream.Collectors.groupingBy;
#RestController
#AllArgsConstructor
public class ValidationEndpoint {
static {
Locale.setDefault(Locale.GERMAN);
}
private final ObjectMapper objectMapper;
private final Validator validator;
#PostMapping("/")
public Map < String, List < String >> validate(#RequestBody String entity, #RequestParam String className) throws ClassNotFoundException, JsonProcessingException {
Class c = Class.forName(className);
Object jsonObject = objectMapper.readValue(entity, c);
return validator.validate(jsonObject).stream().map(constraintViolation -> {
Violation violation = new Violation();
violation.setMessage(constraintViolation.getMessage());
violation.setFieldName(constraintViolation.getPropertyPath().toString());
return violation;
}).collect(groupingBy(Violation::getFieldName, Collectors.mapping(Violation::getMessage, Collectors.toList())));
}
#PostMapping("/valida")
public List < String > validateField(#RequestBody String entity, #RequestParam String className, #RequestParam String propertyName) throws ClassNotFoundException, JsonProcessingException {
Class c = Class.forName(className);
Object jsonObject = objectMapper.readValue(entity, c);
ValidatorFactory validatorFactory = Validation.byProvider(HibernateValidator.class)
.configure()
.failFast(false)
.defaultLocale(Locale.GERMAN)
.buildValidatorFactory();
Validator validator = validatorFactory.getValidator();
return validator.validateProperty(jsonObject, propertyName).stream().map(constraintViolation -> {
Violation violation = new Violation();
violation.setMessage(constraintViolation.getMessage());
violation.setFieldName(constraintViolation.getPropertyPath().toString());
return violation;
}).map(Violation::getMessage).toList();
}
}
Related
I‘m looking for a way to change the header (add some things to it) of the health check of spring boot. I searched for this topic but I only found questions about custom health functions and so on (e.g. How to add a custom health check in spring boot health?).
That‘s not what I am looking for.
I want to use the standard/default health function (so I don‘t want to change the body of the response („status“:“UP“) nor do I want to implement my own health functionality or customize the default one.
My goal is to change the header of the response in order to achieve two things:
add some things to the header (e.g. max age)
reaching cors (e.g. I want to set allow-origin to *, allowed-method to GET and so on), I know there is a way to do it in the management properties but this applied for all endpoints and I only want these tgings to apply for the health endpoint
Is there any way to use the default health check and just modify the header and the properties like allowed origin or do I have to create a new controller?
Thanks for your help.
Just implement your own service with the methods getting the adequate metrics, and then of course your custom controller refering to it. I don't think you can modify those default endpoints..
Here's an example of this custom service:
import java.util.Arrays;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.actuate.metrics.MetricsEndpoint;
import org.springframework.stereotype.Component;
#Component
public class SpringActuator {
#Autowired
MetricsEndpoint metrics;
public Double getCPU() {
return metrics.metric("process.cpu.usage", Arrays.asList()).getMeasurements().get(0).getValue();
}
public Double getRAM() {
return metrics.metric("jvm.memory.used", Arrays.asList()).getMeasurements().get(0).getValue();
}
}
I'm new to web socket programming. I have more than 10 methods annotated with #GetMapping, where the returned data is read from a MySQL database.
Can anyone help me to know how to write WebSockets.
My WebRestController.java looks like the below:
#CrossOrigin(origins = "http://localhost:4200", allowedHeaders="*")
#RestController
#RequestMapping("/api")
public class WebRestController {
#GetMapping("/summary")
public String Summary() { /* ... */}
#GetMapping("/erday")
public String Erday(String erday) { /* ... */}
#GetMapping("/count")
public String Count(#RequestParam Map<String,String> queryParam,
String date, String target) { /* ... */}
#GetMapping("/details")
public String Details(#RequestParam Map<String,String> queryParam,
String date, String target) { /* ... */}
#GetMapping("/devmawah")
public String DevMawah(#RequestParam Map<String,String> queryParam,
String date, String target) { /* ... */}
// ....
}
I tried before many times in internet to find the solution, but couldn't find it. All I found are examples for Chat applications, which have 2 endpoints to send and receive.
WebSockets are used for bi-directional communication, not really for REST style services (where HTTP is superior in my opinion). The core difference being that HTTP is fundamentally a request-reply protocol, which fits very well to REST whereas WebSocket is centred around messages. Of course, you can argue that request-reply is a specialisation of message-based communication.
There are several articles on this topic (google REST over WebSocket) and even some StackOverflow questions which detail the pros and cons, for example Is ReST over websockets possible?.
The only way that I know of which allows you to do something resembling REST over WebSocket without having to re-write the RestController is swagger-socket, but I would not recommend using it as the project seems to be inactive now and it seems to not have been used extensively.
Alternatively, you can replace your #RequestMapping or #GetMapping annotations with #MessageMapping annotations and model your API through messages (e.g. the client sends a "GET" message to a given destination, and you send back a message containing the resources).
I can say 99% of reasons that brings us to the idea of Rest Over Websocket is just because we are looking at the problems from wrong direction.
But I wrote such library because I am going to need it in another dummy project I will write later, and you can check it out.
Basically what it does is to scan your controllers, and create a websocket handler that can pass data to those controllers, depending on path, method, and inputs. But there is a lot more it handles internally to achieve this goal.
I havent started the docs yet, so, you can check the sample from website for now.
Well... Just my little contribution...
First you you should code your websocket handler (taking into account the potential size the payload). Then, you should create a config class to register your hander (I am thinking not in a stomp version).
In your handler, after you stablish the connection with the websocket server, you should have a custom component to hold the sessions (maybe a map of usernames and a session wrapper). This is useful, as you you could send messages not only through the ws connection but also through a rest api endpoint (you could hit an endpoint or using an scheduler tasks to periodically send messages to certain users upon certain conditions). Will post again a link later
I am working on a spring base web application where, we have a few RestControllers and some Request DTO classes. Request DTO contains a token field which needs some validation. So I used spring validators to validate that. After validation, we want to send that field to an external system using another REST API (Just for some kind of analytics logging). The same field is repeated in multiple DTO objects and their controllers. So, I am easily able to define annotations for validators and reuse them across the DTOs. But I am not sure how to process that field after validation succeeds (i.e. call analytics API to consume that field post validation), without mixing it with the core logic of controllers.
Approaches I could think of:
Implement a filter/interceptor and process the field there. But then
there is a limitation that request body can be read only once so I
need to use some alternate ways by creating request wrappers.
Repeat the logic in every controller and it is very error prone as for
every new controller we need to remember to write that code.
But non of these approaches look cleaner. Can someone recommend a better way to achieve that?
Thanks in advance.
You can create a BaseController and implement the method there. Extend this BaseController wherever you need this logging service. Like below.
BaseController.java
class BaseController {
protected void remoteLogging(String name,String token) {
//Calling the remote log services}
}
AppController.java
#Controller
#RequestMapping("register")
public class LeaseController extends BaseController {
#PostMapping("new")
public String new(#Valid #ModelAttribute("registration") Registration registration,BindingResult result){
if(rest.hasErrors(){
remoteLogging("name","token");
}
}
Currently my app looks at router parameter and logged in user (Principal.Identity) to authorize access to certain resources (e.g: Add student to your class [identity + class id]). However, If I'm not wrong, breeze js support just one bulk save. It seems to be that I will have to open each and every data and run through the validation/authorization. That is fine,
but what I may lose is nice separation of cross cutting concern out side my business logic (as a message handler) (finding what roles user has on the class) and nice Authroize annotation feature (just say what roles are needed). So do I have to trade off or is there better programming model which Breeze JS might suggest?
Update:
My question is more on how to separate the authorization (find assigned roles in message handler + verify if required roles are present by adding authorize attribute to controller methods) logic from business or data access logic. Without breeze, I will inspect the incoming message and its route parameter to fetch all its roles then in my put/post/delete methods I would annotate with required roles. I cannot use this technique with breeze (its not breeze's limitation, its trade off when you go for bulk save). So wanted to know if there is any programming model or design pattern already used by breeze guys. There is something on breeze's samples which is overriding context and using repository pattern, will follow that for now.
Breeze can have as many 'save' endpoints as you want. For example, a hypothetical server implementation might be
[BreezeController]
public class MyController : ApiController {
[HttpPost]
[Authorize(...)]
public SaveResult SaveCustomersAndOrders(JObject saveBundle) {
// CheckCustomersAndOrders would be a custom method that validates your data
ContextProvider.BeforeSaveEntitiesDelegate = CheckCustomerAndOrders;
return ContextProvider.SaveChanges(saveBundle);
}
[HttpPost]
[Authorize]
public SaveResult SaveSuppliersAndProducts(JObject saveBundle) {
...
}
You would call these endpoints like this
var so = new SaveOptions({ resourceName: "SaveWithFreight2", tag: "freight update" });
myEntityManager.saveChanges(customerAndOrderEntities, {
resourceName: "SaveCustomersAndOrder" }
).then(...)
or
myEntityManager.saveChanges(supplierAndProductEntities, {
resourceName: "SaveSuppliersAndProducts" }
).then(...)
Authorization is mediated via the [Authorize] attribute on each of the [HttpPost] methods. You can read more about the [Authorize] attribute here:
http://sixgun.wordpress.com/2012/02/29/asp-net-web-api-basic-authentication/
The proper way to do this IMHO is to separate the endpoint authorization and the database actions authorization.
First, create an entity that manages the grands per controller/method and role. For each method you have a value allowed - not allowed for the specific role. You create a special attribute (subclass of Authorize) that you apply to your controllers (breeze or plain web api) that reads the data and decides whether the specific endpoint can be called for the user/role. Otherwise it throws the Unauthorized exception.
On the breeze side (client) you extend the default adapter settings with a method that adds the authentication headers from identity that you received at login, something like this :
var origAjaxCtor = breeze.config.getAdapterInstance('ajax');
$.extend(true, origAjaxCtor.defaultSettings, Security.getAuthenticationHeaders());
On the server, add a second entity that manages the authorization for the CRUD operations. You need a table like (EntityName, AllowInsert, AllowUpdate, AllowDelete). Add a BeforeSave event on the Context Manager or on the ORM (EF or something else) that loops all entities and applies the policy specified on the table above.
This way you have a clear separation of the endpoint logic from the backend CRUD logic.
In all cases the authorization logic should first be implemented server side and if needed should be pushed to the clients.
The way breeze is implemented and with the above design you should not need more than 1 save endpoint.
Hope it helps.
However, If I'm not wrong, breeze js support just one bulk save.
That is entirely wrong. You have free reign to create your own save methods. Read the docs, it's all there.
I'm using Google's Preconditions class to validate user's input data.
But I'm worried about where is the best point of checking user's input data using Preconditions class.
First, I wrote validation check code in Controller like below:
#Controller
...
public void register(ProductInfo data) {
Preconditions.checkArgument(StringUtils.hasText(data.getName()),
"Empty name parameter.");
productService.register(data);
}
#Service
...
public void register(ProductInfo data) {
productDao.register(data);
}
But I thought that register method in Service layer would be using another Controller method like below:
#Controller
...
public void register(ProductInfo data) {
productService.register(data);
}
public void anotherRegister(ProductInfo data) {
productService.register(data);
}
#Service
...
public void register(ProductInfo data) {
Preconditions.checkArgument(StringUtils.hasText(data.getName()),
"Empty name parameter.");
productDao.register(data);
}
On the other hand, the method of service layer would be used in just one controller.
I was confused. Which is the better way of checking preconditions in controller or service?
Thanks in advance.
Ideally you would do it in both places. But you are confusing two different things:
Validation (with error handling)
Defensivie Programming (aka assertions, aka design by contract).
You absolutely should do validation in the controller and defensive programming in your service. And here is why.
You need to validate for forms and REST requests so that you can send a sensible error back to the client. This includes what fields are bad and then doing localization of the error messages, etc... (your current example would send me a horrible 500 error message with a stack trace if ProductInfo.name property was null).
Spring has a solution for validating objects in the controller.
Defensive programming is done in the service layer BUT NOT validation because you don't have access to locale to generate proper error messages. Some people do but Spring doesn't really help you there.
The other reason why validation is not done in the service layer is that the ORM already typically does this through the JSR Bean Validation spec (hibernate) but it doesn't generate sensible error messages.
One strategy people do is to create their own preconditions utils library that throws custom derived RuntimeExceptions instead of guava's (and commons lang) IllegalArgumentException and IllegalStateException and then try...catch the exceptions in the controller converting them to validation error messages.
There is no "better" way. If you think that the service is going to be used by multiple controllers (or other pieces of code), then it may well make sense to do the checks there. If it's important to your application to check invalid requests while they're still in the controller, it may well make sense to do the checks there. These two, as you have noticed, are not mutually exclusive. You might have to check twice to cover both scenarios.
Another possible solution: use Bean Validation (JSR-303) to put the checks (preconditions) onto the ProductInfo bean itself. That way you only specify the checks once, and anything that needs to can quickly validate the bean.
Preconditions, validations, whether simple or business should be handled at the filter layer or by interceptors, even before reaching the controller or service layer.
The danger if you check it in your controller layer, you are violating the single responsibility principle of a controller, whose sole purpose is to delegate request and response.
Putting preconditions in service layer is introducing cross cutting concerns to the core business.
Filter or inceptor is built for this purpose. Putting preconditions at the filter layer or in interceptors also allow you to “pick and match” rules you can place in the stack for each servlet request, thus not confining a particular rule to only one servlet request or introduce duplication.
I think in your special case you need to to check it on Service layer and return exception to Controller in case of data integrity error.
#controller
public class MyController{
#ExceptionHandler(MyDataIntegrityExcpetion.class)
public String handleException(MyDataIntegrityExcpetion ex, HttpServletRequest request) {
//do someting on exception or return some view.
}
}
It also depend on what you are doing in controller. whether you return View or just using #ResponseBody Annotation. Spring MVC has nice "out of the box" solution for input/dat validation I recommend you to check this libraries out.
http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/html/validation.html