I have a feature that is hosted on a different domain from the primary one
in a frame, and need to retain values in a cookie.
example: A web page at one.com contains a frame which has a page hosted at
two.com
If I view the frameset from one.com in Firefox, all works well with the
content from two.com. But if trying to view this using IE (with standard
security settings), the cookie set by two.com is not accessible.
Have been tinkering with the domain setting in the setcookie function to
specify the domain: have tried one.com and two.com, but have not been able
to get at the cookie value.
How can I get this to work?
17  4127 
>I have a feature that is hosted on a different domain from the primary one in a frame, and need to retain values in a cookie.
example: A web page at one.com contains a frame which has a page hosted at
two.com
If I view the frameset from one.com in Firefox, all works well with the
content from two.com. But if trying to view this using IE (with standard
security settings), the cookie set by two.com is not accessible.
Have been tinkering with the domain setting in the setcookie function to
specify the domain: have tried one.com and two.com, but have not been able
to get at the cookie value.
How can I get this to work?
Hopefully you can't on any browser. Cookies from one domain aren't
supposed to be sent to another. For many, many, uses of cookies,
it's a BIG security hole (you're handing credentials to log into one
web site to another web site, which makes session hijacking easy).
Gordon L. Burditt
Yes, but it does actually work on any browser I have seen aside from IE
(including Netscape, Firefox Win, Firefox Linux, Safari Mac).
The page in the frame does have a domain associated with it, shouldn't the
cookie be available to that domain? (But not necessarily to the domain of
the hosting frame)
"Gordon Burditt" <go***********@burditt.org> wrote in message
news:12*************@corp.supernews.com... I have a feature that is hosted on a different domain from the primary
one
in a frame, and need to retain values in a cookie.
example: A web page at one.com contains a frame which has a page hosted at
two.com
If I view the frameset from one.com in Firefox, all works well with the
content from two.com. But if trying to view this using IE (with standard
security settings), the cookie set by two.com is not accessible.
Have been tinkering with the domain setting in the setcookie function to
specify the domain: have tried one.com and two.com, but have not been able
to get at the cookie value.
How can I get this to work?
Hopefully you can't on any browser. Cookies from one domain aren't
supposed to be sent to another. For many, many, uses of cookies,
it's a BIG security hole (you're handing credentials to log into one
web site to another web site, which makes session hijacking easy).
Gordon L. Burditt
"Bruno" <20***@TimesOnThe.Net> wrote in message
news:D0*****************@news20.bellglobal.com... Yes, but it does actually work on any browser I have seen aside from IE
(including Netscape, Firefox Win, Firefox Linux, Safari Mac).
The page in the frame does have a domain associated with it, shouldn't the
cookie be available to that domain? (But not necessarily to the domain of
the hosting frame)
Relying on an obvious security flaw for functionality is not exactly
planning on the future :)
Having a frame in a page be able to read cookies from the domain in which
the frame is situated is a nasty thing. Someone could inject a frame into a
site's HTML somehow, and have that frame bring up a page on a second server,
and that'll give the second server access to the cookies of the first
server, on that page. Nasty stuff.
"Gordon Burditt" <go***********@burditt.org> wrote in message
news:12*************@corp.supernews.com... >I have a feature that is hosted on a different domain from the primary
>one
in a frame, and need to retain values in a cookie.
example: A web page at one.com contains a frame which has a page hosted
at
two.com
If I view the frameset from one.com in Firefox, all works well with the
content from two.com. But if trying to view this using IE (with standard
security settings), the cookie set by two.com is not accessible.
Have been tinkering with the domain setting in the setcookie function to
specify the domain: have tried one.com and two.com, but have not been
able
to get at the cookie value.
How can I get this to work?
Hopefully you can't on any browser. Cookies from one domain aren't
supposed to be sent to another. For many, many, uses of cookies,
it's a BIG security hole (you're handing credentials to log into one
web site to another web site, which makes session hijacking easy).
Gordon L. Burditt
Well, I'm not so sure that it's a nasty thing if a frame from a domain has
access to it's own cookies.
In the example I gave, I would intuitively suspect that domain one.com
should have access to cookies created by domain one.com, and that domain
two.com should have access to to cookies created by domain two.com, but they
should not be able to access each other's - That would be an obvious
security breach. You are suggesting thataccessing a cookie from it's own
domain is a breach just because it is contained in a frame? - It does not
make sense.
It strikes me that a frame's contents should be managed as an independant
page (and obviously the feature works in IE if spawned into a "_blank"
window). Perhaps IE is not secure in separating access to a frame's cookies
that are different than it's host frame...
As far as I can see, the contents of the frame belong either to it's own
domain, or the host frame's (which is it?). Setting the cookie as belonging
to one of these two domains should allow me to save values for subsequent
pages. The only alternatives are to pass values as paramters in the page
call (which is inherently more visible to the average user than values
passed in a cookie), or to implement a complex set of forms/posts for
navigation (which would be quite tedious).
"d" <d@example.com> wrote in message
news:KB******************@text.news.blueyonder.co. uk... "Bruno" <20***@TimesOnThe.Net> wrote in message
news:D0*****************@news20.bellglobal.com... Yes, but it does actually work on any browser I have seen aside from IE
(including Netscape, Firefox Win, Firefox Linux, Safari Mac).
The page in the frame does have a domain associated with it, shouldn't
the cookie be available to that domain? (But not necessarily to the
domain of the hosting frame)
Relying on an obvious security flaw for functionality is not exactly
planning on the future :)
Having a frame in a page be able to read cookies from the domain in which
the frame is situated is a nasty thing. Someone could inject a frame into
a site's HTML somehow, and have that frame bring up a page on a second
server, and that'll give the second server access to the cookies of the
first server, on that page. Nasty stuff.
"Gordon Burditt" <go***********@burditt.org> wrote in message
news:12*************@corp.supernews.com... >I have a feature that is hosted on a different domain from the primary
>one
in a frame, and need to retain values in a cookie.
example: A web page at one.com contains a frame which has a page hosted
at
two.com
If I view the frameset from one.com in Firefox, all works well with the
content from two.com. But if trying to view this using IE (with standard
security settings), the cookie set by two.com is not accessible.
Have been tinkering with the domain setting in the setcookie function to
specify the domain: have tried one.com and two.com, but have not been
able
to get at the cookie value.
How can I get this to work?
Hopefully you can't on any browser. Cookies from one domain aren't
supposed to be sent to another. For many, many, uses of cookies,
it's a BIG security hole (you're handing credentials to log into one
web site to another web site, which makes session hijacking easy).
Gordon L. Burditt
>Yes, but it does actually work on any browser I have seen aside from IE (including Netscape, Firefox Win, Firefox Linux, Safari Mac).
The page in the frame does have a domain associated with it, shouldn't the
cookie be available to that domain? (But not necessarily to the domain of
the hosting frame)
A cookie set by domain A should never be sent to a server not in
domain A. >I have a feature that is hosted on a different domain from the primary
>one
in a frame, and need to retain values in a cookie.
example: A web page at one.com contains a frame which has a page hosted at
two.com
If I view the frameset from one.com in Firefox, all works well with the
content from two.com. But if trying to view this using IE (with standard
security settings), the cookie set by two.com is not accessible.
Ok, perhaps I misunderstood you. The cookie set by two.com is not
accessible *ON WHICH SERVER*? I assumed you meant it wasn't
accessible by pages on one.com. And it shouldn't be.
Have been tinkering with the domain setting in the setcookie function to
specify the domain: have tried one.com and two.com, but have not been able
to get at the cookie value.
Get at the cookie value *ON WHICH SERVER*?
How can I get this to work?
Hopefully you can't on any browser. Cookies from one domain aren't
supposed to be sent to another. For many, many, uses of cookies,
it's a BIG security hole (you're handing credentials to log into one
web site to another web site, which makes session hijacking easy).
Gordon L. Burditt
Gordon L. Burditt
Agreed - A cookie on two.com should not be accessible by one.com.
I want the cookie on two.com to be accessible by two.com inside a frame
originating on a page at one.com.
But, when the two.com page sets a cookie, and chains another page in two.com
(within the frameset defined at one.com) the cookie values are not
accessible under IE as they are for all other browsers.
Now, if I go into the IE privacy setting, click 'override cookie handling',
and ensure 'always allow third party cookies' is checked the application
will work in a frame, otherwise it will only work under IE if it is in a
separate browser window (i.e. being the 'primary' site)
I'm just not happy about having to give instructions to the masses telling
them to adjust their cookie settings under IE. And as far as I'm concerned,
site two.com using a site two.com cookie should not be an unrealistic
thing...
"Gordon Burditt" <go***********@burditt.org> wrote in message
news:12*************@corp.supernews.com... Yes, but it does actually work on any browser I have seen aside from IE
(including Netscape, Firefox Win, Firefox Linux, Safari Mac).
The page in the frame does have a domain associated with it, shouldn't the
cookie be available to that domain? (But not necessarily to the domain of
the hosting frame)
A cookie set by domain A should never be sent to a server not in
domain A.
>I have a feature that is hosted on a different domain from the primary
>one
in a frame, and need to retain values in a cookie.
example: A web page at one.com contains a frame which has a page hosted
at
two.com
If I view the frameset from one.com in Firefox, all works well with the
content from two.com. But if trying to view this using IE (with standard
security settings), the cookie set by two.com is not accessible.
Ok, perhaps I misunderstood you. The cookie set by two.com is not
accessible *ON WHICH SERVER*? I assumed you meant it wasn't
accessible by pages on one.com. And it shouldn't be.
Have been tinkering with the domain setting in the setcookie function to
specify the domain: have tried one.com and two.com, but have not been
able
to get at the cookie value.
Get at the cookie value *ON WHICH SERVER*?
How can I get this to work?
Hopefully you can't on any browser. Cookies from one domain aren't
supposed to be sent to another. For many, many, uses of cookies,
it's a BIG security hole (you're handing credentials to log into one
web site to another web site, which makes session hijacking easy).
Gordon L. Burditt
Gordon L. Burditt
>Well, I'm not so sure that it's a nasty thing if a frame from a domain has access to it's own cookies.
It was unclear from your question that this was the situation.
As far as I can see, the contents of the frame belong either to it's own
domain, or the host frame's (which is it?).
The domain of the cookie is the domain of the URL the browser was
fetching when it received the cookie. This does not necessarily
have anything to do with frames: the cookie could have come from
an image fetched from a server unrelated to any frame (banner ad,
for example).
Setting the cookie as belonging
to one of these two domains should allow me to save values for subsequent
pages.
(1) What was the domain in the URL that caused the cookie to be
sent to the browser? (might or might not be a frame URL)
(2) What was the domain in the arguments to setcookie()?
(3) What was the domain of the URL that you think should be delivering
the cookie to the server for that URL, but isn't?
IE might be dropping the cookie if (1) and (2) are unrelated domains.
A cookie set by (1) should never be transmitted to (3) if the domains
are unrelated (regardless of what you set in (2)).
Gordon L. Burditt
>Agreed - A cookie on two.com should not be accessible by one.com.
I want the cookie on two.com to be accessible by two.com inside a frame
originating on a page at one.com.
(1) What is the URL of the hit that sets the cookie? (might be
an image, not a frame)
(2) What is the domain argument of setcookie for the cookie?
(3) What is the URL of the page expecting to see the cookie?
Please try hard to avoid mention of what frame something is in
or what chains what.
If (1) and (2) are not related domains, it should be dropped as a
third party cookie. If (2) and (3) are unrelated, the cookie should
not be sent. There's then no way to make this work if (1) and (3)
are unrelated.
I want the cookie on two.com to be accessible by two.com
inside a frame
originating on a page at one.com.
I take the above two lines to mean that (1) or (3) are on one.com
but you're trying really hard to say it's on two.com, because
that's where the frame is.
Now, if I go into the IE privacy setting, click 'override cookie handling',
and ensure 'always allow third party cookies' is checked the application
will work in a frame, otherwise it will only work under IE if it is in a
separate browser window (i.e. being the 'primary' site)
I'm just not happy about having to give instructions to the masses telling
them to adjust their cookie settings under IE. And as far as I'm concerned,
site two.com using a site two.com cookie should not be an unrealistic
thing...
You shouldn't be happy about giving such instructions. It marks you
as someone to be permanently ignored, and your site as one to be
presumed virus-ridden.
Gordon L. Burditt
A little further investigation into the privacy settings - IE's default
setting (Medium) specifies that it:
- blocks thrid-party cookies that do not have a compact privacy policy
(what's this about?)
- blocks thrid-party cookies that use personally identifiable information
without implicit consent
So I guess it's one of these things that is blocking the cookie.
Not sure why my cookie would violate any of these restrictions: My cookie
is not using any personally identifiable information. The source page has a
list of links to be chosen among. When the user clicks a link, it chains to
a page which accesses a settings file on the server, saves relevant values
to a cookie for the remainder of the session, and chains to the final target
page which requires these values to operate.
"Gordon Burditt" <go***********@burditt.org> wrote in message
news:12*************@corp.supernews.com... Yes, but it does actually work on any browser I have seen aside from IE
(including Netscape, Firefox Win, Firefox Linux, Safari Mac).
The page in the frame does have a domain associated with it, shouldn't the
cookie be available to that domain? (But not necessarily to the domain of
the hosting frame)
A cookie set by domain A should never be sent to a server not in
domain A.
>I have a feature that is hosted on a different domain from the primary
>one
in a frame, and need to retain values in a cookie.
example: A web page at one.com contains a frame which has a page hosted
at
two.com
If I view the frameset from one.com in Firefox, all works well with the
content from two.com. But if trying to view this using IE (with standard
security settings), the cookie set by two.com is not accessible.
Ok, perhaps I misunderstood you. The cookie set by two.com is not
accessible *ON WHICH SERVER*? I assumed you meant it wasn't
accessible by pages on one.com. And it shouldn't be.
Have been tinkering with the domain setting in the setcookie function to
specify the domain: have tried one.com and two.com, but have not been
able
to get at the cookie value.
Get at the cookie value *ON WHICH SERVER*?
How can I get this to work?
Hopefully you can't on any browser. Cookies from one domain aren't
supposed to be sent to another. For many, many, uses of cookies,
it's a BIG security hole (you're handing credentials to log into one
web site to another web site, which makes session hijacking easy).
Gordon L. Burditt
Gordon L. Burditt
Bruno wrote: Agreed - A cookie on two.com should not be accessible by one.com.
I want the cookie on two.com to be accessible by two.com inside a frame
originating on a page at one.com.
But, when the two.com page sets a cookie, and chains another page in two.com
(within the frameset defined at one.com) the cookie values are not
accessible under IE as they are for all other browsers.
Now, if I go into the IE privacy setting, click 'override cookie handling',
and ensure 'always allow third party cookies' is checked the application
will work in a frame, otherwise it will only work under IE if it is in a
separate browser window (i.e. being the 'primary' site)
I'm just not happy about having to give instructions to the masses telling
them to adjust their cookie settings under IE. And as far as I'm concerned,
site two.com using a site two.com cookie should not be an unrealistic
thing...
Bruno,
Just read this thread
That makes sense. The main page is one.com, so two.com is a third-party for
that page. Unlike when the page is directly loaded from two.com, where there is
no other party involved.
Sounds like IE is doing exactly what it should. Other than telling the user to
change their browser settings, there isn't much you can do.
One of the reasons for this setting, btw, is to limit ad tracking. Third part
ads would set cookies on one page and be able to read them on another page (the
ads would be originated at the same domain so this works).
BTW - please don't top post. This group uses bottom posting as a standard.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
Hi Gordon, and thanks for all the effort you are putting into this - Much
appreciated.
From your questions below (1) is the same as (2) which is the same as (3) .
(except that I have thus far left the domain specification at null when
setting the cookie - this should default it to (1) I assume).
It works fine when in it's own browser window, but not when contained in a
frame from a different site.
"Gordon Burditt" <go***********@burditt.org> wrote in message
news:12*************@corp.supernews.com... Agreed - A cookie on two.com should not be accessible by one.com.
I want the cookie on two.com to be accessible by two.com inside a frame
originating on a page at one.com.
(1) What is the URL of the hit that sets the cookie? (might be
an image, not a frame)
(2) What is the domain argument of setcookie for the cookie?
(3) What is the URL of the page expecting to see the cookie?
Please try hard to avoid mention of what frame something is in
or what chains what.
If (1) and (2) are not related domains, it should be dropped as a
third party cookie. If (2) and (3) are unrelated, the cookie should
not be sent. There's then no way to make this work if (1) and (3)
are unrelated.
I want the cookie on two.com to be accessible by two.com
inside a frame
originating on a page at one.com.
I take the above two lines to mean that (1) or (3) are on one.com
but you're trying really hard to say it's on two.com, because
that's where the frame is.
Now, if I go into the IE privacy setting, click 'override cookie
handling',
and ensure 'always allow third party cookies' is checked the application
will work in a frame, otherwise it will only work under IE if it is in a
separate browser window (i.e. being the 'primary' site)
I'm just not happy about having to give instructions to the masses telling
them to adjust their cookie settings under IE. And as far as I'm
concerned,
site two.com using a site two.com cookie should not be an unrealistic
thing...
You shouldn't be happy about giving such instructions. It marks you
as someone to be permanently ignored, and your site as one to be
presumed virus-ridden.
Gordon L. Burditt
"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:eY******************************@comcast.com. .. Bruno wrote: Agreed - A cookie on two.com should not be accessible by one.com.
I want the cookie on two.com to be accessible by two.com inside a frame
originating on a page at one.com.
But, when the two.com page sets a cookie, and chains another page in
two.com (within the frameset defined at one.com) the cookie values are
not accessible under IE as they are for all other browsers.
Now, if I go into the IE privacy setting, click 'override cookie
handling', and ensure 'always allow third party cookies' is checked the
application will work in a frame, otherwise it will only work under IE if
it is in a separate browser window (i.e. being the 'primary' site)
I'm just not happy about having to give instructions to the masses
telling them to adjust their cookie settings under IE. And as far as I'm
concerned, site two.com using a site two.com cookie should not be an
unrealistic thing...
Bruno,
Just read this thread
That makes sense. The main page is one.com, so two.com is a third-party
for that page. Unlike when the page is directly loaded from two.com,
where there is no other party involved.
Sounds like IE is doing exactly what it should. Other than telling the
user to change their browser settings, there isn't much you can do.
One of the reasons for this setting, btw, is to limit ad tracking. Third
part ads would set cookies on one page and be able to read them on another
page (the ads would be originated at the same domain so this works).
BTW - please don't top post. This group uses bottom posting as a
standard.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
So basically you are saying that IE by default kills all cookies not
relating to the primary level domain.
It seems that Microsoft has a different interpretation of this than the
Mozilla folks: With Mozilla (Firefox) if restricting Cookies to be 'for the
originating site only', which is not the default, the application still
works, as I assume that they will allow a site that created its cookie to
retrieve its cookie, even if in a frame (since it is the originating site).
If IE's approach is as you say, it may stop ad counters, but also cripples
having nested content not originating from the primary site - That's a
shame.
If the domain-in-a-frame (two.com in the example) were to specify the main
site (one.com) as being the cookie's owner at creation time, would this work
to get around the problem? (I'm really just interested getting it working in
the frame).
Aside from getting users to change their settings, the only other way is to
detect IE and spawn it into another browser instance, but this is an ugly
solution...
>A little further investigation into the privacy settings - IE's default setting (Medium) specifies that it:
- blocks thrid-party cookies that do not have a compact privacy policy
(what's this about?)
Your web site can publish a privacy policy. Google "compact privacy
policy" and select "How to Deploy P3P Policies on Your Web Site"
(on msdn.microsoft.com). Typically it's in the URL /w3c/p3p.xml.
- blocks thrid-party cookies that use personally identifiable information
without implicit consent
If you don't publish a policy to not use personally identifiable
information, it's presumed that you do, and sell it to Satan, and
use it to rape and pillage the user.
So I guess it's one of these things that is blocking the cookie.
Not sure why my cookie would violate any of these restrictions: My cookie
Your *LACK OF A POLICY* violates those restrictions. IE can't read your
mind or figure out what you encrypted into that cookie (if anything).
is not using any personally identifiable information. The source page has a
list of links to be chosen among. When the user clicks a link, it chains to
a page which accesses a settings file on the server, saves relevant values
to a cookie for the remainder of the session, and chains to the final target
page which requires these values to operate.
PHP doesn't have a function called chain(). This probably doesn't
refer to a method of attaching your partner to the bed. Are you
using it in the context of "when the user clicks the submit button
or a link, the browser goes to this other page"? Or something that
doesn't require user action?
Gordon L. Burditt
Bruno wrote: "Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:eY******************************@comcast.com. ..
Bruno wrote:
Agreed - A cookie on two.com should not be accessible by one.com.
I want the cookie on two.com to be accessible by two.com inside a frame
originating on a page at one.com.
But, when the two.com page sets a cookie, and chains another page in
two.com (within the frameset defined at one.com) the cookie values are
not accessible under IE as they are for all other browsers.
Now, if I go into the IE privacy setting, click 'override cookie
handling', and ensure 'always allow third party cookies' is checked the
application will work in a frame, otherwise it will only work under IE if
it is in a separate browser window (i.e. being the 'primary' site)
I'm just not happy about having to give instructions to the masses
telling them to adjust their cookie settings under IE. And as far as I'm
concerned, site two.com using a site two.com cookie should not be an
unrealistic thing...
Bruno,
Just read this thread
That makes sense. The main page is one.com, so two.com is a third-party
for that page. Unlike when the page is directly loaded from two.com,
where there is no other party involved.
Sounds like IE is doing exactly what it should. Other than telling the
user to change their browser settings, there isn't much you can do.
One of the reasons for this setting, btw, is to limit ad tracking. Third
part ads would set cookies on one page and be able to read them on another
page (the ads would be originated at the same domain so this works).
BTW - please don't top post. This group uses bottom posting as a
standard.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
So basically you are saying that IE by default kills all cookies not
relating to the primary level domain.
It seems that Microsoft has a different interpretation of this than the
Mozilla folks: With Mozilla (Firefox) if restricting Cookies to be 'for the
originating site only', which is not the default, the application still
works, as I assume that they will allow a site that created its cookie to
retrieve its cookie, even if in a frame (since it is the originating site).
If IE's approach is as you say, it may stop ad counters, but also cripples
having nested content not originating from the primary site - That's a
shame.
If the domain-in-a-frame (two.com in the example) were to specify the main
site (one.com) as being the cookie's owner at creation time, would this work
to get around the problem? (I'm really just interested getting it working in
the frame).
Aside from getting users to change their settings, the only other way is to
detect IE and spawn it into another browser instance, but this is an ugly
solution...
Basically, yes, IE kills those cookies. You can thank the sites which abused
cookies and used them to track the sites people visited. Microsoft was under
fire to increase security to stop the abuse, and they did.
I believe you can do the same by tightening Firefox's security, but I'm not
positive. It's just a matter of what the default is.
The whole purpose of stopping this is to prevent third-party sites from
storing/retrieving cookies. I doubt there is any way around it. If there were,
that would be another security exposure these abusive sites would use.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:va******************************@comcast.com. .. Bruno wrote: "Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:eY******************************@comcast.com. ..
Bruno wrote:
Agreed - A cookie on two.com should not be accessible by one.com.
I want the cookie on two.com to be accessible by two.com inside a frame
originating on a page at one.com.
But, when the two.com page sets a cookie, and chains another page in
two.com (within the frameset defined at one.com) the cookie values are
not accessible under IE as they are for all other browsers.
Now, if I go into the IE privacy setting, click 'override cookie
handling', and ensure 'always allow third party cookies' is checked the
application will work in a frame, otherwise it will only work under IE
if it is in a separate browser window (i.e. being the 'primary' site)
I'm just not happy about having to give instructions to the masses
telling them to adjust their cookie settings under IE. And as far as I'm
concerned, site two.com using a site two.com cookie should not be an
unrealistic thing...
Bruno,
Just read this thread
That makes sense. The main page is one.com, so two.com is a third-party
for that page. Unlike when the page is directly loaded from two.com,
where there is no other party involved.
Sounds like IE is doing exactly what it should. Other than telling the
user to change their browser settings, there isn't much you can do.
One of the reasons for this setting, btw, is to limit ad tracking. Third
part ads would set cookies on one page and be able to read them on
another page (the ads would be originated at the same domain so this
works).
BTW - please don't top post. This group uses bottom posting as a
standard.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
So basically you are saying that IE by default kills all cookies not
relating to the primary level domain.
It seems that Microsoft has a different interpretation of this than the
Mozilla folks: With Mozilla (Firefox) if restricting Cookies to be 'for
the originating site only', which is not the default, the application
still works, as I assume that they will allow a site that created its
cookie to retrieve its cookie, even if in a frame (since it is the
originating site).
If IE's approach is as you say, it may stop ad counters, but also
cripples having nested content not originating from the primary site -
That's a shame.
If the domain-in-a-frame (two.com in the example) were to specify the
main site (one.com) as being the cookie's owner at creation time, would
this work to get around the problem? (I'm really just interested getting
it working in the frame).
Aside from getting users to change their settings, the only other way is
to detect IE and spawn it into another browser instance, but this is an
ugly solution...
Basically, yes, IE kills those cookies. You can thank the sites which
abused cookies and used them to track the sites people visited. Microsoft
was under fire to increase security to stop the abuse, and they did.
I believe you can do the same by tightening Firefox's security, but I'm
not positive. It's just a matter of what the default is.
The whole purpose of stopping this is to prevent third-party sites from
storing/retrieving cookies. I doubt there is any way around it. If there
were, that would be another security exposure these abusive sites would
use.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Yes, well... It appears that Microsoft forgot to read the specification
then:
(An excerpt from the authority at http://www.w3.org/TR/html4/present/frames.html#h-16.3)
------------
"16.1 Introduction to frames
HTML frames allow authors to present documents in multiple views, which may
be independent windows or subwindows. "
------------
If a frame is to be considered an independent window, then third-party
considerations really have nothing really to do with it. I guess Microsoft
has decided that the standard does not apply to them, and have gone their
own path as usual...
Oh well, I'm not going to waste my breath tackling with this any further.
I'll just have to put in the best workaround that will do the job and forget
about it.
Thanks for your insights Jerry.
"Gordon Burditt" <go***********@burditt.org> wrote in message
news:12*************@corp.supernews.com... A little further investigation into the privacy settings - IE's default
setting (Medium) specifies that it:
- blocks thrid-party cookies that do not have a compact privacy policy
(what's this about?)
Your web site can publish a privacy policy. Google "compact privacy
policy" and select "How to Deploy P3P Policies on Your Web Site"
(on msdn.microsoft.com). Typically it's in the URL /w3c/p3p.xml.
- blocks thrid-party cookies that use personally identifiable information
without implicit consent
If you don't publish a policy to not use personally identifiable
information, it's presumed that you do, and sell it to Satan, and
use it to rape and pillage the user.
So I guess it's one of these things that is blocking the cookie.
Not sure why my cookie would violate any of these restrictions: My cookie
Your *LACK OF A POLICY* violates those restrictions. IE can't read your
mind or figure out what you encrypted into that cookie (if anything).
is not using any personally identifiable information. The source page has
a
list of links to be chosen among. When the user clicks a link, it chains
to
a page which accesses a settings file on the server, saves relevant values
to a cookie for the remainder of the session, and chains to the final
target
page which requires these values to operate.
PHP doesn't have a function called chain(). This probably doesn't
refer to a method of attaching your partner to the bed. Are you
using it in the context of "when the user clicks the submit button
or a link, the browser goes to this other page"? Or something that
doesn't require user action?
Gordon L. Burditt
Thanks for your insights Gordon.
I will look into Microsoft's privacy policy information and see if it is
worthwhile doing this - I tend to stay away from any code that is MS
specific, so I may just resort to a compromise that does not require this.
Bruno wrote: "Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:va******************************@comcast.com. ..
Bruno wrote:
"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:eY******************************@comcast.c om...
Bruno wrote:
>Agreed - A cookie on two.com should not be accessible by one.com.
>
>I want the cookie on two.com to be accessible by two.com inside a frame
>originating on a page at one.com.
>
>But, when the two.com page sets a cookie, and chains another page in
>two.com (within the frameset defined at one.com) the cookie values are
>not accessible under IE as they are for all other browsers.
>
>Now, if I go into the IE privacy setting, click 'override cookie
>handling', and ensure 'always allow third party cookies' is checked the
>application will work in a frame, otherwise it will only work under IE
>if it is in a separate browser window (i.e. being the 'primary' site)
>
>I'm just not happy about having to give instructions to the masses
>telling them to adjust their cookie settings under IE. And as far as I'm
>concerned, site two.com using a site two.com cookie should not be an
>unrealistic thing...
>
Bruno,
Just read this thread
That makes sense. The main page is one.com, so two.com is a third-party
for that page. Unlike when the page is directly loaded from two.com,
where there is no other party involved.
Sounds like IE is doing exactly what it should. Other than telling the
user to change their browser settings, there isn't much you can do.
One of the reasons for this setting, btw, is to limit ad tracking. Third
part ads would set cookies on one page and be able to read them on
another page (the ads would be originated at the same domain so this
works).
BTW - please don't top post. This group uses bottom posting as a
standard.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
So basically you are saying that IE by default kills all cookies not
relating to the primary level domain.
It seems that Microsoft has a different interpretation of this than the
Mozilla folks: With Mozilla (Firefox) if restricting Cookies to be 'for
the originating site only', which is not the default, the application
still works, as I assume that they will allow a site that created its
cookie to retrieve its cookie, even if in a frame (since it is the
originating site).
If IE's approach is as you say, it may stop ad counters, but also
cripples having nested content not originating from the primary site -
That's a shame.
If the domain-in-a-frame (two.com in the example) were to specify the
main site (one.com) as being the cookie's owner at creation time, would
this work to get around the problem? (I'm really just interested getting
it working in the frame).
Aside from getting users to change their settings, the only other way is
to detect IE and spawn it into another browser instance, but this is an
ugly solution...
Basically, yes, IE kills those cookies. You can thank the sites which
abused cookies and used them to track the sites people visited. Microsoft
was under fire to increase security to stop the abuse, and they did.
I believe you can do the same by tightening Firefox's security, but I'm
not positive. It's just a matter of what the default is.
The whole purpose of stopping this is to prevent third-party sites from
storing/retrieving cookies. I doubt there is any way around it. If there
were, that would be another security exposure these abusive sites would
use.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Yes, well... It appears that Microsoft forgot to read the specification
then:
(An excerpt from the authority at
http://www.w3.org/TR/html4/present/frames.html#h-16.3)
------------
"16.1 Introduction to frames
HTML frames allow authors to present documents in multiple views, which may
be independent windows or subwindows. "
------------
If a frame is to be considered an independent window, then third-party
considerations really have nothing really to do with it. I guess Microsoft
has decided that the standard does not apply to them, and have gone their
own path as usual...
Oh well, I'm not going to waste my breath tackling with this any further.
I'll just have to put in the best workaround that will do the job and forget
about it.
Thanks for your insights Jerry.
No, I don't think it's that they don't think the standard applies. I think it's
more because of the attacks and data mining some irresponsible websites do,
especially with IE. This almost forced them to implement these security measures.
And yes, that is the default because most users are clueless about such things.
But MS does give the user the opportunity to disable the security measure.
I can find fault with a lot of things MS does, but in this case I really don't
think I can. I know it's a problem, though, when developers with real needs
such as yours have to put up with hassles. Such is the problem when a few ruin
something for the rest.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
================== This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Maarten |
last post by:
Start http://212.123.5.17/mb/xdata/am.asp
in the left Frame choose N,F or D (Nederlands, French, Deutsch) Not E
(Standard for English)
Click GO
Close your Browser
Reopen the page. On top you...
|
by: Rahul Chatterjee |
last post by:
Hello All
I have an asp page problem (the nature is slightly complex so please bear
with the long winded explanation).
We have a sandbox front end domain and a sandbox backend domain. The...
|
by: kam bansal |
last post by:
Hi all,
Can javascript read a cookie from a different domain? Meaning, if my
html page is running on "www.mydomain.com" and I goto another domain
"www.another.com" to do some work, and then I...
|
by: LagWagon |
last post by:
hi,
I have a page whith frames where y load other pages in. If these other pages
are in my computer y can read/write with javascritp in their properties like
name, location, href etc. but when y...
|
by: BH |
last post by:
I developed a small web app using the FormsAuthentication class to set a
cookie (FormsAuthentication.SetAuthCookie(value, isPersist)). The cookie
persists fine on my local PC when "isPersist" is...
|
by: rss |
last post by:
SUMMARY:
==========
I am unable to pass along a simple Cookie obtained from a HttpWebRequest
call (Machine A's ASP.NET app) so that another Web Server (Machine B)
recongnizes the cookie.
I...
|
by: Super Mango |
last post by:
Hi,
I have this login that works fine when the page is presented as-is, but
I want to allow other site owner to put any page from my site in a
frame in their own site.
The thing is that when...
|
by: =?Utf-8?B?YzY3NjIyOA==?= |
last post by:
Hi all,
Is there an easier way to handle that? I used Javascript to handle this when
our two domains are hosted on two different servers(on different networks)
and our search engine marketing...
|
by: Stevo |
last post by:
I'm guessing this is a laughably obvious answer to many here, but it's
not to me (and I don't have a server or any knowledge of PHP to be able
to try it). It's not strictly a PHP question, but...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
