Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Weird SESSIONS behavior in Frames

0 views
Skip to first unread message

Shill

unread,
Dec 5, 2002, 8:58:21 PM12/5/02
to
I have a normally function PHP site working if you access it directly
without frames. I'm store SESSION data as the user navigates the
website, and the website refreshes.

However, if I put the same site into a frame, suddenly, all my SESSION
data becomes GET data since I can see PHPSESSID in the URL of the
links on the page. When I click a URL, it can't find my SESSION data.

Using php 4.2.2 + RH 7.2

Thanks

Arjan van Bentem

unread,
Dec 6, 2002, 4:11:27 AM12/6/02
to
"Shill" wrote

> However, if I put the same site into a frame, suddenly, all my SESSION
> data becomes GET data since I can see PHPSESSID in the URL of the
> links on the page.

That might simply indicate that the browser has rejected the cookie. Do
all the frames of the frameset belong to the same domain?

a.


Arjan van Bentem

unread,
Dec 6, 2002, 4:37:43 AM12/6/02
to
"Shill" wrote

> all my SESSION data becomes GET data since I can
> see PHPSESSID in the URL

Just to make sure you understand: it's not like *all* session data will be
put into the URL. Just the ID; the data itself is still stored on the web
server.

a.


Shill

unread,
Dec 6, 2002, 6:27:25 PM12/6/02
to
Well, the weird thing is, if I set my frame target URL from
"http://www.domain.com/php/?action=sed" to "php/?action=sed", all the
session stuff work correctly! So changing from a absolute URL to a
relative one fixes it in IE 6.

AND, another thing...If I use Netscape 7, the sessions work as well,
even using absolute URL.

So I'm reallly curious what's going on here.

Thanks.

"Arjan van Bentem" <avbe...@DONT-YOU-DARE-dds.nl> wrote in message news:<3df06983$0$11750$e4fe...@news.xs4all.nl>...

Shill

unread,
Dec 6, 2002, 6:32:27 PM12/6/02
to
Arjan,

No, not all the frames belong to the same domain. But I also made a
test frameset using all one domain and it still fails.

When it fails, you can tell because all the URLS generated contain
PHPSESSID embedded in the link.

When it works, you don't see PHPSESSID there.


"Arjan van Bentem" <avbe...@DONT-YOU-DARE-dds.nl> wrote in message news:<3df06983$0$11750$e4fe...@news.xs4all.nl>...

Arjan van Bentem

unread,
Dec 6, 2002, 7:28:04 PM12/6/02
to
"Shill" wrote

> No, not all the frames belong to the same domain.

Then you'll see a little red eye in the statusbar of Internet Explorer
telling you that some third-party cookie has been rejected. Double-click
that little eye for more details.

> When it fails, you can tell because all the URLS generated contain
> PHPSESSID embedded in the link.

Which is not a problem -- the session stuff will still work, but using URL
rewriting rather than cookies. This is not too weird; it is all by design
of both PHP and IE.

a.


Shill

unread,
Dec 6, 2002, 8:31:56 PM12/6/02
to
Ok, found out the problem. To simulate the problem, I turned off
cookies on my browser, and tried loading the page enclosed in a frame.
Clicked on a URL, javascript pops open a new window, and the session
dies.

Repeated the same process except without a frame, javascript window
pops up, session still alive.

Any ideas? Why does it only happen when I put it in a frame?


shawsh...@hotmail.com (Shill) wrote in message news:<c344bd54.02120...@posting.google.com>...

Shill

unread,
Dec 6, 2002, 8:44:51 PM12/6/02
to
Well, for those that were hanging on to the edge of their seats for
the answer, here it is. It seems the the url I wrote for the
javacscript function to perform a popup wasn't properly encoded by the
PHP server. I had to manually encode the PHPSESSID in. I was tricked
because when I hovered the mouse above the link, it SHOWS the
PHPSESSID in the link.

So there!

0 new messages