I have been exploring on spring-session framework for session management in our application, and we want to store session in database. I understand that spring provides implementation with JDBC and we can configure our own DataSource. The problem I'm facing is that we don't have direct access to db and need to make web service call to do any sort of crud operations.
So, is there a way to integrate spring-session to consume web services for session related crud operations in db ?
Another question is, can we change the schema for session related tables. I know that we can change the table names, but is it possible to add or remove further columns in the given tables ?
You can employ your custom session repository fairly easy - use #EnableSpringHttpSession (which imports SpringHttpSessionConfiguration) to configure common Spring Session components and register your SessionRepository implementation #Bean.
Regarding more advanced customization of schema used by JdbcOperationsSessionRepository, this was considered during implementation of JDBC support however decision was made not to provide this initially. If you need this feature please consider creating an feature request in Spring Session issue tracker.
Related
We are starting a new ASP.NET Core web site and the customer would like to handle the authorization using the database. So they want to configure custom roles and the actions to be configured in the database.
I have been trying to find an example or something to help me implement this, but could not find. Can this be achieved using the Authorize attribute from framework or a custom filter needs to be implemented?
EDIT:
I should probably mention that the application is an intranet so Windows Authentication is used for authentication
Short answer Yes.
Long answer...
This can all be achieved from the database you can configure up using existing methods with Identity, and from there create all the custom roles and even policies that you want to have and be able to assign, to each user individually or via roles.. Authorize attribute will work just fine with cookies. My only recommendation is that you try not handle security yourself but let the framework handle this for you.
I'm currently designing a new website built on MVC and I wonder what is the right way to manage state.
The state should contain the userId and some structs of the user info, and should be kept during the whole session of the user while he's logged in (across http requests)
The important criteria:
1) Support scalability
2) Performance
The easy way is to use the Session object, but it doesn't support scalability. If different requests during the session go through different IIS servers, the session won't be kept. Although I've heard of load balancing tools which route all requests of a single session through the same machine, I'm not sure that it's a good practice to rely on it (isn't it?)
Another option that I've read about, is keeping the state data in special state servers which are running a RAM DB (like Cassandra for Linux or Redis for Windows). But it seems to me an overkill at this stage of the development.
Do you have any other suggestions?
I would like to start with something simple at the moment, but keep the design ready for a more advanced solution at the future.
Any best practice or code/design suggestions will be appreciated.
Thanks,
Edi.
(1) Use Sql Server to Store Session State
(2) Use Memcached as a Session State Provider
(3) Cook up your own solution using Caching on an external caching provider: look into using something like the ServiceStack Caching Framework. Using this, you can use Redis, Memcached, Azure or AWS to handle caching.
Next, create a KeyFactory to handle generation of keys for specific items. The item keys would include the UserId (which you would always have from FormsAuthentication UserId (assuming that you are using FormsAuthentication). Then store any Session data for the user in the cache. Using this approach you are using Caching in place of Session, and the cache can be shared across multiple servers.
Note: you can have different approaches regarding clearing out the user's data whenever they begin a new session. Potential approaches include:
Include the user's session start dateTime in the cacheKey, and auto-expire entries when they are no longer fresh
Clear out all potential entries for a user when they begin a new session
If you are using .NET 4.5 and dependent on the type and amount of information you are keeping on users you may want to look at using claims to store information about the user. In .NET 4.5 all Principals inherit from ClaimsPrincipal. ClaimsPrincipal already uses claims to store the user name, roles and other information. You can create your own service to transform claims, which will allow you to add additional information to the Principal user.
I am using Spring security for Authentication and Authorization in my application. I am using Neo4j database as backend and implemented userDetailsService for authentication.
However, whenever my application restarts, user is forced to login once again.
To overcome this, i am thinking to store session information in redis database and load the data to Spring security Context whenever application gets started.
Kindly pass on if there are any articles and pointers to implement the same.
I am thinking of following implementation for it,
1) For every successful authentication, store user details and session details in redis.
This must be implemented in loadUserByUsername() method of UserDetailsService implementation
2) Remove the data from redis, whenver user logs out, Where can i do this information? Is there any spring security function where i can call this
3) Load all the data from redis to spring security whenever application restarts, again where do i need to write this logic?
Please let me know if i have missed any information.
All you need to do is to implement a
SecurityContextRepository that handles security context storage to reds
Eventually a custom filter that retrieves/ stores session information (GenericFilterBean)
I think it is possible to just give the standard filter a different repository, but I am not sure, I needed my own implementation anyway...
Store session in a redis is out-of the box functionality now
http://docs.spring.io/spring-session/docs/current/reference/html5/guides/httpsession.html
You need to configure remember-me feature of Spring Security.
Remember-me or persistent-login authentication refers to web sites being able to remember the identity of a principal between sessions. This is typically accomplished by sending a cookie to the browser, with the cookie being detected during future sessions and causing automated login to take place. Spring Security provides the necessary hooks for these operations to take place, and has two concrete remember-me implementations. One uses hashing to preserve the security of cookie-based tokens and the other uses a database or other persistent storage mechanism to store the generated tokens.
More information available in Spring Security documentation:
http://static.springsource.org/spring-security/site/docs/3.1.x/reference/remember-me.html
You can use out of box implementations or inject your own (aforementioned redis).
As Luke Taylor said, Tomcat's default action is serialize/deserialize sessions on container restart.
Here
pathname attribute of standard manager is the name of the serialization file. If you dont specify a path name attirbute the default is SESSIONS.SER
If you dont want to have sesssions back when restarted, you need to specify it as empty string value..
In a multi-tenant (seperate database per client) model is possible or even desireable to use either the Microsoft MembershipProvider or the SimpleMembership providers?
the original membership provider is configured from the web.config and the Simplemembershipprovider (in MVC4 template) has a method which initialises the database per application start rather than per session or request.
Is it the case that the membership/simplemembership providers are therefore tied into the application or inprinciple is it a sensible fit to change the database connection to point to the requesting clients database per request?
It's possible with my custom membership provider:
http://blog.gauffin.org/2011/09/a-more-structured-membershipprovider/
Create your custom IAccountRepository on top of the one in the SqlServer package. A lot easier than implementing your own provider.
I've seen and implemented something very similar to that, based on code from ASP.NET: Supporting Dynamic Applications.
This is not the same as what you are asking - the goal here it to use the same membership database, but with a different Application Name for each client.
I am not sure how you can set the connection string dynamically though - SqlMembershipProvider does not expose that property. You might start with Initialize, but as you've said, it doesn't run on each request. There is also the option of creating your own provider, and creating an internal SqlMembershipProvider per request.
We established that we needed to use dependancy injection to add custommembership providers per tenant request. Through thorough investigation it was apparent that we couldnt modify the connection for the membership provider and ensure it hadnt been remodified by another request prior to completion of the request. Due to its singleton design.
Cheers
Tim
Greetings,
Windows Azure only supports SQL Azure Session State for multiple instances.
I'm thinking what whether storing the objects in session will boost any performance for given scenario below:
Scenario:
I've got MVC Application where it's header and footer are populated from DB. I've created ApplicationController which inherits from controller. This applicationcontroller in turn will be inherited by actual controllers such as Home/Account etc.
I'm thinking of loading all these footer/header value in to session and use the session object for any subsequent requests.
Does anyone know whether this will boost any performance? Only reason I'm asking is that SQL Azure Session would do the same thing i.e. query SQL Azure Session storage for each request?
Thanks.
I would say that right now the amount of performance improvement you get from one option over the other is pretty negligible. The only way to know for sure would be to create some test scenarios.
Having said that, App Fabric Caching is coming out of CTP in less than a month and includes a session provider. If you were willing to use it you'd have two options:
Use the App Fabric Caching session provider and the session technique you've described above and it should be faster than either of the SQL options
Use the cache directly to provide the header and footer information (you'll still need to keep the data in SQL, but you can populate the cache on demand when headers and footers are requested)