Forums / Install & configuration / strange behaviour when redirected from masked (or gripped) url

strange behaviour when redirected from masked (or gripped) url

Previous topic

Install & configuration

Next topic

Author	Message
nigel dodd	Tuesday 12 April 2005 8:23:57 am My domain is parked with Freeparking who allow me to forward to my own isp. When this happens the Address window of the browser gives my domain name (as parked with Freeparking), not the real isp address. Furthermore, my static home page on the isp has links to Apache running on my home pc (broadband but changeable ip address, hence the homepage on the isp whose links are periodically updated to track the changing ip address). When the user clicks any of the links on the homepage he gets directed to my home pc. The browser still says the original domain name registered with Freeparking, not the raw ip address of my home pc. At this stage the user is in the dynamic, easyPublish-driven cms. Now everything appears to work fine except when the user logs in. Normally (and this is what you get if you go directly to the home pc using the raw ip address or localhost) the Login word changes to Logout after you login. Also, I have got roles and permissions set so that the logged-in user sees extra menu entries compared to the anonymous user. Neither of these two things happen when you get to my site through the convoluted route of Freeparking -> isp -> hope pc, although the user is definitely logged in (one of the pages lists all logged in users and he appears there). I think the problem has to do with this masking or gripping of the url done by Freeparking but I don't know how to work around the problem.
nigel dodd	Monday 18 April 2005 2:51:47 am thought I'd post the conclusion to this original posting by myself! The problem was due to cookies and Internet Explorer's default settings which seem to reject what it calls Third party cookies. To demonstrate this it is possible to allow such cookies by fiddling with the IE Options and then the login process works correctly. The reason these are Third-party is because the browser has the gripped url in its address bar but the site issuing the cookie is my own computer with different ip address. I have worked around the problem by defeating Freeparking's gripping of the url. I am puzzled by a previous post http://www.ez.no/ez_publish/info/ez_publish_2_2/forum/general/cookieless_sessions_do_not_appear_to_work which says that ezPublish logins work without cookies if you set $UsePHPSessions = true in index.php but unfortunately this is for version 2.1 and there is no mention of $UsePHPSessions in the version 3.4 index.php. Has this setting been changed?
Bård Farstad	Wednesday 20 April 2005 12:55:18 am Nigel, glad that you found the reason for your problem. eZ publish 3.x does not support cookie less sessions since they are very un-secure. Since Apache logs referrer URL's it is very easy to hijack sessions stored as part of the URL, specially when linking out from a website as they will be stored in the log file on the remote server as well. You should also always disable transparent session id's in your PHP configuration. For the same reasons. --bård --bård Documentation: http://ez.no/doc

Author

Message

nigel dodd

Tuesday 12 April 2005 8:23:57 am

My domain is parked with Freeparking who allow me to forward to my own isp. When this happens the Address window of the browser gives my domain name (as parked with Freeparking), not the real isp address.

Furthermore, my static home page on the isp has links to Apache running on my home pc (broadband but changeable ip address, hence the homepage on the isp whose links are periodically updated to track the changing ip address).

When the user clicks any of the links on the homepage he gets directed to my home pc. The browser still says the original domain name registered with Freeparking, not the raw ip address of my home pc. At this stage the user is in the dynamic, easyPublish-driven cms.

Now everything appears to work fine except when the user logs in. Normally (and this is what you get if you go directly to the home pc using the raw ip address or localhost) the Login word changes to Logout after you login. Also, I have got roles and permissions set so that the logged-in user sees extra menu entries compared to the anonymous user. Neither of these two things happen when you get to my site through the convoluted route of Freeparking -> isp -> hope pc, although the user is definitely logged in (one of the pages lists all logged in users and he appears there).

I think the problem has to do with this masking or gripping of the url done by Freeparking but I don't know how to work around the problem.

nigel dodd

Monday 18 April 2005 2:51:47 am

thought I'd post the conclusion to this original posting by myself!

The problem was due to cookies and Internet Explorer's default settings which seem to reject what it calls Third party cookies. To demonstrate this it is possible to allow such cookies by fiddling with the IE Options and then the login process works correctly.

The reason these are Third-party is because the browser has the gripped url in its address bar but the site issuing the cookie is my own computer with different ip address.

I have worked around the problem by defeating Freeparking's gripping of the url.

I am puzzled by a previous post http://www.ez.no/ez_publish/info/ez_publish_2_2/forum/general/cookieless_sessions_do_not_appear_to_work which says that ezPublish logins work without cookies if you set $UsePHPSessions = true in index.php but unfortunately this is for version 2.1 and there is no mention of $UsePHPSessions in the version 3.4 index.php. Has this setting been changed?

Bård Farstad

Wednesday 20 April 2005 12:55:18 am

Nigel,

glad that you found the reason for your problem.

eZ publish 3.x does not support cookie less sessions since they are very un-secure. Since Apache logs referrer URL's it is very easy to hijack sessions stored as part of the URL, specially when linking out from a website as they will be stored in the log file on the remote server as well.

You should also always disable transparent session id's in your PHP configuration. For the same reasons.

--bård

Documentation: http://ez.no/doc