Win a copy of Beginning Java 17 Fundamentals: Object-Oriented Programming in Java 17 this week in the Java in General forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Junilu Lacar
  • Rob Spoor
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Jesse Silverman
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Piet Souris
  • Frits Walraven

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

 
Ranch Hand
Posts: 193
14
Hibernate Eclipse IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.



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
Ranch Hand
Posts: 193
14
Hibernate Eclipse IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.



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
Ranch Hand
Posts: 193
14
Hibernate Eclipse IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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



By disabling the request cache the new header was read every time a request was sent.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic