I have a pretty common Spring Web MVC application using Hibernate. The user of the application are stored in a table called USER and there also username, password and a couple of other properties are stored. Also I am using Spring security with jdbc-user-service in order to secure the application so that only user from this table can access is with their username / password.
Now my problem is that once logged on, I need to access this user object quite often, e.g. in order to get all orders from this user, the address of this user and so on. I know how to access the Principal object, which shares username with my User Object, but I am wondering which would be the best strategy to easily access my custom User object. There are a couple of strategies like putting it in the session, write a findUserByUsername() method and call it whenever needed (which would result in hitting the database quite a lot I think) but I am looking for a smarter way. Is it somehow possible to inject a User object? Or should I rather put it in the session? If so, how would be the best way to achieve this? How could I hook in after the Spring frameworks login event?
Any suggestions?
Thanks
Paul
You could always scope a UserDetails bean to the session (link). This would, of course, be a stateful bean, so you would be free to store any information about your User entity that you need to and access it as long as the session is active. One trip to the database.
Note: The User object (and any related objects) will be detached from the Hibernate Session. Keep this in mind when either 'storing' the values within the bean or accessing them in later processing.
Related
We are using WSFederationAuthenticationModule in an ASP.NET MVC 5 application to authenticate users via Windows Azure ACS. We have tried multiple things to save some user specific data in the session after the authentication has succeeded but everytime we write to the session object we got the exception 'Session state is not available in this context'. Our favorite was the event System.IdentityModel.Services.FederatedAuthentication.WSFederationAuthenticationModule.SignedIn but of course at this time the session does not exist. Where is the recommended place to write initial data of an currently authenticated user into the session?
Have you considered using the ClaimsAuthenticationManager for this? The beauty of this is that you can access the current claims for the authenticated user (before your application code is executed), run whatever query you need to run, and then stuff new claims into the claimset of the principal. I've used this technique before for similar situations as you described.
If you really need to get access to the session data, then I think you want to look at the SessionSecurityTokenHandler class.
Experts,
what's the recommended way to pass the user id (system internal id of the user used to query for the user info) between controllers in a codeigniter app?
I'm considering the following options:
1. Use the CI session id to query the database for the user id in every controller. That way I don't have to place the user id in the session which is a security concern. But this option means an extra db query in every controller
2. Store the user id directly in the session so I have it readily available to query for user info.
What do you think?
From my understanding of MVC you're not normally supposed to talk directly between two controllers. However in this case I would use the session. As far as security goes there are plenty of extensions to codeigniter dealing with authentication such as TankAuth and WolfAuth including many others that you might look into if that is your concern. In this case however I'd say using the session to store a user id is perfectly fine as long as you're not storing sensitive data along with it.
You can read up on CodeIgniter sessions here: http://ellislab.com/codeigniter/user_guide/libraries/sessions.html
There is a great authentication library Ion Auth. Check it out
http://benedmunds.com/ion_auth/
I'm using Spring Security which works great to make sure that a user has a certain role before accessing a resource. But now I need to verify something a little different:
`/product/edit/{productId}`
What is the best way to verify that the logged in user "owns" productId? My business mappings handle the relationship (a user has a list of products). I need to verify this product belongs to the user and hence, they can edit it.
I know how to gain access to productId and the logged in user in both the controller and an interceptor. I don't believe this logic belongs in the controller at all. The interceptor seems better but I wondered if Spring Security had an "accepted" way of handling this situation.
Yes, in Spring you can implement this by implementing Access Control Lists. ACL declaration specifies permissions for individual objects per user. Once you have everything setup like acl entries in your database and logic, you can use SpEL and #PostFilter annotation to control the list of objects returned to a user.
Spring Security Documentation
Related:
Here's the issue at hand: I have developed an ASP.NET MVC3 application using Razor. I have also implemented a custom membership provider and overridden the ValidateUser() method. Within, I query my db and get a lot of user information in addition to the password auth.
At the moment, I am pushing this information, i.e. companyId, to static properties of a class. This works and I can display/use this information throughout my app. The problem arises when a user closes their browser tab. Upon re-opening the app, the user is authenticated via a cookie, so they don't need to re-login; however, those static variables are blown away.
So guys and girls, how would/do you conquer this issue? Should I append the extra info to the session cookie? Or perhaps a better solution?
Use the ProfileProvider in ASP.NET.
For application level variables, they are going to be subject to application pool recycles and similar "simulated" restarts related to users starting all over. These variables should be completely independent of user usage and should be able to be recreated easily. If you have variables that are user dependent or that can't be restored easily without some sort of outside intervention then you will definitely need a different method of storage.
If the data is user specific, storing it in the session cookie is probably the best idea. If the data is user-related but branches multiple users it should be stored in a database or a flat file somewhere. If the data has nothing to do with users specifically then it should just be in a database or configuration file.
I am using a Security scheme that is based on session attributes. I know that Spring has Acegi Security but I don't have much time to study that module. I just want to share this to solicit comments.
The pseudocode is like this.
On successful Login, I am setting an attribute on user session. The object that I am placing as session attribute is a simple javabean with a map of privileges.
public class UserInfo{
public String getRole(){};
public Map checkPrivilege(){};
//getters and setters
}
The session attributes contains the Role also of the user. (He could be a User/Guest/Admin/Super Admin). Now there are certain privileges that are authorized to User.
For my JSP, I just check out the user session for his role and privilege.
My rough code is like this using JSTL
IF (User Info in Session is 'User' and has this privilege)
Add Button is shown
Else
No Add Button is shown.
I have these questions:
Are session attributes considered secure that no one else can sniff or hack?
Are security based on these scheme considered secure-enough?
Session attributes are stored on the server side only, so yes they are secure.
There is no problem with putting these security identifiers into session attributes in terms of security. But that is the easy part of web application security! The hard part is the rest of the security infrastructure, which I am concerned that you have not thought about yet.
I recommend you investigate Spring Security.