we've recently upgraded our D3 / Flashconnect from Centos7 & D3 10.1 to Almalinux 9.4 & D3 10.3.4. flashconnect has been version 3.9 throughout. everything seems to be working fine except for one thing, which worked on the old set-up and doesn't seem to be working on the new one.

the issue is when the client follows a link that takes to a different cgi-bin script on our server. that scrip lets them upload files to the webserver, and contains a <form> link back to where they left off on flashconnect. this has worked perfectly for us for more years than i can remember, the return to flashconnect has always been seemless thanks to a single cookie with the w3profileid stored in the client browser.

on the new system however, when they return to fccgi.exe instead of ending up where they should they're getting a logon screen that seems to be generated by wbp w3logonscreen and i have no idea why that's happening. i don't know what's calling that subroutine so i'm not sure how to trace backwards to find where the fault is or what's missing. i can say that absolutely nothing in our normal operation would ever call that routine. from log on to log out they're only ever using our own inhouse flashbasic routines & html templates

any guidance would be most appreciated!

looking at the w3logs file & it seems like something is causing flashconnect to issue a new w3profileid in this specific situation, but i can't figure out why it's doing that. hitting the back button will get us back into the previous valid session, which is still valid.

but for whatever reason linking to a different cgi script on the same server then linking back causes a new w3profileid which means the original existing logged-on session is ignored & the user gets a logon prompt. 

i don't know if this problem is coming from the apache webserver (having gone from centos7 to almalinux9) or if it's something inside d3 (10.1 to 10.3 & reinstall of flashconnect)

Hi Violet,

If it isn't there already, you might want to try adding the 'd' option to the 'Options' attribute (attribute 8) of the W3APPS item of the FC application that is being executed.  This will log more information to the W3LOGS,DUMP file (I believe you'll need to create that data level if it's not already there).  Once that's in place, look for the EHTTP_COOKIE string in the file and see if it has the value you expect it to have throughout the whole process you described above.  Depending on how busy the site is it could be a little challenging to sort out which W3LOGS,DUMP items belong to a given session but some of the other name/value pairs in the items should help with that.

Best regards.

Hi Violet,

If it isn't there already, you might want to try adding the 'd' option to the 'Options' attribute (attribute 8) of the W3APPS item of the FC application that is being executed.  This will log more information to the W3LOGS,DUMP file (I believe you'll need to create that data level if it's not already there).  Once that's in place, look for the EHTTP_COOKIE string in the file and see if it has the value you expect it to have throughout the whole process you described above.  Depending on how busy the site is it could be a little challenging to sort out which W3LOGS,DUMP items belong to a given session but some of the other name/value pairs in the items should help with that.

Best regards.

i tried it out this morning when things were quiet & sure enough the EHTTP_COOKIE value is changing and i don't know why?

at initial log on we get this: EHTTP_COOKIE = w3ProfileId=204364079892880 and that sticks through the session without any problems as long as we don't link out to another cgi script.

if we do that, then try and jump back into the existing flashconnectt session we get a new cookie: HTTP_COOKIE = w3ProfileId=2035174662204114

interestingly these profile numbers are consistent, they're the same two i saw yesterday when i first started investigating this problem.

it looks like the only other differences between the two states (before & after it breaks) are:

EHTTP_HOST - in one case there's a www. prefix & the other case there is not

EHTTP_REFERRER - obviously the ones from within flashconnect are /cgi-bin/fccgi.exe while the broken one has the cgi-bin/[othername].pl 

i'm wondering if it's the host that's causing the problem? could the presense / absense of www. on the domain name cause it to have a different w3profileid cookie?

gonna test that & see what happens

looks like that was the problem!! not sure why this didn't cause issues before, but alternating between the www. prefix or not is causing it to come up with a new profile id / new cookie

at least now i now what to fix lol

thanks again for the tip re. the w3logs,dump, Chris!