I would like to be able to share some data between an asp.net mvc application and a python/django application . The type of data I would like to share are authentification or session data.
This is of course possible as long as you access some shared resources between both frameworks. There are likely several ways of doing it but one of the most obvious would be using some shared backing store ie. database or maybe even memcached which would be faster. I'm not a Django user but as far as I know memcached is supported in it...
There is of course a more complex scenario related to this and that is data compatibility. You will likely have to use some interchangable format that both frameworks understand ie. XML, JSON, BSON or similar. So even when using memcached you will have to do this translation.
How I would share session...
Make the Session Cookie sub-domain agnostic
<httpCookies domain=".mydomain.tld" />
Have my two sub-domains that I want to share session between
www.mydomain.tld [ASP.net MVC app]
extra.mydomain.tld [Python app]
Create a simple web service or generic handler in ASP.net that returns the user's session serialized in JSON or XML.
If you use generic handler remember to use the IReadOnlySessionState or IRequiresSessionState interfaces on the class.
Now from extra.mydomain.tld you can call your www.mydomain.tld/[Get/Set]SessionValue handler or service. It will pick up on your ".mydomain.tld" cookie and allow sharing modifying values.
I would recommend the following approach using a shared database (could be a shared cache or any other datastore):
When a user accesses one of your applications at your domain, you create a cookie with the key "_shared_session" and with the value of a random string generated by your application;
Save the value of this cookie into the database and relate it to a JSON object holding the data you want to share between applications;
When the user accesses the other application, you verify if the cookie with the key "_shared_session" exists and read its value;
With the value of the cookie, you can retrieve the shared JSON object.
Quick answer: there should be a filter that look for a shared cookie before creating a new session
There is an option for storing Session state in MS SQL Server database which is available out of the box. Use the steps from the next kb http://support.microsoft.com/kb/317604
It's more about configuration, not implementation.
You can write your own custom storage provider but is there any reason for that?
I'm not familiar with python, but there are at least ODBC drivers for it
http://wiki.python.org/moin/SQL%20Server
Related
Now I'm reading a book and in the book it says:
"Both Session State and Application state are used for storing a small amount of insecure global information that does not change frequently"
Based on that I have five questions:
In MVC4 we can access session by HttpContext.Session, what's the difference
between this and HttpContext.Current.Session?
What's application status used for?
What's the practical difference between Session and Application state?
For which user info we cannot store in session but only store in server database?
Many many browser side cookies have been disabled, does that mean cookie are no longer in use when developing web application?
I hope this is not only helpful to me but also will help others who see this
Any suggestion are welcomed!
There is no difference. Use HttpContext.Current.Session when you are not on a view.
For storing application-wide information that applies to all users. There is only one at a time and the values are the same for all users.
Sessions are at a user level. Application is system-wide. If you need to keep information specific to a user, use session. If the value will be the same for all users, use Application.
Not sure what you mean
They both point to the same object.
ApplicationState if for sharing data between different Session objects which are tied to a concrete user session
I stated the main difference under the previous point. To elaborate: objects stored in Session are only accesible to requests that are run under that session (they have session cookie or identification string in url). Objects stored in Application, on the other hand, are available everywhere (for instance in global.asax) and are not dependent on current user.
It depends on your paranoia level. I would not store credit card information or social security number or passwords in an unencrypted format in Session. On the other hand I would not store them unencrypted on the database as well. SessionState can, by the way, be configured to reside in database and thus be shared between different machines.
ASP.NET functions better with cookies. There are ways of making it work without cookies, but it will involve a lot of work.
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.
The new class MemoryCache in .Net 4.0 appears to act just like asp.net caching. My questions are:
Is MemoryCache equivalent to storing an object/value in for a user in Session Cache, but not in the code behind of an aspx page.
Can a value stored in MemoryCache, which exists on the server, be accessable to a web page event?
Is MemoryCache equivalent to storing an object/value in for a user in Session Cache
No, it is not equivalent. The ASP.NET Session object is per user key/value storage, whereas MemoryCache is an application level key/value storage (values are shared among all users).
Can a value stored in MemoryCache, which exists on the server, be
accessable to a web page event?
In ASP.NET MVC there are usually no web page events but you can access values stored in MemoryCache everywhere within the application.
Basically, in an ASP.NET application, the new MemoryCache object is just a wrapper for the old HttpContext.Cache object (it stores values in the old Cache object).
User session state is relevant to web world while the newer MemoryCache is a new implementation which now generalizes the availability of caching across other types of applications as well e.g. console application, winform applications etc. MemoryCache is stored w.r.t. the application domain in which its instance was created and is application to all the users accessing the application. Quoting from this MSDN link:
The main differences between the Cache and MemoryCache classes are
that the MemoryCache class has been changed to make it usable by .NET
Framework applications that are not ASP.NET applications. For example,
the MemoryCache class has no dependencies on the System.Web assembly.
Another difference is that you can create multiple instances of the
MemoryCache class for use in the same application and in the same
AppDomain instance.
MemoryCache class is present in a separate assembly System.Runtime.Caching.dll altogether which can be referenced
Note: The MemoryCacheclass and System.Web.Caching.Cache class are different implementations lying in different dlls with no interdependency. It is just that conceptually their behaviors look very similar as anyways they are cache at the end of the day.
I would suggest reading this, this and this thread for even better understanding and some great thoughts on this topic.
To answer your question:
To store anything which is application wide but light-weight - Use Application State.
To store anything which is application wide but resource intensive - Use Web Cache
To store anything which is user specific (usually light weight stuff as heavy weight stuff will not scale with growing users of your website) - Use Session state
As long as you are doing website development, the older web cache should be able to fulfill all your use-cases. There can be very specialized use cases in a weebsite where you would require the newer MemoryCachebut I can't think of any at the moment.
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)
I notice in the azure examples they are using:
<sessionState mode="Custom" customProvider="TableStorageSessionStateProvider">
Can someone explain what this is used for with MVC3? I'm very confused about session state. Do I really need to use it if my application does not have anything like a shopping cart? Is it needed if I just want to do simple authentication? I removed the code from my web.config and my authentication still seems to work.
If you're publishing your application to Azure and you're using Session in any way (this includes MVC's TempData) then you will probably need to use some kind of central storage for session, rather than using the default "InProc" provider which just stores the user's session in the application's own memory. With azure, you can use, among others, SQL Azure or the AppFabric Cache (still in CTP).
Here is a good lab for AppFabric:
http://msdn.microsoft.com/en-us/gg457897
And here's one for SQL Azure (not supported): http://blogs.msdn.com/b/sqlazure/archive/2010/08/04/10046103.aspx
This is because you could have mutiple instances running or you instance could be moved at any given moment.
It sounds like your application doesn't currently use Session State so you won't need to worry about it. (although, remember that the TempData dictionary uses Session under the hood)