I have a .net site that runs in an iFrame. In order to track various things on the page I use a cookie. I'm using a p3p header to ensure IE can read the cookie.
However it doesn't always seem to work. If I follow the steps below I can recreate an issue.
Delete all cookies from IE
Browse to iFrame containing my pages
Cookie is read OK.
Close browser
Navigate back to iFrame
Cookie not read
Refresh the page (F5)
Cookie is read OK
Repeat from step 4. ad infinitum...
Is this a caching issue in the parent page or the iFramed page?
If it is a caching issue how can I ensure IE doesn't cache this specific page and instead reloads the page along with the cookie?
Needless to say this doesn't happen in Chrome or Firefox.
Any light that could be shed on this will be much appreciated.
S.
This is a caching issue with the iFrame. The way to get around it is to add a unique query string parameter to the url in the iFrame.
Something like this will work:
<iframe src="http://www.MyAspNetApplication.com?q=<% =DateTime.Now.Ticks %>"></iframe>
Where q is the unique query string param.
Related
I have a website that I created for the company I work at. This site is on a subdomain and is brought in as an iframe within another company's retail site, as we offer services under them. Is there a good way to track this with google analytics? I've never tracked a subdomain before, let alone in an iframe.
I've created a test analytics account, and added the top level domain, but I only put the tracking code on the pages for the subdomain that I created the site on. Will this even give me any information? and if that part of it works, is the information from an iframe setup accurate? I know from a design standpoint an iframe is kind of off in it's own world within a world, but does anyone have any experience on how google sees a site like that?
I've searched the forums and anywhere else i could think of, and they have bits of info on subdomains, practically nothing on iframes, and nothing combining the two. I have no access to adding any tracking code to the partner company's retail site either.
If your iframe hosted content is not on the same domain as the parent page (which I'm going to assume is not, based on the context of your question), then google will report the page name as the URL of the iframe, not the parent page.
GA code has a way to override the default page name, however, you cannot retrieve the parent URL in this case, because this is considered cross-site scripting (XSS).
The only way to get info about the parent page in this case is for whoever has control over the parent page that has the iframe tag, to pass the parent URL to the iframe by adding a query string parameter to the iframe src="..." attribute (also, same thing for any other info you want to pass to the iframe page). Then you can write some javascript to retrieve those values from the URL and pop whatever you want, including overriding the default reported page name (which you would do by setting the optional 2nd param to your _trackPageview call).
If the iframe content IS on the same domain (even if it is a subdomain of the parent page), then you can access the parent page properties using parent.window.whatever instead window.whatever.
Well, from what I understand, you have a page that will be inserted inside an iframe to a second page, but we need to know if the page that will host the iframe is the same domain as the calling page:
If the page called by the iframe in the same domain of the calling page:
In this case, you can insert the block of JavaScript Google Analytics, as both the iframe on the main page, and we have the measurement data from the main site, the iframe.
If the page that calls the iframe belongs to a different domain:
Some of the features that are measured are in frames within the site. These iframes indicate the domain, for example, site.com.br. Whenever a page in one domain has a frame to a different domain prevents the browser cookies that are stored inside the Iframe, which in the case would prevent the measurement.
Cookies are nothing more than small text files that are stored by your browser on the machine. Most of our cookies are session cookies that are automatically deleted from your hard disk in the closing of the window. Persistent cookies also are used by websites to facilitate identification of your computer in the next visit you make to the site. Inactivation of the cookies can be made in your browser however, this will preclude all the functions available on the site.
To allow the recording of cookies should add P3P headers in HTTP server that serves pages. This header causes no change in display mode or operation of the pages. Just instruct your browser to allow to record cookies of third, however, it has a bigger role in Internet Explorer. If you do not set, you can receive data from other browsers (Google Chrome, Firefox, Opera, etc. ..), but Internet Explorer still has a widespread use of the mass of the population.
Imagine that we have four distinct domains:
www.site1.com
www.site2.com
www.site3.com
www.site4.com
These four pages will receive the iframe tag:
<iframe Src="http://www.meusite.com.br/anuncio.php">
The anuncio.php page need to have a call header p3p for accept the third party cookies.
To add the header p3p use the code below (should be added to all pages that belong to the same domain)
ASP.Net
HttpContext.Current.Response.AddHeader ("p3p", "CP = \" "PSA CONE NOI ONL OUR BUS \" "")
PHP
header ('P3P: CP = "NOI PSA CONE ONL OUR BUS"');
JSP
response.setHeader ("P3P", "CP =" NOI PSA CONE ONL OUR BUS '")
ColdFusion
<cfheader name="P3P" value="CP='PSA CONo OUR ONL NOI BUS'" />
I hope to have helped:)
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.
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.
I have a web application that I use Login Control and ASP.net membership for Sign in process.
my application work propebly untill last week I upload new version, in this version I didnt change the login UC and just the main page ( default page after user logged in ) changed.
but some users report me they cant login and redirect to Login page.
some note:
1- this problem occure just in IE browser
2- users that report this problem can login to old version
I add a log procedure and see users redirected becuase of this code
if (!this.User.Identity.IsAuthenticated)
{
Response.Redirect("~/Secure/Signin.aspx");
}
I checked and see this.User.Identity.Name was empty or null.
What setting maybe changed?
Thanks
I've seen a similar thing happen when there was a malformed FORM tag was rendered inside my ASP.Net Server FORM tag. By 'malformed' I mean that it was missing the required METHOD attribute.
It is my understanding that the HTML spec doesn't support nested FORM tags, so different browsers handle them differently. In my case, I saw a similar issue as you describe, with no issues in Firefox, and major issues in IE.
Check to ensure there are no Nested FORM tags on your page. Also check all FORM tags to ensure they have all required attributes.
Doubt this will solve the problem, it's kind of tangental. But, rather than hand coding the redirect url it's poosible to use
FormsAuthentication.RedirectToLoginPage()
which has the benefit of taking care of the returnUrl and stuff. It'd require the login Url set in the web.config.
This is a follow up to my previous question: Problem passing parameters via Iframe in IE. Which was never solved.
Here's the core of it:
I'm trying to execute an HTTP GET from
my website to another website that is
brought in via iframe.
On Firefox, you can see in the source
that the correct url is in the iframe
src along with it's correct
parameters-- and it works.
On IE, you can see in the source that
the correct url is in the iframe src
along with it's correct parameters--
and it doesn't work...
Is there something about IE that
doesn't let you pass parameters
through an iframe in the querystring?
I've tried refreshing the iframe in
IE, I've tried refreshing my page &
the iframe in IE, and I've tried
copying the url and re-pasting it into
the iframe src (forcing it to refresh
as if I just entered it into the
address bar for that iframe window).
Still no luck!
Anyone know why this is happening, or
have any suggestions to try to get
around this?
As for the code, all it's doing is creating
the src from the backend code on page
load and setting the src attribute
from the back end...
//Backend code to set src
mainIframe.Attributes["src"] = srcWeJustCreated;
//Front end iframe code
<iframe id="mainIframe" runat="server" />
I've made a temporary account for you to login and see exactly what I mean. That way you can use firebug or any of your other debugging techniques to figure out why this isn't working rather than having me try to explain what's going on.
EDIT: Changed the account credentials. Please use this one instead
Username: matt
Password: globalbuying
Please follow this link to get to the login page. One you login with the above credentials it will take you to the main backend page. Click the image on the left that says "Vacations", that will take to you a page with the iframe and will execute the Http Get from there.
If you need more details on what's going on in the behind code, etc., let me know and I'll post them.
Thanks,
Matt
After working my way through the HTTP requests with Fiddler2, comparing different browsers, I found that IE makes the request just fine, but fails to set any cookies in the iframe.
I also noticed that if I open that framed page by itself it does work. Even more so, after logging out again there, the iframed version works too. That's because it then already has a session cookie and the iframe no longer needs to set it.
It turns out that this is a known security restriction: IE blocks cookies in iframes. But this can be overcome with the use of the Platform for Privacy Preferences (P3P).
Here are a few links that should help you fix the problem. Starting off with another (answered) question on StackOverflow:
Cookie blocked/not saved in IFRAME in Internet Explorer
Privacy in Internet Explorer 6
IE Blocking iFrame Cookies
The example page you provided is working for me in IE8. The iframe is not as tall as in chrome, but it does have the correct page in it.
As an aside, please note that passing logon credentials via the query string is extremely unsecure and open to various exploits.
It seems that the ampersands in the iframe's URL are HTML-encoded (&).
I think that might cause IE to choke on identifying the param names. Does the problem still occur if you use plain ampersands in the URL?
If the encoding on the src attribute is happening implicitly, you might want to consider using a Literal control for testing purposes and set its Text property to the entire iframe tag to avoid any unwanted encoding.