the SAME server than issued the page - so the framed page can receive a
cookie from the browser that sent it. Don't think of a frameset as a
"container" - rather think of it as a collection of independent windows
(which is really when it is to browser). Each frame uses a separate
thread, separate memory space and so forth.
The browser's security model prevents frames from different servers from
sharing resources just as it would prevent different browser windows
from doing the same thing. This can be a pain in rare case.
Cross-domain cookies are more specific to assets within a page. For
example I call a page from server A and that page calls a graphic from
server B. If that graphic tried to write a cookie then you'd run into
trouble with "third party cookies". You can address this by making sure
that server B has a compact privacy statement available. This also goes
for scripts called from another server.
I spent more than a little of my retreating youth recently doing the
same thing: framing a NEFn.com application inside a MetLife.com
application. It's a nasty business, but does have clear rules. It's
just a shame that all those rules tend to work against you. ;^)
Frames from separate servers can't see each other's cookies, they can't
run each other's scripts and they can't call each other's methods.
I actually built an asynchronous message transfer service that worked by
having on frame write a message to the browser status bar and having
the other read it. Unfortunately IE 5.5 considered this a security
breach. Netscape 4 and 7 and IE 4 and 6 allowed it happily. It was a
kludge by any definition but it was kind of interesting. It would be
nice if there were a "public" scope or space to keep information that
you DID want available to cross site scripting - that would solve many
of these problems (you'd have to explicitly populate it to allow other
servers to see it).
Jim Davis
-----Original Message-----
From: Ben Doom [mailto:[EMAIL PROTECTED]
Sent: Friday, October 31, 2003 2:38 PM
To: CF-Community
Subject: Re: URGENT! Frames and sessions
At a guess, I would say that the problem is that some browsers prevent
cross-domain cookies. That is, if the title in the URL bar is at
www.domain-a.com, and the content is from www.domain-b.com, the cookies
are blocked. Now, this may only pertain to things like embedded data
(webbugs and ads) but it may also affect frames.
That's all I can think of offhand.
--benD
William H Bowen wrote:
> All,
>
> I am being forced by an organization higher up the food chain to now
> only grant access to certain parts of our corporate external site via
> frameset.
>
> It's a domain name thing, they don't want us using ours anymore
> (www.esca.com) despite years of brand recognition in our industry.
>
> So here's the issue. many of the parts of the site they want accessed
> through the frameset are password protected and access is granted by
> reading a cookie value set from my site.
>
> Now, I did a bit of research because of the obvious third party cookie
> issues caused by frames, and I found that session management is
> "compatible" with frames (sort of). I set up a test and found that if
I
> access it directly (www.esca.com/blah url ) everything works fine
> session variable initiate and expire as requested, but if I access it
> via frames, the login doesn't work.
>
> What am I missing? Does the session have to be init'ed on the outside
> frame? If so can I init the session with _javascript_ and then write to
it
> with CF? I don't have control of the outside frame, it's hosted in
> England, but if I need to I can probably get something added there.
>
> The external frame is being handled in the OpenMarket CMS and my site
is
> all CFMX.
>
> Please help!
>
> --
>
> will
>
> ----
>
> William H Bowen
> Marketing Communications Manager
> ALSTOM EAI Corporation
>
>
_____
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
