When we say we have declared our form bean in session scope, few questions arise :
NOTE : A session is per client.
Assumptions :
a)Form bean object is in session.
b)In reset() method, we access the fields of form bean object, that is there in session.
Q-1) When is this session created and destroyed ?
Q-2) Will reset() method will be called for each user request? Is yes, then we usually reset the field values in reset(), then how come these values will be available throughout session ?
Q-3)are request scope attribute values are available after validate() method ?
The container is responsible for session management.
For each request to an action that uses a given form. Because usually fields aren't reset; it's mostly to deal with checkbox defaults, although there are other uses.
Of course; otherwise the values wouldn't be available in the action.
Related
I have an application whereby I'm creating a scope via IServiceScopeFactory.CreateScope.
From this scope, I first create an ILogger<T> and then add a scope to this logger.
var logScope = scopedLogger.BeginScope("SignalR connection. signalRConnectionId: {signalRConnectionId}", context.ConnectionId);
After this, I create various services (via the created scope), each of which I want to preserve the
logging scope I created.
This works fine initially, and I can see the scope against messages logged in the service constructor.
However, on later use, the logger that the service has, has lost the scope.
It has not been disposed, the IServiceScope has not been disposed, it just disappears.
My premise seems sound as it works in the initial constructor, but is somehow losing it along the way and I cannot see why that would be.
For a non-trivial setup involving session concurrency control, authentication is not equivalent to login. For example, a user can be authenticated successfully but still redirected to a logout or error page if this is a second login attempt and max-sessions="1". If I have post-login logic that needs to be invoked at the point of login (not authentication), what is an optimal way to incorporate this logic into a Spring Security-based webapp? The solution I came up with, based on my limited understanding of the framework, was to implement my own custom ConcurrentSessionControlAuthenticationStrategy adapter extending the framework's ConcurrentSessionControlAuthenticationStrategy and inject it into CompositeSessionAuthenticationStrategy in my Spring Security configuration XML. I created a 1-arg constructor and onAuthentication method. onAuthentication performs my post-login processing before calling super.onAuthentication. Is there a better way to do this?
My custom onAuthentication method looks something like
.
.
if (sessionCount < allowedSessions) {
// Record login timestamp in database
Date now = new Date();
userDao.setLastLogin(now);
userDao.save();
}
super.onAuthentication(...);
Because sessionRegistry member variable is declared private (as opposed to protected) in the parent, I had to declare my own sessionRegistry and initialize it inside the 1-arg constructor so that my onAuthentication method would have access to it.
Shiro provides cache feature but in my case, I'm using dynamic roles and permissions for the users. I need to expire the cache for a particular user if any so that changes in permissions immediately affect to user.
There is a method in Realm, but how I get an instance of associated realm to invoke method to clear cache.
I ended up exposing the private method "clearCachedAuthorizationInfo" in the extended Realm of AuthorizingRealm. Then just pass in the principals.
public class MyRealm extends AuthorizingRealm {
//...
#Override
public void clearCachedAuthorizationInfo(PrincipalCollection principals)
{
super.clearCachedAuthorizationInfo(principals);
}
//...
}
to clear the authorization cache:
realm.clearCachedAuthorizationInfo( SecurityUtils.getSubject().getPrincipals() );
I think this is a bit cleaner/safer because this method has additional checks against null on the cache and will ensure you get a reference to the cache if one exists. Simply calling getAuthorizationCache() doesn't do this and may or may not work all the time.
You do need to maintain a reference to the realm. I did this by initializing Shiro via Spring and then injecting it as a Singleton bean wherever I needed it.
If you check out the source of the method getAuthorizationInfo in AuthorizingRealm, you see it is simply using a key/value store to cache the authorization info.
It uses the PrincipalCollection object as a key.
So if you call something like:
realm.getAuthorizationCache().remove(SecurityUtils.getSubject().getPrincipals())
the cache should normally be cleared.
I'm still pretty new to JEE6 having come from a Servlets + JSP style of development on legacy systems. In the applications I worked on we would just throw objects into the various supplied scopes (request, session and application) keyed on a constant String. For example, the User object that represented the currently logged in user would be in the session scope keyed under "current_user".
I've done the same in our new JEE6 application, when the user logs in the User object is bound into the session scope. I'm wondering though if there is a better, more EE, way of handling this?
The problem I'm having is that now I've got the User stored in the session it's awkward to get access to it again. I can get it via JNDI look up or with a few lines of boiler plate code involving FacesContext but neither are very elegant.
Rather than boiler plate code all over the place (the User object is need in a few places) it would be great if I could just get the object injected into a field or method. After all there can only be one object in the session bound to a particular name so there shouldn't be any ambiguity about what I'm asking for. Is this possible?
Maybe the CDI could be of any help?
Could you define the way you achieve the User object into one, main method?
If so, and you're working with Java EE 6 environment, you could use the Producer method. Something between these lines:
public class ClassWhichCanAccessUserObject {
#Produces
public User produceUser() {
User u = ... // get the user as you do it right now
return u;
}
}
Then in the place you want to use this class you just Inject it (in the field or method) and use it:
public class MyLogic {
#Inject
User u;
}
You need to remember to add the beans.xml file to your classpath, as without the CDI will not work for your module.
Long post - sorry....
I'm doing input validation for a WCF service and using StructureMap IoC to instantiate the appropriate validation objects.
I have 2 different validation groups:
Per object validation: means that one input parameter, will be resolve by the Ioc (e.g. Ioc.ResolveAll<IValidatorObject<InputParameter1>, .... <InputParameter2>... etc). If any rules are found, the validate method is invoked.
Per context validation: mean that validation rules are invoked, based on the current context (explicit roles). A context could be 'deposit money' or 'open bank account'. Context validation are usually dependent on 2 or more of the input parameters and is the key difference between object and context validation.
The input validation is performed in the BeforeCall event call in the IParameterInspector (provider/server side!). With this event I get a string containing the operation name (aka. the context) and an object[] with the input parameters.
The problem is that there's multiple validation rules for a single context and the only way I have figured out to register the context in the Ioc, is by using named intances. However I can only register 1 named instance pr. interface. And the interface is not uniquely identifiable by its signature. E.g.
Context rule for 'create account': IValidatorContext<User, Account>
Context rule for 'deposit money': IValidatorContext<User, Account>
So my question is, whether it is possible to register the context in StructureMap in any other way than named instances - or maybe a way to group named instances.
An alternative route, is to implement explicit interfaces for each context, so that the DepositMoney service method might look like this:
public Response Deposit(IDepositMoney inputArguements)
where IDepositMoney contains the input parameters.
So am I way off here, or can I somehow register a context in StructureMap? Or should I just go ahead and use explicit interface instead (3rd option?)
Thanks in advance
Ended up wrapping each set of input parameters in a context and used the context to register in StructureMap. Works like a charm!
The whole idea of named instances is that the name points to a single instance, so you won't be able to use that feature to do what you are trying to achieve. I would use explicit interfaces, since this will allow you to auto wire more things and have less calls to your container.