You need to log in before you can comment on or make changes to this bug.
As the chameleon package is currently setup, there is no easy way to supply a specific session ID and/or session save-path. It would be useful if the these two parameters could be supplied to a chameleon application using form variables (e.g., http://url.com/cwc2app?sid=sessionID&savepath=sessionpath) - this could make it easier to integrate Chameleon applications into websites that already make use of PHP sessions, rather than having the Chameleon applications generating their own sessions every time they're started.
After a little work, I incorporated the session structure for my website. Now when a chameleon application loads with sid=sessionName in the url, it does actually use the appropriate save-path and session file, but the "Your session has expired" message still appears, also causing widgets such as the identify tool to fail.
Changed target to FUTURE.
I have just now been able to get a chameleon application to use the same user- based sessions as the rest of the website I'm developing. This revealed a new problem, however. I've found that if I open a chameleon application with a session that already exists (using the same session structure that Chameleon uses) the CWCInitialize() function in chameleon.php does not get called. This is because chameleon only does this if there is no SID set in the moHttpFormVars object, the variable mbSessionOK is false(because the session is actually valid now), or if the $_SESSION['gszMapName'] is previously set and different from $szMapFile. I've worked around this by setting $_SESSION ["gszMapName"] equal to an empty string just after a user's session is created, before sending the browser to the chameleon application - this then satisfies the last condition so that CWCInitialize will be executed. A second (and less important) problem: in session.php, I was having an issue with the parameters for the initializeSession function; the third parameter (the session ID) is not actually used if an sid appears in the _GET or _POST globals. This is not a big problem in itself, but it prevents the use of a different session-id than the one initially supplied in the URL (e.g., at the time a user logs in with the site I'm working on, the SID gets changed). I got around this by setting the 'sid' variable to the desired name in both _GET and _POST globals before running initializeSession.
re-filing to Chameleon-Core