ContextHolder and Context Questions

[eisenb]

In case someone knows these answers off the top of their head before I research them by implementing proof-of-concept tests:

1. Is the Authentication conditionally available in the SecureContext based upon whether the user has been routed to an entry point? Trying to understand the conditions that are present when a user hits a non-secured page. If the Authentication is not present, I will not know their granted authorities. I need to understand this so that I can determine how to treat Guests to my website.

2. Unless I missed it, there's not much information about the concept of Custom Contexts. I saw the brief note in the documentation, but that's about it. In specific, I'm trying to decide whether I should implement a custom context to contain a mini shopping cart. My site really only needs Authentication, the Cart, and some User Details. Would it be reasonable to implement a custome context and add to it a get/set for the Cart?

Thanks in advance for anyone's opinion / help.

Bill

[Ben Alex]

The ContextHolder will be non-null if the integration filter - typically HttpSessionIntegrationFilter - copies an Authentication from the HttpSession (or other well-known container location) to the ContextHolder. This doesn't mean the Authentication is necessarily valid or has the correct GrantedAuthority[]s, although it generally implies this (as some presumably trusted code at some stage generated the Authentication and put it into the well-known container location). If you really need to know if the Authentication is correct, you must present it to an AuthenticationManager and use the Authentication it returns. Alternatively, place whatever requires a properly validated Authentication behind a secure object (eg a secure web URL, or a properly configured method which has a security interceptor on it) and the Authentication contained in the ContextHolder will be valid.

In relation to custom SecureContexts, I would not recommend they be used instead of the HttpSession. Your shopping cart should just interact with HttpSession as per normal. A custom SecureContext is helpful if you really need a ThreadLocal-bound object, such as if you have some objects that need to be available to many different methods, and passing them around as method arguments would be inconvenient. Good candidates include system utility type objects, such as authentication, transaction status, datasource, the user's locale etc. On the other hand, a list of items in the cart really is a normal business object that should be passed around only at well-defined events, such as checkout or changing quantities. It really doesn't require a ThreadLocal.

[eisenb]

Thanks for the reply. I'm slowly getting this after repeated reads of the documentation. Its not that its not clear, it just takes a bit to get one's head around it.

Bill