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.
Related
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 have a web page and a modal dialog page. On clicking the save button in the show modal dialog. closes the window and returns a value. Now when the
control reaches the JavaScript function of the parent window . I wnt to perform some database operation on the basis of this returned ID.
I am using the following approach to utilize this returned value.
Keeping it in the hidden field and populating the returned value in hidden control.
keeping a hidden button in the parent window, performing the click event when control comes back to JavaScript function of the parent page. Thus in the server side button handler get the value from hidden field and perform database operation on the basis of returned value.
Is this approach fine. Or I can get rid of hidden field
That's not terribly bad provided the ID returned is not sensitive information that someone can use to modify a record that doesn't belong to him. One can perfectly manipulate this ID on the client side for any other ID and have your logic update a different record from what you intended.
If all you are doing is calling a server side method passing this ID; why don't you do the whole update from the pop-window itself (at that point you already know the ID)?
If the parent window (page) is meant to be updated; you can just perform a normal refresh of the page (ie. use window.location to redirect the user to the same page so he can see the update or use Response.Redirect to the same page.)
What you're probably looking for is called AJAX. With AJAX you can communicate with your web server from within your JavaScript code directly. No HTML form posts are required then. You might want to look at frameworks like JQuery. These have easy implementations (cross browser wrappers) to send HTTP requests via AJAX.
Note: I just noticed, you are using ASP.NET. Take a look at ASP.Net AJAX Page Methods.
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).
I am trying to come up with a way to measure how long a user has been on a page in my ASP.NET application. I am storing the userid, pagename, pageenteredtime and pagelefttime in a database. Each record has its own unique id as well, called featureuselogid.
At the moment, I can track when a user comes into the page with the page_load function on the server side. I store the userid, pagename and pageenteredtime.
After that im stuck, and need some guidance in the right direction. I need to record the time the user leaves the page. I know in javascript there is a window.onbeforeunload function, which will cover most cases (browser shutdown, links etc).
But how do I pass the featureuselogid to the javascript? If i can do that, I think I can make a webservice call from the javascript and update the record with the pagelefttime.
Am I going down the wrong path?
Cheers in advance.
You will have to run Javascript timer on the client that periodically calls the server. Once the call does not get logged at the expected time, it means that the user has left. Woopra does this, and it works reliably. For instance, sometimes people have a page loaded in a browser in the background for days, and there is no other way of detecting that they are still connected.
Users on laptops pulling the network cable, moving out of the coverage of a Wifi zone, etc etc there are too many scenarios where the onbeforeunload event will not reach a server anymore.
Just put the featureuselogid in a hidden field in the page, with a unique ID that will make it accessible to Javascript, or set a javascript variable.
Having said that, I believe that you are going to be able to most reliably detect Page_Load. You can determine the time between pages by measuring the time between Page_Load events. You won't get the browser closure, but IMO knowing when the user closes the browser is not all that meaningful.
When you render the page in ASP.net, include a javascript tag that assigns a variable to the value of a server side script:
<script language="javascript">
var JS_featureuselogid = <%= featureuselogid %>;
</script>
Later in your javascript code, you can reference the JS_featureuselogid variable and get the value that was injected into it during page construction.
I want to redirect the user to another page to fill out a captcha but i would like to keep the post data, and if the captcha pass to send it 'back' and complete the previous page action.
When/if the user succeeds i like to add an captchaPass=true and would like access the post data and continue processing. Right now i am using redirects but ATM i am not required to use it.
Is it possible to carry the post data? keep in mind i may the user access multiple pages so separating data and not having a mixup is necessary.
One idea is to get and save all posted data [1] on the captcha page, and then recreate a middle white page with this form data and automatically make a new post to the previous page.
Can this work with out any issues with hash checks and security ?
Is there a better idea with out this white redirect page ?
[1] One other issue here, how to send this posted data with the redirect ? and not change the url - or make it too big to accept it. Keep in mine that a server transfer may not good idea because is complicate the thinks on captach post back.
Update 1
The basic idea here is how some one capture the full post back of a page, show a different one page and then send the post back data to the original first one.
The reason is to stop a bad user, or an attacker bot program that try to bring down the pages/server by making many post back from different pages in short time. All that happens with out javascript, and most attackers use custom made programs that just make post of data to all page together try to bring down the system.
For example, if a page have a search box, is very easy for most of the the site to bring them down by start making hundred of random search with wildcard (called and Dos Attacks using SQL wildcards) and make the sql server and the computer spend his time and cpu to search and search thinks. So to prevent an attack like this you need to recognize multiple post backs from the same computer, and then the next step is to redirect him to a captcha page to block him out in case that is a computer program.
Other example, many page have email submit, very easy you can submit hundred times the email of his and full his mail box in no time with hundred of emails, or on a store to place all items on the cart again and again and full the database with stuff like that.
So ajax and javascript is not working in this case, and we need a way to redirect him after the post back to a page that can check if is a real user or an attacker and stop him - but if is a real user must return back to his normal action.
Update 2
This all must be done in a general way, eg on BasePage, or on Global.asax or somewhere that is independed from the content of any page. Because we try to prevent a DoS attack, or multiple submit anywhere on any random place of any random page.
Yes I know how you can place a captcha on the contact page, but this is not what this question was first asked for - this questions asked how can carry post data to one different page, keep them there and then resend them back to the original one.
The obvious solution is to read all post back, and save them on the form, and then read them back and make on fly a form only with that data and make the post back. Here I am asking if there are any other better than this solution.
Other Applications
There is also the case that a user is inside a page that request authentication, but the authentication ticket has expired, and the user make post back. In this case we need to keep somewhere all the posted back data, to proceed with the login page, and resend them back to the first page that request the authentication.
Sure, just write the form data out to the captcha page in hidden elements with the additional captcha fields added to the form. Have your submit action post the whole thing back to the original. Using ASP.NET it's probably easier to have the captcha written to the same page with the form fields hidden, but you can do cross-page postbacks as I've described above.
Cross Page Posting might help you.
Why not implement the CAPTCHA with AJAX? Load the captcha object and form with Javascript in a div perhaps displayed lightbox style, accept the user input and post it to your server for validation, hence continue with the users post request or keep them there until they get it right (or cancel).
A more specific situation example:
Give the form submittal button an onClientClick value of some Javascript function. This function decides if this particular form needs a CAPTCHA. If it does it loads an interface for taking the CAPTCHA (which you'd need to do with some server-side code) and inserts the CAPTCHA's input element to the form that the user clicked to submit.
Once the user has entered the CAPTCHA input and clicks some button whose click event is bound to return to your first JS function, the Javascript intercepts this action and posts the full form, all the data from the original form and the CAPTCHA for validation. Your server script can now process all this at once!
This is the best solution I can think of that works similar to how you've asked, but I can't imagine why you want to perform the CAPTCHA on a different page.
Server.Transfer with MultiViews, Panels like control is fine with you? In this way, no need to bother about the Data Maintenance and Postbacks. You can do the validations in javascript.
You can keep both functionality in the same page to avoid moving data from one page to another page/Bring the data back to original page. You can utilize Session for this intermediate operation. Set it back to associated controls across Postback. You can create a class, Instantiate it and Initialize the control values in this class object. Save class object in Session. On Postback, You can reassign the values to the associated controls. This will definitely keep the things simple and without much complexity.
Doubts ?