I'm working with struts2, hibernate and spring and using model driven pattern. It seems that there is a serious issue when trying to fetch an object with 2 different users and sessions (also different computers) at the same time exactly.
More info...
Let's say we have a Project object which has 2 members - user and name.
Both users will try to fetch their Project object (which is a different object for different user of course). So User A would have a project with id 498 and User B would have a project with ID 499.
The struts action would recognize that they're trying to fetch an object with different ID but it seems that both of the users have the same Project object instance and therefore they see the same result.
You could see in the log provided here:
2011-12-08 14:07:21 LoginInterceptor [INFO] User 17 is invoking populateProject, params: id=499
2011-12-08 14:07:21 LoginInterceptor [INFO] User 4 is invoking populateProject, params: id=498
2011-12-08 14:07:21 ProjectAction [INFO] Obj: hbn.Project#e2df60d, Session User Id is 17, obj.user.id is 4
2011-12-08 14:07:21 ProjectAction [INFO] Obj: hbn.Project#e2df60d, Session User Id is 4, obj.user.id is 4
How could I solve it?
Thanks,
Ron.
As per discussion we have i am posting the cause of the problem and solution.
The scope was not set for the action being created by spring plugin and by default they have a scope of singleton.
In struts2 each action also work as a domain object so Struts2 always create a new instance of an action per request and place it on value stack.
in above case scope was singleton and which was the cause of problem since both user have same action object being passed by the spring due to singleton scope .Setting scope=prototype solved problem
for more details refer the official plugin page
Struts2-Spring plugin
Related
I am wondering how to set up the netcore dependency container for mvc with one instance per user.
According to https://learn.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection#service-lifetimes-and-registration-options there are currently only three methods of specifying a lifetime: singleton(one instance per application), scoped (one instance shared within a HttpRequest), transient (one instance per DI instance request)
Has someone attempted to do create on instance per user yet? I would be curious how it's done - if not i will probably dig through the docs at some point to see how it can be done and share the solution.
Create instance on first user request and keep it alive (for next requests) until with some expiration timeout... This looks like a Sessions.
You may register your service with factory method and analyze current Session inside.
If this is an asp.net core application, middleware that is automatically added to the middleware pipeline handles creating a new DI scope at the start of a request, and disposing of that scope at the end of a request. This scope is stored in HttpContext. This scope will be used when injecting MVC controllers etc. Therefore if you want to have per-user services injected into your MVC controllers / action methods, you'll need to replace this scope in HttpContext with your own one built for the current user. You'd have to do this with middleware which would have to run after the authentication middleware (so after the current user was established). Your custom middleware would look at the current authenticated user, and the GetOrCreate the IServiceProvider (container) held in some cache with probably a sliding expiry. With the per user IServiceProvider in hand, it would then create a scope for the current request and replace the scope currently in HttpContext with this user specific one, also ensuring its disposed of at the end of the request. The thing is, when building the per user container, if you create a new ServiceCollection for each user and register a few services and build and cache that IServiceProvider for that user, you won't be able to resolve any services that you've only registered at the application level I.e on startup. This is where the concept of child containers are handy, which microsoft doesnt implement out of the box, but you can use if you switch to using another DI provider like Autofac. Autofac provides an implementation of IServiceProvider and the ability to spawn child containers. If you used this mechanism you could create a child container for each user, which means it would still be able to resolve all your higher level services, but now you can also resolve the user specific services. If you do all this, you'll be able to have per user services injected.
It's a fair amount of work. If there is enough interest I'd consider adding this feature to my multitenancy library as it already does something similar to create per tenant containers: https://github.com/dazinator/Dotnettency
something like that?
var shoppingLists = new Dictionary < string,
ShoppingListStateContainer > ();
services.AddTransient < ShoppingListStateContainer > (s = >{
var userName = s.GetRequiredService < AuthenticationStateProvider > ().GetAuthenticationStateAsync().GetAwaiter().GetResult().User.Identity.Name ? ?"null";
lock(s) {
if (!shoppingLists.ContainsKey(userName)) shoppingLists.Add(userName, new ShoppingListStateContainer());
}
return shoppingLists[userName];
});
Our problem is a very basic, simple implementation of editing the database using JSF + EJB.
Keeping things short:
two separate XHTML views, use two separate Managed Beans #RequestScope.
WebuserListBean and EditWebuserBean, and with #ManagedProperty we inject WebuserListBean, so we could obtain selected user data. So far no problems. Views are filled with data succesfully!
BUT!
We want to be able to edit the user!
And here (to my surprise) we cannot overcome the problem.
1st try:
Because the request scoped bean is dead after filling the view, on Save() method the #PostConstruct tries to launch again, of course it can't. So we couldn't even obtain it from database or anything.
2nd try:
Because the request scoped bean is dead after filling the view, if we do not set up user as field in #postconstruct, we lose our connection with user object which was linked on previous view (and injected, but now that view is dead too).
3rd try:
Cannot inject RequestScope in ViewScoped
Ok and our restrictions, because we think it's wrong way:
We dont want to create a SessionScoped Managed Bean for this
We dont want to use any params etc. We want to use EJB
We are not sure if we could store data in Stateful session bean which is our
endpoint for the module? Is it proper approach?
Thanks for any advice, we could paste some code but i guess it is pointless!
Cheers!
There are many ways to do it, but I recommend using the flash if the pages involved in the navigation are in the same folder (I recently found out reading a BalusC answer that there is a known issue with the flash, in which it will not hold values when navigating between pages in different folders!).
The flash is a way to hold parameters for a little longer than the context of a single request (concept taken from Ruby if I'm not mistaken, someone correct me if I'm wrong), allowing for the sent parameters to be fetched in a subsequent view, for example. Those values are discarded in the second request issued after saving them, if I'm not mistaken. You can inject the flash in your managed beans like this:
#ManagedProperty("#{flash}")
private Flash flash;
public void setFlash(Flash newFlash) {
flash = newFlash;
}
Then, you access it like a map with the put and get methods. If you use the put method in a bean, return a redirection rule and, on the second bean, use the get method your object should be there.
You can also find a highly comprehensible guide of communication in JSF (listing a really extensive list of options) here, in particular if you need to navigate between pages in different folders.
I am using the new Spring Security 3.1 and have a few questions to Spring Security ACL.
So let's say I have an object and want to define an ACL for it. I create an ACL Entry and want to asign it to a group of users; not a role (GrantedAuthoritySid), not one user (PrincipalSid), but a group of users. I have researched everywhere for an example but was unable to find any. Can you please point me to an example or the class that would help me in this scenario?
So now I want to create a second object that is related to the first object (it should apply for the same users).
This could be a status update for the first object for example. My GrantedAuthority or Principal has a different mask of permisions for the second object.
Also the first object has 2 GrantedAuthorities (2 ACLEntries), and the status update has just one. If I use ACL inheritance the permision sets for the first object do not match the permision set for the second.
My question is how can I model this so that the GrantedAuthorities for the two objects are automatically kept consistent while retaining different permision masks. One idea is to use a composite pattern to link the GrantedAuthority of the second object on the GrantedAuthority of the first object (instead of linking it to users).
An ACL has a owner. What is the owner for? What role does it play for the ACL or for the ACL entries?
It's kind of complicated. I reverse engineered the Spring source code to understand the principle and it took me a lot of time. I can't exactly tell you how I implemented it (because it's very specific for the project I work on) but will try to give you a starting point.
What I did was:
Implement a custom org.springframework.security.acls.sid.Sid. This Sid references not an authority or user but a kind of groupobject which has an id and references two different objects. To use this groupobject as an Sid you have to create an ACL_Sid-record with the id of the object as ACL_sid.sid. ACL_sid.principal has to be an integer other than 0 or 1 which has to be checked for in a test in the custom LookupStrategy (see below and the Spring sourcecode).
Extend org.springframework.security.acls.sid.SidRetrievalStrategyImpl to retrieve the custom Sid's from the database.
Implement a custom org.springframework.security.acls.jdbc.LookupStrategy. I copied an existing implementation (because the class was final) and modified it for my needs.
Wired everything together in the spring configuration because the default Spring ACL config needs to no which classes it had to use (and not the defaults)
Look at the Spring source code and see how it's done.
To assign an object to a group of users, there should be an ACL entry for each user for the same object. This may lead to a considerably large amount of ACL records.
I'd like to know if it's possible with grails to specify a scope for the domain classes.
Few words to explain how my application is working at the moment:
- database access is done through an external "module" using SQLJ. This module is user by controllers in my grails app.
- a user ask for specific information submitting forms -> request submitted to the external module -> information extracted from the database -> information loaded into grails mem DB (HSQL) -> information displayed in views.
It works fine in development environment as i'm the only one using the application. But i'm wondering how the application would behave with two or more users. I mean, do the information loaded into grails memory database will be shared between users or not? And how not to shared information requested by one user with the others?
Thanks in advance for any help about this subject.
Regards.
All data in the database is shared across all users of the grails application. You would have to write a custom query to limit the data returned to a specific user. Based on your application maybe something similar to the following.
class DomainClass1 {
//fields you get from SQLJ go here
int userId
}
To get data into an instance of your domain class.
def domInstance=new DomainClass1()
domInstance.loadFromSQLJ() //call the SQLJ module and put it's data in the domain class
domInstance.userId=5 //assign the user associated with this info
domInstance.save()
Then when you want to display info for the user with the userId 5
def domInstance2=DomainClass1.findByUserId(5)
//Do stuff with domInstance2
It will be shared between all users.
But it depends on you, as for any other database, there must be some criteria (db column) by which you can choose only information related to current user.
In our project, we overrode domain classes' get(), list() that take into account domain aggregate root (a User or whatever), and also check all the named queries.
This leaves off all the other means of accessing instances, like findBy*(), criteria, findWhere() (though you can also override the dynamic methods), or HQL, but anyway reduces the amount of security review by 80%.
Suddenly it turned out to be OK to use DomainClass.list() in scaffolding.
Just wondering if there is a plugin out there that abstracts the process of deriving the instance of a current resource (or its class) from the current controller name?
Currently I just classify.constantize the controller name, and if that works then I test for the id paramater and load the record if it exists.
Yea, maybe it's a bit weird, but just wondered if someone's been there before and done it properly.
The reason it exists is because I need to know these objects to perform authentication on a granular level but I have about 35 different object classes so it needs to be abstract. I suppose I could assign #item to be the current item in each controller and rely on that but it seems a but unDRY.
inherited_resources :)
ResourceController by James Golick. It's out default in Blank, a starter application.