Method Security With @PreAuthorize - RequestHeader Does Not Refresh After 403

[Simon Ritchie]

Hi folks,

I asked this question elsewhere a few days ago but nobody's been able to assist - hopefully someone here can help.

I've developed a method that is annotated with @PreAuthorize. The @PreAuthorize annonation runs a method (called isStringInList(String s)) on a separate class (a @Service that I've qualified as "myStringEvaluationService") to ensure that the method returns true.

@PreAuthorize("@myStringEvaluationService.isStringInList(#myString)")
@RequestMapping(value = "/myEndPoint", method = POST)
void executeThisMethodIfAuthorised(@RequestHeader(name = "whateverTheStringIs") String myString) {
    //do stuff
}

I'm using Postman to send HTTP requests to the method. If I send a String that is on the list the above method executes fine. If I send a String that isn't on the list then the method doesn't execute - this is fine, it's how I want it to behave. It sends a 403 - Forbidden message back to Postman.

The problem is when I resubmit a String that is on the list, I see from debugging that the String that is not on the list is what gets sent for every subsequent request. For some reason the 403 error doesn't result in the myString variable being refreshed. Why might this be happening?  There's obviously some form of caching taking place somewhere but I'm unsure how to clear the cache when it comes to SpEL variables.

[Simon Ritchie]

I've done a little digging on this and I see that the @PreAuthorize interface makes use of an annotation called @Retention and that its Retention Policy is set to RUNTIME.

import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Inherited;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface PreAuthorize {
    String value();
}

What seems to be happening in my example is that when an unauthorized user tries to access the method, a 403 error is returned (as it should) but this 403 has some abrupt effect of forbidding all subsequent access to the method.  Does anyone know if Spring Security handles access on the basis of IP address?

[Simon Ritchie]

Solved the problem.  Bit of a strange situation (I'll explain it here) but one that makes sense when you consider how Spring Security functions.

I had written a Security Configuration class that extended WebSecurityConfigurerAdapter and overrode that class' configure(HttpSecurity http) method.  Initially I had merely included some code to permit any requests mapping onto the endpoint.  What was happening that was causing the problem was that when I submitted a String in the HTTP header that wasn't on the list, Spring Security was caching the URL.  Even though I changed the header of subsequent requests, I wasn't changing the URL and Spring Security considered that URL to be in violation of security and hence blocked the request.

The remedy for this was to include the following two lines of code in the configure(HttpSecurity http) method

http.headers().cacheControl().disable();
http.requestCache().disable();

By disabling the request cache the new header was read every time a request was sent.