We have a web application that's built on top of Play framework 1. The current version of Play is 1.2.7. It's running on top on Ubuntu 12.04 in an Amazon EC2 instance.
Recently we experienced a peculiar and very worrying behaviour on our test server. There were only a few people using the system: a few developers and a few testers. What happened was that the session cookie of one user was given to two other users. Suppose you have users A, B and C using the system, each logged in as themselves. Suddenly what happens is that all of them seem to be logged in as user A, without any of them doing anything special.
Play is managing its own session cookie. Suppose the session cookie name is configured as XYZ_SESSION. When we saw this behaviour, I was able to inspect the session cookies of users A and B (C was in a different organization and site). The session cookie that B had was 100% same as A had. In this application, the session cookie is used to store user name, email address etc. So in practice, user B was suddenly having the same session as user A. I didn't inspect the cookie of user C, but the verbal report was that he suddenly was logged in as user A.
This was actually a second time this behaviour was observed with this application. The previous time was several months ago, and then a cludgy hack was developed to notice the situation and logout the user in question. However, the hack is not very maintainable or scalable, and we want to get rid of it. And preferably find the root cause for the issue.
The authentication logic of the application is implemented using OpenID4Java. However, when this behaviour occurred, all users were already logged in.
We have a theory on the possible cause of this behaviour. In the application, we have a BaseController class that inherits Play's Controller class and that is used as the base class of all controllers. In the BaseController there is some code that gets and puts to the session container. In the code of that class, the session is referred to as just "session", which means the static field in Play's Controller class. The assumption is that Play's enhancer will enhance the reference to use a ThreadLocal field in Scope.Session class. The enhancing would be done by Play's ControllersEnhancer class. However, when inspecting the code of method enhanceThisClass in ControllersEnhancer, it makes use of CtClass/getDeclaredMethods. In the comments for that method it says "The inherited methods are not included." I don't fully understand how enhanceThisClass gets called, so I'm not entirely sure how solid the theory is.
So, our suspicion is that in practice Play skips enhancing the code in this BaseController class, and the static session field in Play's Controller class gets used as plain as it is, and this combined with suitable scheduling of threads will cause the session duplication!
The problem is quite difficult to reproduce and thus we haven't this far conclusively verified that this is the cause for the behaviour we observed.
Anybody have any insights? Have seen similar behaviour with Play? Able to prove the theory right or wrong?
on my work we use play 1.2.7 in a lot of applications. Last month we see the same issue with Play. Two users with the same session. In our case the app is separated in two modules (catalog and checkout), the catalog was using 1.2.7 and the checkout's module 1.2.4. Because the difference between the modules Play! create the same session in each module and given this session to the users. I don't know if your app has the same structure as our, but if yes, i recommend you see this.
Related
im new to Node and React. Now i am playing with react and redux. It is awesome! But at least there is one question. Is the redux store user specifc or get every user the same obejct with the same values?
Edit:
In my scenario different User work with the App on the same time. Do they always have the same state. Is the state syncron between different users.
Or get every user an specifc state in redux.
Thanks!
React runs in the client-side as JavaScript, so by default each tab where your application is running has got its own state that has no guarantee to be the same.
To synchronize your state between your tabs of the same browsers, cookies can be used. To synchronize your state between your different users, they have to communicate with each others so some implementation has to be done on the client side, for example with sessions or websockets.
But keep in mind that there is no easy sync switch! State synchronization requires a lot of implementation and even if there might be some libraries that help with that, synchronizing the state between several instances of a React app requires possibly a lot of skills and code.
It's hard to go further in answering with the little amount of explanation you gave without speculating, but you got the gist.
Because React is served from the client (browser), the state of a react app belongs to the instance of the application itself.
So if you have 2 tabs open, each tab has its own instance of the application and therefore have their own state.
No matter if you are logged in as the same user within the app or different users, it's the application which has its state (unlike a session, which you would usually find on a backend)
The same applies to redux, the state belongs to the instance of the application.
I hope this provides some clarity
I am quite sure that I am not the first person on the planet trying to implement the following, but I am sure that I am not able to find a good guide how to do it.
Our node backend is setup quite like a MVC to say so.
View = Express Server offering our api
Controller = Library, a set of controller functions to manage our data
Model = Our mysql database, it's Javascript DAO respectively (since our usecase is quite unique we need to write own DAO's and can not go let's say for js-data.
The challenge we face now, is:
As a developer, I want to keep our library clean from overhead for developers.
On the other side, as a database administrator I clearly want to know who did what modification and so on
Until now I tried to keep the 'user' object out of the library, since I do not want all controller functions to look like
function ctrl(param1, param2, param..., user)
Going for this would mean, we have to pass around User objects all the time, which would make it a pain to code inside the libraries.
On the other hand, I can not find any other approach in node/express to somehow get knowledge about the user without passing it (since we do not really have sessions, at least not yet in our code).
TL:DR; I do want to action log all database modifications, but do not want to pass around a User object all the time.
Is there any known approach for that challenge which does scale and is 'best practice'?
Thanks in advance
I developing a stateless REST API that makes use of token based authentication, where I'm manually adding an Authentication object to the security context by calling SecurityContextHolder.getContext().setAuthentication(authentication) from within a custom security filter. I've been experiencing problems with the context not being set correctly which I believe is due to this :
Storing the SecurityContext between requests
In an application which receives concurrent requests in a single session, the same SecurityContext instance will be shared between threads. Even though a ThreadLocal is being used, it is the same instance that is retrieved from the HttpSession for each thread. This has implications if you wish to temporarily change the context under which a thread is running. If you just use SecurityContextHolder.getContext(), and call setAuthentication(anAuthentication) on the returned context object, then the Authentication object will change in all concurrent threads which share the same SecurityContext instance. ...
You can customize the behaviour of SecurityContextPersistenceFilter to create a completely new SecurityContext for each request, preventing changes in one thread from affecting another.
So the question is - how do you change the behaviour of the SecurityContextPersistenceFilter?
I'd like the security context to not be associated with the http session, but don't want to set the session creation policy to stateless, because I still want to implement CSRF protection etc.
I had this exact question this afternoon, and this open question matched my search exactly, so I thought I would add the little I learned.
We had threads that were accessing the same SecurityContext. I was unable to figure out how to customize the behavior of the SecurityContextPersistenceFilter directly (and in the pattern of the framework), however there were two ways that I could get it to be thread safe.
The first solution was to ensure that an empty context was created in our main authentication filter. This covered all of our authenticated requests, so it would work for our solution.
SecurityContextHolder.createEmptyContext();
The second thing that worked for me was to change our WebSecurityConfig to be stateless, which I know doesn't work for the OP, but added here for completeness.
http.authorizeRequests()
.anyRequest().authenticated()
.and()
.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
...
Both these solutions work independently for our particular configuration. I'm certain there is a 3rd solution that would read better, but I don't know what it is but would like to.
This is my first time posting. I welcome any feedback.
I want to implement logging in for users, and regard them as "logged in" during their surfing (using sessions). I do it on Google App Engine with webapp2 framework. But the platform is not important, I'm sure you will point out the general rules to do it.
I have written the class Authorization with authorize method, and every handler inherits from this class. When some handler is triggered I first run self.authorize() and it checks whether the user has the session variable holding his login. Then I check the internal datastore to find out whether the user's session is expired (so I don't depend only on the info from the client's side).
How can I improve or simplify this approach? Do I have to do the authorization routine from every handler or I can keep it in one place?
Also the way webapp2 implements sessions look strange to me. I have to make a class with dispatch and session methods that do some magic. And if a handler inherits from this class I can use sessions inside it:self.sessions['login'] = 'Joe'; self.sessions.get('login').
I have a custom ASP.NET Membership Provider that I am trying to add password history functionality to. User's passwords expire after X days. Then they have to change their password to one that has not been used in their past X changes.
I already had the User entity, which has a password attribute for their current password. This maps to the User table in the db. Since I needed a list of previous passwords I created a UserPassword table to store this information with a FK reference to the UserId.
Since passwords are value objects, and have no meaning outside of the user, they belong inside the User aggregate, with the User as the root. But here in lies my dilemma. When I retrieve a User from the repository do I always have to get all of their previously used passwords? 99% of the time I don't care about their old passwords, so retrieving them each time I need a User entity seems like a dumb thing to do for db performance. I can't use lazy loading because the User entity is disconnected from the context.
I was thinking of creating a PasswordHistory entity but for the reason stated above, passwords aren't really entities.
How would you DDD experts out there handle this situation?
Thanks.
Edit 1: After considering this some more, I realized this is essentially a question about Lazy Loading. More specifically, how do you handle lazy-loading in a disconnected entity?
Edit 2: I am using LINQ to SQL. The entities are completely detached from the context using this from CodePlex.
It is hard to fully answer this question because you do not specify a platform, so I cannot be exactly sure what you even mean by "disconnected". With Hibernate "disconnected" means you have an object in a valid session but the database connection is not currently open. That is trivial, you simply reconnect and lazy load. The more complicated situation is where you have an object which is "detached" i.e no longer associated with an active session at all and in that case you cannot simply reconnect, you have to either get a new object or attach the one you have to an active session.
Either way, even in the more complicated scenarios, there is still not a whole lot to lazy loading strategies because the requirements are so inflexible: You have to be "connected" to load anything, lazy or otherwise. Period. I will assume "disconnected" means the same thing as detached. Your strategy comes down to two basic scenarios: is this a situation where you probably need to just reconnect/attach on the fly to lazy load, or is it a scenario where you want to make a decision to sometimes conditionally load additional objects before you disconnect in the first place?
Sometimes you may in fact need to code for both possibilities.
In your case you also have to be connected not only to lazy load the old passwords but to update the User object in the first place. Also since this is ASP.NET you might be using session per request, in which case your option is now basically down to only one - conditionally lazy load before your disconnect and that is about it.
The most common scenario would be a person logs in and the system determines they are required to change their password, and asks them to do so before proceeding. In that case you might as well just take care of it immediately after login and keep the User connected. But you are probably using session per request, so what you could do is in the first request process the time limit and if it is expired, you are still connected here so go ahead and return a fully loaded User (assuming you are using the historic passwords in some kind of client side script validation). Then on the submit trip you could reattach or just get a new User instance and update that.
Then there is always the possibility you also have to provide them with the option to change their password at any time. They are already logged in. Does not matter much here, you have a User but the request ended long ago and it does not have passwords loaded. Here, I would probably just write a service method where when they invoke a change password function the service gets a second copy of the User object with the full history for update purposes only, then updates the password, and then discards that object without ever even using it for session or authentication purposes. Or if you are using Session per request you have to do the equivalent - get a fully initialized object for client side validation purposes, then when the data is submitted you can either reattach either one you already have or just get yet a third instance to actually do the update.
If the password is needed after beginning an authenticated session, you could still do the same things and either replace the local User or update the local User's in memory password version as well.
If you have too much stuff going on with multiple levels of authentication most likely you are going to have to require them to logoff and do a full log back in after a password change anyway, so the state of the User does not matter much once they request a password change.
In any case if you are using session per request and your objects become fully detached after every request, in the first scenario you can still lazy load while you are on the server on the original request to return data for client side validation. In the second scenario you have to make another trip (there really is no such thing as lazy loading here). In both case though you have to weigh your two update options because you are always disconnected before an update. You can either just get a second instance from the database on the submit trip to update, or you can reattach the one you already have. It depends on what is optimal/easiest - does saving a db round trip for an uncommon event really matter? Does reattaching using your ORM of choice possibly hit the database again anyway? I would probably not bother to reattach and instead just get a new instance for the actual update as I needed it.