Geek Answers Handbook

Is it a good idea to use aspects as a method to remove security checks from application logic?

Kind of a long headline, but this is usually a question.

I want to know if you think it is a good idea to do the following.

Instead:

public void buyItem(int itemId, int buyerId) { if (itemId <= 0) { throw new IlleglArgumentException("itemId must be positive"); } if (buyerId <= 0) { throw new IlleglArgumentException("buyerId must be positive"); } // buy logic }

I want to have something like:

 @Defensive("isPositive(#itemId, #buyerId)") public void buyItem(int itemId, int buyerId) { // buy logic }

Do you think this is good / terrible / too bizarre / too slow? If you really think this is good, I was thinking about using SpEL to implement it, does anyone have a better / lighter / faster mindset?

Thanks,

+8
java coding-style spring-aop aop
source share
5 answers

This is not necessarily bad, but your simple case can be solved with the help of excluding operators ( rather than the statements that I originally mentioned).

It seems you are presenting your own set of annotations that other developers in your project should adopt and adapt. However, once you have entered the annotations, it seems that the usual Proxy approach will be the best candidate for solving the problem.

To summarize: the problem you described can be easily solved using standard java alternatives, although in a more complex case it can be justified (for example, @Secured in spring-security), especially if you are developing your own framework.

+3
source share

I think that it's

  • conversions
  • encapsulation violation, relying on an external aspect (which might or might not be there) to preserve the invariants of the object
  • confusing
  • inefficiently
  • without adding value

I like to use the Guava Preconditions class for such checks. Moreover, such checks are part of the business logic, IMHO.

+2
source share

I think you meant annotations, not aspects. Aspects are usually external to the code they advise. In any case, you can perform the checks that you highlighted in your message, JSR 303 . Example:

 public void buyItem(@Min(value = 1) int itemId, @Min(value = 1) int buyerId) { // buy logic }

There are currently two well-known implementations of JSR 303:

+2
source share

It looks like validation . FYI, several frameworks already exist, see this question and OVal for an example.

I do not know about the performances, but for me it is not too difficult: you save only the logical code. I like to work with it.

+1
source share

I would prefer the Java assertion approach .

  • This is a standard approach, so all (most?) Java programmers will understand this. Automatic equipment, etc. Also able to analyze it.
  • you do not need to develop anything yourself. I know this looks trivial, but these things have a habit of escalation.

If you cannot demonstrate that your approach is clearly better or something else, I would use the tools and APIs that Java provides as standard.

0
source share

More articles:


All Articles