I am new to WCF and trying to accomplish a few things in terms of session management:
I would like to get an event on the server when a new session is opened/created.
I would like the ability to either close all open sessions, or get a list of open sessions and close specific ones (on the server, of course).
How would I go about doing this? Google has been surprisingly unhelpful...
The answer is going to be a lot of "it depends". Some of the bindings are not session aware. Something like BasicHttpBinding for example doesn't do sessions on its own, but if you enable ASP.net compatability mode you can get ASP.net's session management to work. You will then be able to use Session_Start and Session_End in global.asax to do what you want when sessions are opening or closing.
You should look at the binding you're using and see if it has some kind of session support built in, because some of them do.
If you're doing authentication, you could also imitate a session management system by mapping requests to authenticated users and storing the session record in the database.
I will say that in any case I'm not sure what "closing" a session is going to get you. Unless you're also locking the user out somehow, the next request will just immediately start a new session if the previous one was ended. Maybe if you explain what goal you want to accomplish (and why) we can be of further help.
I agree with Tridus's answer on this. You can use Session with WCF services by enabling ASP.NET Compatibility Mode.
Check http://msdn.microsoft.com/en-us/library/aa702542.aspx for an initial reading. Keep in mind - Services are supposed to be stateless by principle.
Related
I have an application that uses APS.NET as the middle tier. One of the features for administrators is to allow them to popup another browser window logged in as a non-admin user, so they can provide support.
I use a javascript function "openWindowWithPost." The application takes credentials from a DB and forces a login so the support staff does not need to know the user credentials. Unfortunately when it does that the original session is reused and hence all of their application variables are shared, causing havoc with the original Admin login.
What I would like the ability to do is to force a second browser window to popup and when it talks to IIS have it create a new session and keep the original one active. Is this possible? If so where can I find how to do this?
From your post, it looks like you are using the Session object in ASP.Net to store data.
By default the Session ID is stored by the browser in a cookie. See MSDN
for a description of how it works. You could setup your application to use query strings to store the session id, but that is really old fashion and can become messy and hard to deal with.
Your best bet is to find a solution at the browser level. For example, Firefox has an extension called Multifox that would do what you want. Other browsers have similar extensions.
I have two website consider it as website1 and website2.
In website2 there is a login page .When a user click on the login button it will call a HTTPhandler in website1 to authenticate user.On successful authentication user information will be stored in a Session variable from handler.
Then it will redirect to a page page1.aspx in website1.But the previously set session is not available in the page1.aspx .What will be the issue?
I checked the session id in first request(when calling handler in website 1 from webiste 2) and Second request( redirecting to the page1.aspx from the handler) the session id is different.
How can i retain the session data?
You need to store session data in another process shared to both web site.
You can do it intwo different ways:
Configure an SQL server
Configure SessionState service, a Windows service used to share informations.
In both cases you have to change both web.config files to support the new session mode.
I.e. to use SQL:
Prepare a database (from command prompt):
cd \Windows\Microsoft.NET\Framework\v4.0.30319
aspnet_regsql.exe -ssadd -E -S localhost\sqlexpress
Modify web config as following:
<sessionState mode="SQLServer"
sqlConnectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;Initial Catalog=Test" allowCustomSqlDatabase="true"/>
You don't need to change your code.
Correct me if I an wrong, AFAIK different domains cannot share a single session. One way to handle this is to carry the data to the other site through cookie [encrypt the values for security], then copy this cookie value to the session in the other site receiving it and destroy the cookie.
And if the sites are in different servers you need to handle the "sticky session" so that servers share the session.
This situation sounds kind of similar to one I have experienced and worked on before, where one web application acts as the login page while another is the actual app where all your work is done. I can describe what I did in the hope that you find it useful.
Like you I had one web app which had the login page (so in your example this would be website2). When the login form submitted I then redirect to a fake Login.aspx page in website1 - this is where we differ I think as I'm not sure of your specific reason for using a HttpHandler.
In my case the website2 Login.aspx page is actually just the way into the web application; it has no markup, just code-behind which will authenticate the user, perform setup (e.g. set session variables) and then redirect to another page such as Homepage.aspx. This particular scenario has worked for me, so maybe your problem revolves around the use of a HttpHandler though I would not be able to tell you why.
In order to retain the same session date across two different servers running ASP.NET web applications you must configure your session state to be managed out of process. This means the actual session state data variables will be stored outside of worker process and in another process that is able to make the session data available to other machines.
To achieve this you can configure your application to use SQL Server to store session state and make it available to multiple servers in your farm. The TechNet article Configure a SQL Server to Maintain Session State (IIS 7) provides details on hor this is done in IIS 7.
If you are using IIS 6 then the steps to configure are somewhat different and I can provide further details on this if needed.
In order for this to work you do need to ensure that both servers are running applications within the same domain, e.g. myapp.com, otherwise the ASP.Net session cookie will not be passed between the two servers. ASP.Net uses the cookie to lookup the session state stored in SQL Server and will therefore not find any matching session if the cookie is not passed on requests between the two servers.
i think IRequiresSessionState will not help because context is different.
once we had the same problem but that was passing asp session varibles to .net. How ever you can do it here also.
on both website create a page setsession.aspx
now if you are on page say web1/page5.aspx and want to go to web2/page3.aspx
you redirect to web1/setsession.aspx?togo1=web2/page3.aspx
in both setsession.aspx logic in to extract sessiondata and place them in querystring
so the web1/setsession will redirect to web2/setsession.aspx?sess1=value1&sess2=value2&togo=page3.aspx
web2/setsession.aspx will check for togo querystring and if found will extract all querystring name and value will set them in session and will then redirect to togo value.
you need to differentiate togo1 and togo carefully.
Session sharing between websites is going to require hand-coding. You could hack the asp.net framework to get this working, but I feel that this is not a clean way of achieving what you set out.
If user authentication is all you are doing from website, is it possible to use alternative? Single Sign On mechanisms will help you out here.
Something like SAMLSSO could help you in this case.
You have two websites which are hosted on different servers, it means you have two different processes running on separate machines, so sessions will be definitely different. Same session can't be shared across processes because by default asp.net support in-memory session.
Here you would need to think about storing sessions information which can be shared between two processes (i.e. out of process). Ideal way to store sessions information in databases. For this you can consider Stefano Altieri code sample above.
I don't think you really want to share session information between two websites at all. From what I can gather from comments, what you're really trying to do is have a user authenticate in one website (give you a username and password which are validated) and then have that "logged in" state transferred to another website which doesn't handle authentication for itself.
What you are describing is the Delegated Authentication model.
In this model, your application hands-off authentication to other systems which it trusts to provide information about users.
There are two well-known protocols which provide this mechanism:
OpenID
This is intended to facilitate users logging in with their own identity providers (Google, Facebook, Microsoft Account). It's a very good choice if you're running a public-facing website, as most users will already have an account they can log in with.
WS-Federation
This is intended to facilitate users logging in with identity providers which are managed by known trusted parties, such as partner organisations.
From version 4.5, the .NET Framework has built-in support for WS-Federation via the Windows Identity Foundation component (and is also available for earlier versions as a separate download). This automates the task of delegating your authentication to an Identity Provider.
It also provides components for you to write your own Identity Provider, should you want to create your own, but you shouldn't have to; you can find various existing implementations to perform this job for you.
The problem you're trying to solve is a very difficult one, especially trying to make it secure enough to be reliable. The good news is that smarter people than you or I have spent years working out very clever ways of doing this. You should use what they have done and not try to cobble together something out of Session state.
In the long-run it's best to let the smarter men do the hard work for you.
My asp.net session objects are storing in SQL server.I am storing an ID in session. If client open another browser and storing different ID in session. I need to notify client is “are you sure you want both ID’s open?” in same based user logged user.
Application runs on logged in user (not anonymous)
How can we check this in asp.net?
Session is not linked to an authenticated user, and there is no way of accessing an other connection's Session without knowing its SessionID.
Usually this kind of problem can be solved using cache instead of session state. With cache you can create your own user-based keys to store data. Depending on whether you are planning to just run your web app on one server or in a web farm environment, you can either use asp.net in-process cache or one of numerous distributed cache solutions (like memcached which I'm using in my web projects with great success).
There are a couple ways to go about this:
Option #1, in your user table, add a value called "session id"
When a user logs in, check to see what their last session id was. Then test to see if it's still a valid session. If it is, ask them what they want to do. Store the latest session id in that table after each log in.
However, I'd go with option #2: Don't do this. If the user wants to open multiple browser windows to access your application then let them. There's probably a pretty good reason for it. Most (as in nearly all) users have no idea what "session state" even means and they really have no desire to know. All they care about is getting their job done.
for a secure web application , How to clear an item in server Cache on Browser close.
You could try using the Session object and use it Session_End method to detect when the session is over and then do the cleanup.
More info about the session object you can find here - http://www.codeproject.com/KB/aspnet/ExploringSession.aspx
I'd use a small timeout so that the cache will clear almost immediately when the session is over. I might be wrong here - so if any one can help, it would be appreciated.
Good luck!
I have a website in C#/ASP.NET that is currently in development. When we are in production, I would like to do releases frequently over the course of the day, as we fix bugs and add features (like this: http://toni.org/2010/05/19/in-praise-of-continuous-deployment-the-wordpress-com-story/).
If you upload a new version of the site or even change a single file, it kicks out the users that are currently logged in and makes them start over any forms and such. Is there a secret to being able to do deployments without interfering with users for .NET sites?
If you make a change to a config file, the contents of a bin folder of the app, or things like that, the ASP.NET worker process restarts along with your application.
This results in deleted sessions and kicked-out users.
The solution is to use other session storage methods other than the default InProc.
You can achieve this by setting the session state mode. The SqlServer and StateServer options provide very good remedy for your issue.
SqlServer mode is relatively easy to set up and get up and running. (Basically, it's just creating a database, running aspnet_regsql, and then specifying it to the config.) If you don't have MS SQL Server or don't want to use it, you can use StateServer, or create your own provider and use the Custom mode.
The only restriction is that you can only store serializable values with SqlServer and StateServer mode.
The reason you're seeing this is because you are resetting the application pool, thus resetting everyone's session.
The cleanest route would be to offload your session to a session state server, or minimize your use of session.
One way around this is if you can't offload your session is to always deploy to a new virtual directory. Your public facing URL then just redirects to your latest version. All users that are already logged in would continue to use the older version, but any new users would use the new version.
There are two alternatives to achieve that:
Do not use Session at all. (You may use cookies for authentication)
Use another Session-state mode. State server or SQLServer. http://msdn.microsoft.com/en-us/library/ms178586(v=VS.80).aspx
Either way you will also gain the flexibility to be able to run your application on multiple servers for performance or fail safe clustering.
Depending on what you store in the Session object, you may be able to reconstruct it in Global.asax's Session_Start handler. I used to do this in an internal application where we only really stored the user's identity in the Session, so we could just use their authorization cookie to recreate the session.
One thing to keep in mind if you do this: say a user loads up a form and then leaves for lunch, and you update that page while they are away. If they return to their desk and submit the form they'll be submitting the old version of the form to the new code-behind.
I suppose users are kicked because web-server application process is restarted. By default user sessions are stored in memory and session data is killed. Session provider is configurable option in web.config. May be choosing external (out-of-web-application-process) session provider is a step toward what you are expecting.