This is C#.Net code:
How to share Cookie between 2 HttpWebRequest calls?
Details:
I am posting a form in first request from abc.com to xyz.com, this form contains some setting variables which are used by the system. lets say there is a input field in the form which sets the size of grid pages to be displayed in other pages.
Once i have updated the setings in previous request, i go to send a request to another page which shows off asp.net gridview/grid. The grid might contaian several pages and the page size should be the one which i set in previous request. But when i do this via HttpWebReeust it does not happen.
When i do it via browser, loading the setting page in the browser and then going to the grid view page... i see the page size is updated.
I want to achieve this via code. Sicne i am scraping this grid. i have to set page size or visit the gird pages one by one via code.
Or is it possible to set a cookie on 2nd request which is used to set in first request? It will be great if i go this way. any solution? All posts go to xyz.com from abc.com.
Cookies are controlled by your browser. If you were to open the same page in two different browsers, you will not see the cookies set by one browser in another.
HTTPWebRequest does not use any browser, so I don't think it will set any cookie at all.
You would probably need to store the settings at server side, maybe use a session.
Related
I need to open my page in two different browser tabs and work on both of them simultaneously. I have maintained a session in my code which have all the data from the page. When I try to modify in one tab it gets reflected in second tab. How can I achieve two different sessions for the same page?
You can not do it the way you ask for. Each browser have their cookie to connect with the user.
What alternative you have. The point here is to connect the same user (no matter what browser use) to the same data.
You force the user to login (and there you have the same data base on user)
You use some variable on the url that must be the same on all browsers to have the same data. Eg, on first browser you have a url like http://www.test.com?s=123 and ask to from the user to copy paste either that url either the code on the second browser to been able to connect each other.
On each case session is not do the work, and you need some other database to connect the two data pages.
The tabs in a browser share the same set of cookies, which includes the session cookie - so the pages use the same session.
So you need to find some other way to distinguish those two tabs.
You could add a "tab" parameter to the url that you use on that page, with some tab-specific value. You need to maintain that value in the url when you redirect, you can't store it in Session or a cookie.
The processing must then be done in a tab-specific manner.
If it is just for testing, you could use "private tabs" - they don't leak their cookies into regular tabs. But you do not want to force regular users to use this.
i heard that , if your asp.net page is inside a iframe, and u want to get the parent url, you can achieve this by using the referrer?
i tested is okay, and found that the window parent url will included in the referrer when called the iframe content
Request.UrlReferrer.ToString();
Assume that i can only use server side to achieve
I just want to ask is that way safe?
Any chance to lost the referrer url in this case
The browser is not guaranteed to send the referer. It's all up to the browser/configuration/extensions/proxies and whatnot between the request and your server.
If the user navigates to a different page within the iframe, the referer will point to whatever the user came from.
All in all, never use the referer for any logic that may fail if it's not there or if it has an unexpected value.
You can do this but it is not entirely in ASP.Net.
You would have to get the referrer from Javascript and pass that to the iFrame.
One of the 2 following calls would be what you are looking for.
top.document.referrer
or
parent.document.referrer
Is there a way to set pages to expire in ASP Classic so that the user can't hit back and re-do anything?
Is this a good practice?
If you force the page to 'expire', it would have the opposite effect you want: It would actually force the browser to make the request again (because it's been told the data it has expired)
I suspect you might be barking up the wrong tree here, though. Are the pages that "do stuff" using the Query String values as the parameters to take those actions? In other words, is the page that links to the 'action' page doing so via a regular anchor tag with query string parameters in the URL, or via a form using the GET method?
If so, you should change the form submitting that action to a POST form. Doing that will not only result in a prompt in the browser if the person uses the Back or Refresh buttons to try to reload that page, but also helps protect you against Cross-Site Request Forgery attacks. (more info on XSRF here)
What is the problem that you are trying to solve? If the back button is forcing something to be updated on the server, then you are better off making sure that you don't allow pages to be in the browser history that can cause problems.
After a POST, I often do a Response.Redirect so that the POST is not in the browser history. This helps avoid these types of issues.
In my asp.net 2005 app, I would like conceal the app structure from the user. Currently, the end user can learn intimate details of my web app as they navigate and watch the url change. I don't want the end user to know about my application structure. I would like the browser url to not change if possible. Please advise.
thanks
E.A.
URL rewriting is the only one that can provide any kind of real concealment.
Just moving the requests to AJAX or to frames, means anyone (well, more advanced users) can still see those requests being fired, just not in the address bar.
Simplest solution is to use frames - a single frame that holds your application and is 100% * 100%. The URL will not change though the underlying URL can still be seen via "View Frame info", however only advanced users will even figure that out.
In your pages, make sure that they are contained inside the holding frame.
A couple of possibilities.
1) use AJAX to power everything. This will mean that the user never leaves the home page
2) use postbacks to power everything. In this, you'd have all those pages be user controls which you progrmattically hide or show.
3) URL rewriting (especially if this is asp.net 3.0 or later)
My site uses url parameters to dynamically load ascx files into a single main aspx. So if I get 'page_id=123' on the query string, I load the corresponding ascx. The url changes, but only the query string - the domain part remains the same.
If you want the url to remain precisely the same at all times, then frames (per Oded) or ajax (per Stephen) are probably the only ways to do it.
Short answer: use URL encryption
A simple & straight article: http://devcity.net/PrintArticle.aspx?ArticleID=47
and another article: https://web.archive.org/web/20210610035204/http://aspnet.4guysfromrolla.com/articles/083105-1.aspx
HTH
A site has 100's of pages, following a certain sitemap. A user can navigate to page2.aspx from page1.aspx. But if the user goes to page2.aspx directly say through a book marked URL, the user should be redirected to page1.aspx.
Edit: I dont want to go in and add code to every page that needs to fulfill this need.
Note: This is not a cross-page postback scenario.
You might consider something that is based off WorkFlow, such as this: http://blogs.msdn.com/mwinkle/archive/2007/06/07/introducing-the-pageflow-sample.aspx
The WCSF team also included a pageflow application block that you can use as a standalone add-on to your application.
I guess you could check the referrer, and if there isn't one / or it isn't page1.aspx then you could redirect back to page1.aspx.
As another answerer mentioned, you could use the Referrer header, but that can be faked by the client.
Since you don't want to modify each page, you could do something with an IHttpModule. Assuming you have some way of describing the valid page navigations, you could do something like this in the BeginRequest handler:
Check the session for a list of valid pages (using a default list for first visit if none are in the session).
If this request is for an invalid page, redirect to the place the user should be.
Based on this request, set up the list of valid pages and redirect page in the session so it's ready for the next request.
I recently worked with real code that checked to see if referrer was blank and used that as a step in authorization. The idea was users wouldn't be able to fake a referrer, you don't need a custom browser to fake a referrer. Users can book mark your page to delicious, then delicious.com is the referrer (and not blank).
I've had real arguments about how sophisticated a user needs to be to do certain hacks-- i.e. if users don't know how to set the referrer, then you can trust it. While true, it's unlikely your users will write a custom browser, but there already are Firefox addons to set headers, referrers etc and they're easy to use.
Josh has the best answer-- on page2 you should check the page hit log and see if the user has recently visted page1
I like alot of the answers above (specifically the workflow).
Another option, is creating each page as a usercontrol and having page1.aspx control what usercontrol gets loaded. This has the advantage of storing your workflow in a single place instead of on each page.
However, I don't think there's a magic bullet out there. It sounds like this security problem is an afterthought, or possibly reported as a bug, and you have been tasked with fixing it quickly and efficiently.
I would start weighing the answers here with their associated cost in hours.. I suspect the quickest solution will be to check referrer addresses on each page. Although hackable, it is obscure and if that risk is acceptable to you it may be the appropriate solution.