The problem that I am having is as follows:
I currently have a custom class that generates buttons and places them on a placeholder on a master page.
The events for these buttons put specific values into session that differs values for a database query. In essence, the buttons serve as filters for charts.
After creating all the buttons, I realized that session values will stay constant from page to page, so everytime a user enters a different page while another is open, the filters selected on the open page will remain constant for the new page that is opened.
At first, I wanted to use viewstate rather than session, but then realized that a master page and a content page do not share the same viewstate.
At the current time, I am thinking of using a prefix for the sesson key that will identify what page the filters actually exist for. However, I am not wanting to overload session with numerous values if the user wishes to have many pages open at the same time.
Any solutions that would entail a way to share viewstate (or some other way to store values) between app_code, the master, and the content page?
Use HttpContext.Current.Items, it is a key-value pair collection with a lifetime of a single Http Request.
Have you considered Context.Items?
How many filters are we talking here? Store the filter values in the URL. Have you seen some of the URLs that google or an ecommerce site uses? They are quite long. Here is how I do it:
I store the filter values in the query like, www.chart.com?filter1=val1&filter2=val2 etc.
I user JQuery's query plugin to manipulate the query on the client side, and then request the chart from the server again, using the new query.
This way, I'm not junking up session, cookies, or anything like that, and if the user wants to store a bookmark to a particular chart or email it to a friend, they can and the filters are preserved.
I'm starting to think the answer shown in the following question will work:
ViewState object lost in Master Page Load
Exposing the desired variables via a property.
If the data isn't too long, cookies are a typical solution.
Another option is to use Silverlight isolated storage. The Silverlight control itself could be invisible (no UI).
Related
I have a Layout page which sets up the list of Projects in the application using Telerik's ComboBox as shown. The combobox allows user to select a project he/she wants to work on.
Once a selection is made, I want all subsequent actions in the application should correspond to the selected Project. I can preserve the Project information in a Session but then if user chooses to open this in a new tab and in 2nd tab users switches to a different Project and comes back to the first tab and refreshes the page then the session information (Project) would have changed which will create issues in my application.
So, what is the best way for me to persist Project information of the Layout.cshtml controls so that I can use it in my application such that every page that is rendered uses the currently/correctly selected values.
Tempdata / QueryStrings came to my mind but i don't know whether they will be reasonable solution to my problem. If yes, then how should I use them generically (specially querystrings) without complicating my solution?
localStroage and sessionStorage also seems like relevant solutions but then how do I use them in scenario where user opens a new tab from existing page? How will the Project # will persist on the newly opened page/window/tab?
something like this is achievable, if you make sure the url changes when a selection is made.
So let's say you select project C-1379 in your dropdown box, at that point your url could become http://localhost:58692/pid=C-1379.
from now onwards, your page can load the desired data, retrieving its required information from the query string. Do not use session or localstorage or anything like that as it won't work.
This way, you can still load your list of projects in your layout page, and you can select one based on the query string value and then load some default values via api calls to the back end.
If all your work from now on is done based on api calls, for example, you have some properties that you change and then you issue a POST to update said details then this is very easily done as well.
telerik controls usually have some events associated with them. the one you are using should have an onChange or something like that. This where where you would update the query string with the value of the project selected and then you can proceed to do what you need
I can preserve the Project information in a Session but then if user
chooses to open this in a new tab and in 2nd tab users switches to a
different Project and comes back to the first tab and refreshes the
page then the session information (Project) would have changed which
will create issues in my application.
I would have thought this is the desired behavior... take stackoverflow.com as an example, if I change my username in one browser-tab, I would expect my username to be updated in other browser-tabs as well... and that's what happens if I refresh my other tab.
There is no built in solution for maintaining user info in different browser tabs separately... the only way to achieve this, is by sending project name back and forth in the URL... but then you would loose this info if user changes the URL... In my opinion, this is an ad hoc solution and does not worth the effort of development, because it's a very uncommon scenario.
Getting to your options:
Storing user info is a very typical use case for session variable.
TempData is stored in Session by default. Though you can write
your own custom TempDataProvider and store it somewhere else (e.g.
database, cookie, etc). See Brok Allen's Cookie TempDataProvider
as an example. One advantage of using Cookie is that you send your
session variable back and forth with the request so you don't need to
worry about Sticky Sessions.
You can of course use a permanent storage, such as DB/Disk.
If the project name is not a sensitive info then I don't see any issue in passing it in Query String.
I have page where users can select from one or more images. When they are done I would like them to navigate to the next page and what is displayed would be based on the selection from the previous page.
"Selecting" just means that they click the image and it has a CSS class added to it. When they click the link to navigate to the next page I'd like to collect the images that have been selected and pass that information along using either TempData or Session.
In most of the examples I have seen either inputs or the query string is used to pass information from the View to the Controller. How can I pass which elements have a particular class to my controller when a link is clicked?
If you're using a link click, I'd probably just append the selected images to the query string. I'm assuming you don't mind exposing this query string to end users.
I'm sure that's probably not the answer you were looking for. But as you stated I think you're only to legitimate options are passing the values through the query string or using hidden inputs and posting the page to your action by intercepting the link click event.
You said you do not want to post back to servers. You cannot access TempData or Session without posting back to server, so they are out of scope.
You only have client side option, so you want to collect a user's selected items in array.
Once the user clicks to Next Page, you create a query string like this ?ids=1-2-3-4 and retrieve those value at next page.
Other thoughts: Long URL likes this is a bit ugly, and URL has maximum length limit depending on browser. If I'm you, I'll post back to server to collect the selected values. Then use TempData (or some persistent storage).
I'd like to stop IE8 from sharing my sessions in one of two ways (or both if possible):
Through configuring the browser to always do this (so I can force my users to configure their browsers in this way).
Through code in my web application.
Thanks.
Instead of storing data in the session directly, create a custom tab-level session upon demand and store everything there. When a new request for any page comes in, create a Dictionary<string, object> to use as the tab-level session and then store it in the session based on a unique key. Pass this unique key from page to page either in the viewstate or url.
However, you need to prevent users from opening links in a new tab (which will make them mad, so this really isn't a good thing to do anyways). To do that make sure all links are postbacks only.
I'm doing some brainstorming for a portal framework, and I'm envisioning a breadcrumb navigation stack that is tracked via the ViewState (so that if the user clicks "back" in their browser and clicks some other link, the breadcrumb trail will depart from the right page). My pages are really just ascx controls that get loaded into a placeholder control on the main portal page based on the URL. When the user clicks a portal link, there is a postback that loads the original page and invokes the given link's "clicked" handler, which should then "push" the current location onto the breadcrumb stack before sending the browser a redirect instruction to change the URL to that of the page that I want to go to.
That's as far as my brainstorming goes for the moment, because once we perform a redirect, we lose the ViewState. Rather than doing the redirect, I've thought of simply telling my main portal page to replace the current page control with the target page control, thus avoiding the extra http round-trip and allowing me to keep the ViewState. But then my entire website experience occurs in the context of a single URL, so I lose URL bookmarking among other things. And if I wrap some of my controls in AJAX panels, the entire site happens in one page request as far as the browser's history is concerned.
What I would like is some way to have the browsing history and URLs behave as if each link is leading them to a new page with a descriptive URL and all that, but still have some way to know the path that the user took to get to the page that they're on (ViewState seeming to be the simplest way to track this).
Could anyone suggest some techniques I might try using?
First suggestion... You may want to look into ASP.NET MVC. However, I have to admit to some ignorance here as I'm not sure that would really solve your problem. But it sounds like the sort of thing MVC would be suited for.
Second... it's possible to override the methods responsible for saving and loading ViewState. One of the things you can do, for instance, is push the ViewState into the Session rather than sending it down to the user and back up on postback. You could easily add some custom code here.
Third... I think you may want to rethink part of your design. The ViewState really serves one purpose: It recreates the state of the page as it existed when the page was rendered for the user. If you are moving to a different page, or a new set of controls, why would you need the ViewState at all? The ViewState itself is really just a hack to begin with... ASP.NET's way of maintaining state on top of a stateless system. (but that's a whole 'nother discussion) We have other methods of maintaining state... the primary mechanism being the Session object. Why not save your breaacrumb data there instead?
I would look at using cookies. For performance reasons, you really want to avoid HTTP redirects if you can, and ViewState only works if the user submits a form, not for regular links.
You might do something like maintain several path lists in cookies that show the path that the user took to go from one page to another. Maybe you set a unique ID with each page that is applied by some JavaScript as a query string when the user clicks on a link, and the server uses that ID and the past history from the cookies to determine how to render the bread crumb on the next page?
What are the different ways of communication between asp.net page and a popup page? Query strings etc. Which is most secure?
You say "communication between" the pop-up and the main ASP.NET page. First, I assume that the pop-up is an ASP.NET page as well so the communication from the main page to the pop-up is no different from the communication from one page to the next in a series of pages. That is, you can store and then use data in the session (if the data is available when the main page is loaded), via query strings, etc. Unless the data is sensitive, the simplest way by far is to include a variable in the call to the pop-up that is replaced by the appropriate arguments. Here is a sample image link:
<img style='cursor:hand;' alt="Open Note" onclick="javascript:window.open('NoteEdit.aspx?T=3&UID=<%#NoteUID%>', 'Note', 'HEIGHT=400,WIDTH=420');" src="images/Note.gif" />
Note the "NoteUID" replacement argument.
The more interesting question is how to pass information back to the window that popped up the pop up. To do that, start with this javascript:
<script type="text/javascript">
function OpenHRAResults()
{
opener.location.href="<%#DestName%>";
window.close();
}
</script>
This is taken from code where I re-open a specific page but, as you can guess, you can do all sorts of things with the "opener" window (the window that popped-up the pop up).
Hope this helps...
If you are talking about an actual pop-up page, where you are using window.open from javascript. You have the querystring and Javascript as your only real available options for passing information between.
As for "security" of this. The users will be able to see anything via a querystring, JavaScript can move values across, but they would be existing on the other page. But you could pass something like an excrypted value to make things more secure.
We try to avoid query strings where possible in sometimes they are just too convenient. In those cases we always encrypt the querystring. There are several ways to do this - example of one approach:
http://www.codeproject.com/kb/web-security/querystringencryptionnet.aspx
A few methods
Query strings (window.open('/users/123'..)
Javascript (window.opener)
HTTP POST (open a popup via javascript, set the form target to it's name as target and post)
Sessions or other server side methods
In answer to the security consideration I'd say that query strings in combination with server side security is the way to go. Open the popup passing the information via query strings, then validate that the logged in user has permissions to access that user. Some specific requirements would call for encrypting the querystring data.
For delete operations I'd probably use a postback to avoid problems like "my indexing spider deleted all users".
You don't need to sent the real data to the popup window. Just create a GUID on the opener page.
Create a class in asp.net which represent all the data you need to sent between the popup page and the opener page. For example popupdata
Store the serialized class in the Session with the GUID as the name Session[Guid] = class object
Session[Guid] = popupdata;
Open the popup with f.i. ~/popupwindow.aspx?PageID=Guid
Retrieve the session object with calling the Session[Guid] again (Guid is coming from the PageID querystring.
so on the popup page call popupdata data = (popupdata)Session[Guid];
And then do whatever yuo like withthe data.
If data is changed on the popupwindow you can store it in the Session variable again
and send it back to the opener...
Very secure since no data is sent to the client.