FEU/Core/FF/IE interaction unresolved but now understood

[wakewatcher]

First of all, thanks for all for your recent coddling.

Secondly, I'm not sure how helpful the following is but thought I'd share it in case others ran into similar behaviors.

Lastly, While nothing is fixed I now believe I know exactly what's happening. However I don't know the why it's happening. The the root cause may be FEU based, Core Product based, Window's IE based, or likely as some have suggested something I've introduced. (Or even Godaddy.com based as it also is involved as described below.)

Over the last couple of weeks I've had a hell of a time with issues regarding consistency between uniform browser experience and sign in and sign out as moaned about; (Don't bother looking at them except perhaps the screencast.)
here->http://forum.cmsmadesimple.org/viewtopi ... =8&t=65457,
here->http://forum.cmsmadesimple.org/viewtopi ... =7&t=65361,
here->http://forum.cmsmadesimple.org/viewtopi ... =7&t=65291, and
here->http://forum.cmsmadesimple.org/viewtopi ... =7&t=65306 and easily seen in a screen cast
here->http://screencast.com/t/nBZ2bMyv.

The version specifics etc are described in those other posts but those may just end up being a red herring after all is said and done. Here are the key salient points of my setup. My cms (CondoDev1) is installed in a folder off the root of a different domain, I.e. at MyCondoDevelopments.com/CondoDev1. Then I have my domain registrar, Godaddy, forward requests for CondoDev1.com to MyCondoDevelopments.com/CondoDev1 with URL hiding. (Not sure 'hiding' makes a difference to the observed behavior or not.)

When using FF/Chrome and accessing the cms via CondoDev1.com everything is, as they say, hunky-dory. (Sign-in/sign-out and showing protected content as expected.)

However if you open an IE browser and access via CondoDev1.com you get the behavior as observed in the screen cast above. BUT if you access it via MyCondoDevelopments.com/CondoDev1 then Olé! It works.

And interestingly after you access it once via the full path then, until you close that IE browser session, it is fully operational (sign-in/sign-out) accessible via CondoDev1.com as well. ( And in new browser tabs etc. but once you kill the IE browser and bring it up again then you must access via the full path again.)

So unfortunately my IE users that try to sign-in with FEU using the CondoDev1.com address are out of luck. I've got a work around but ultimately will move the cms to a root location.

Nonetheless I would have not expected so dramatic behavior differences between FF/Chrome and IE so I remain suspicious.

[calguy1000]

This is probably an IE issue and nothing to do with CMSMS.

Here's a similar story about similar problems with a drupal installation:
http://drupal.org/node/832072

[wakewatcher]

Yes that does look very similar.

I found something else while working on a workaround. Don't know if it's useful or not. I found in this IE case that the session id in the feusers_loggedin table doesn't match the actual session id in the cases where the wrong form is rendered. (i.e keep getting the sign-in page) So I'm surmising what happens normally is the logic checks to see if there is a user in the table with the same session id and if so then renders the sign-out form.

(But when I try again using the full path then the session id matches and the expected form is rendered.)

So when I've observed in the past that the user is logged in the database that is only half true. The user shows up in the database but not attached to the session of the browser that put it there. So apparently the browser's session id changed. I assume this also explains why $feusers = cms_utils::get_module('FrontEndUsers');
$id = $feusers->LoggedInId(); doesn't return an id. (Because it is probably looked up based on session id which now don't match.)

[Dr.CSS]

Sounds like IE doesn't understand the "URL hiding"...