I have a user control that only displays customer information on each .aspx page in my application. That user controls contains public properties for customer information those are set from .aspx page (say page1.aspx) OnLoad event and displays information in that user control. Now from this page1.aspx, redirects to page2.aspx but couldn't able to display information in page2.aspx usercontrol (the values are lost after postback). I could maintain user control's properties state by using session in each proprty of control and can access in all the pages, but sessions would be expensive ways to do that. Please give me another better solution about this, so that i can maintain user controls properties value across postbacks.
Thanks in advance...
The information is not lost in PostBack as the Page2.aspx gets a seperate GET request after doing a redirection from Page1.aspx
There are below ways by which you can do state management
Session State
Application state
View State
Cookies
Query string
HTML Web storage
Session state is what seems to be the logical choice for your scenario, As application state would affect the data for all the users who are logged in. Viewstate will be lost once we do a Redirection. For cookies there would be problems with size limit and you need to clear the data stored in cookies. Also, you should be encrypting the data stored there. Query strings are easy to be tampered & is not reliable. HTML Web storage is available only in latest browsers and hence browser compatibility would be a problem.
One other possible answer - you could use CrossPagePostback. This allows Page2 to automatically detect data passed from Page1. You'd have to do this on the page's load event.
A redirect will always take you to another page, and this will always lose any state attached to the first page. The only way you can maintain state like this is by not using a web application!
It's never really a good idea to keep the user information in a session and as little as possible in a cookie. Neither are secure and as you can see have some state baggage that seldom justifies it's use.
I recommend going back to the drawing board and designing a solution that keeps the information in a database obviously on the server; even if the record is purged at the end of the transaction. Watch that table and you'll be surprised how many sessions are dropped and never reach the "official" end of the transaction.
Related
I have built an ASP.Net MVC site using Forms Authentication for a client.
Recently, they have requested that an authenticated user be restricted to a single browser session. That is, if the user raises a new browser instance, or opens a new tab on the original browser window, that he/she be logged out of the original. They insist on the added security.
Does anyone know how I might approach this? Thanks in advance.
Personally, I would push back and ask exactly what security this is bringing. Maintaining state like this counter to web architecture and is only going to bring you and your users grief.
Here is what I would do if presented with this problem:
Store the username of the user in your database (i.e. LoggedOn table).
When a user logs on, check to see if their username is already present in the LoggedOn table.
If the user isn't already logged on, insert a row into the table with the username and the current time; otherwise present the user with a message informing them that they can only log into the system from one device at a time.
Include logic to expire and delete the rows in the table if a user's session expires or if the user logs out.
First a disclaimer: I'm no expert in web programming.
Perhaps you might try a system where every user interaction requires the submission of a random value that's been generated for that page (much like what's used for CSRF protection.) That key could be kept under the user's session information on the server, and if a page is ever requested without the correct key as a URL parameter, the session is invalidated. The URL from one browser won't work in another, either, since once a URL is gone to, the user's session key has changed. The only way for a user to transfer a session between tabs would be to copy the URL of an unclicked link and paste it in a new tab's address bar. Switching browsers would be even more complex assuming that ASP.Net uses a session cookie: the user would have to transfer the cookie from one browser to another. Going back would also fail, as all the links on the previous page, and the URL for the page, would carry an incorrect session key.
Also, for reference, I believe the US Gov't TreasuryDirect site works in the way you've described, though I've never looked at how they manage it.
Thanks, people for the suggestions. Each had strong merits, however I had to take a hybrid approach. I found an incredibly simple suggestion from this post.
I implemented table of active users as Karl suggested as well. This will give the client the ability of deactivating the user on demand.
Thanks again.
Think of it as one active view at a time instead of one browser or tab. Or convince the customer to view it this way.
You can always issue a unique cookie for the browser session (ASP.NET Session) and allow communication to the latest cookie issued effectively making only one session active at a time, and therefore rendering other open sessions (browsers, tabs, etc) useless with the app by disallowing them communication any longer or serving up an error page for them. To do so you have to recognize who the user is and authenticate them against your app. This is half the puzzle and will force the user down to use your app in only a single browser at a time on their machine.
The other part of the problem is to pare down the windows and tabs that are part of the same browsing session of that browser, to allow only one view to be active at a time. To do so you can issue a unique sequential ID to the viewstate of each page for postback to the server to uniquely identify that page apart from other pages sharing the same session state (whether that page be in a browser tab, a frame or new window, etc). Or a code of your choice that's traceable. You then know which page is posting back within the session and can disallow others or deactivate previous ones by, again, shutdown down communication in some manner or serving up an error page, etc.
A new browser instance or a new tab may or may not be part of the same browsing session depending on how the browser is configured. I believe, for example, IE provides a setting that allows the behaviour to be set of whether a tab opens in a new process or session or shares the session. You won't necessarily get expected consistency across browsers to rely on for this feature, therefore you need to take programming steps to reign it in, like those described above.
You can additional steps like disallowing the user to be connected from a different IP# at the same time.
I am working on a small web application right now and part of the requirements is to allow the user to pick how their session will be managed: with either cookies or HttpSessionState. I have researched how to use cookies (http://www.codeproject.com/Articles/31914/Beginner-s-Guide-To-ASP-NET-Cookies) and Sessions (http://msdn.microsoft.com/en-us/library/ms178581(v=vs.100).aspx). I will be using non-persistent cookies.
The application will collect some data about the user (name, age, school) and take this session data and display messages on another page depending on the data that the user entered.
The thing I am having problems with is how to deal with how the user will pick the management. That information is also part of the session! The selection will be checked on every page on the web application.
I have researched globals (http://www.dotnetperls.com/global-variables-aspnet) but that is not a good method because it can be shared among different users which is not what I want! Correct me if I am wrong. How can I store this data temporarily through the session without actually using a session or a cookie?
Is it even possible to do this with cookies and sessions being mutually exclusive?
At the end of the day, you should save it somewhere. This option if it is not persistent, as it may be asked/changed by every time user visits the web site, the easiest way is to save it in a hidden html field. As user submits the forms, the value will be passed to the next page if you are using html forms. Or you can retrieve the value and send it manually in asp.net (e.g. Transfer).
You may use ViewState (not recommended) as well. If the information should be persister for future, try using User Profiles in ASP.net and save it as a custom field in database. This one is really cumbersome.
I have a several site collections in the same web application and I need to handle events when user goes from one site collection to another. I need it for specific actions, like setting "lcid" cookie for changing default language of site and claims values to user properties mapping.
Currently I'm using custom HTTP module, which handles all PostAuthorize web application requests and checks current user and site collection, holds last visited site for each user in collection and fires a custom event for subscribers, when detects transition between site collections.
But I think this approach slows down performance of web application. And from logs I see that there are to many PostAuthorize requests even when user simply clicks a link to page in other site collection. Also, in similar cases sometimes there is a series of requests to "next" site collection, then to "previous", and then again to "next". Also there are some issues with SharePoint Designer (can't edit page) become when this module is active.
Could you give me a advice with better approaches for this task? Thanks in advance.
1 way is using a hidden control and cookie.
Keep a hidden control in all the masterpage of all the targeted sitecollections.
This control will check the current site collection url and save it in a cookie. Possibly in the same cookie where you are storing lcid.
From next load onwards it will try and match the url in the cookie and the current site collection url. If different call the code you want to execute and update the url in the cookie.
This will be much lighter on performance than an httpmodule.
i am writing a login page in asp.net c# not using login control.
i can create account and log in without problems as a user.
the pages that require login has a separate master page.
and i want to check if the user is logged in in masterpage page_preinit function
but the problem is that child page event functions are called before masterpage's so i could experience a problem like session expire in child page before i get to check it in master page. is there anyway around this?
ok found the event im looking for. second one on the list
http://msdn.microsoft.com/en-us/library/dct97kc3.aspx
Are you using FormsAuthentication? You shouldn't need to worry about this. Authentication happens in the IIS pipeline before the Request is handed off to your Page object, and if the user's authentication fails, it will never get there, being redirected to the login page instead.
None of your PreInit code should be called by an unauthenticated user if the page is protected by FormsAuthentication.
This is one of many reasons why rolling-your-own authentication is a risky approach. There are lots of corner cases.
Since you're storing the user ID in the Session object, then once the session expires, you can't access it any more; it doesn't matter if it's from the child page or the Master page.
Instead of using Session, it would be better to use cookies. You could have a long life on the cookie itself, with the login expiration time encoded in the value of the cookie or kept in the database, keyed by the value of the cookie. That way, the session could expire, but you would still be able to refresh it or take some other action, rather than just reporting an error.
I am using ASP.net for developing an intranet website. I need to hold the userid across all postbacks for all the pages in the website. Is it advisable to hold those information in Session or somether way is available.
FormsAuthentication is also capable of holding a custom userid, and solves a lot of things for you like setting the cookie, login page redirection etc.
You can set the userid using the RedirectFromLoginPage method and then use the FormsAuthentication_OnAuthenticate event to find and set the Page.User property, to access all the other logic you need.
If using Forms Authentication, then the username will be available as:
Page.User.Identity.Username
If you need to hold another piece of information alongisde this, then use Session.
PS. I recommend using a class to wrap your session variables for strong-typedness and potential default values.
The most common ways of doing this are using either the ASP.NET Session Object or using cookies.
Either way will work well, but if you wish for their user information to persist even after the session has timed out (such as the closing of a browser window), then you would want to look into cookies. Session information will be disposed upon closing of a browser, or the activity timeout has been reached.