Strange issue with SessionID not being set after upgrading NetTalk

[Devan]

Hi All,

I've got a site that worked beautifully last year, but this year when I went to make some changes and recompile it for my client using NetTalk 6.50, I am finding that the SessionID is not being set at all for any page.

I check the value of p_web.SessionID straight after p_web.NewSession() on a page, and get the value 'null'.

What could be happening here to cause this?  I have no idea what the previous version was compiled under.  It would have been a much earlier version of 6.

I had to untick the boxes for 'Change Session in Log In/Out' and 'Delete Session On Logout' like I have for other apps that I have upgraded to newer versions, but would these be causing the issue?  All I have done is add a couple of fields to two forms.

Thanks,
Devan

[Bruce]

if you look at the log do you see the session coming in as a cookie?

perhaps the browser you are testing with is suppressing cookies?

cheers
Bruce

[mark]

Maybe your sessionid is still a long. Nettalk changed the sessionid to a string, as indicated in the version history overview.
Now you can choose a string or a long but you have to tell Nettalk to use a long in SETTINGS, (webserver - extensions).

Hope this simple anser does help.

Mark B.

[Devan]

Thanks for the replies Mark and Bruce...

How odd - I left the project last night and went to bed, came back this morning and just loaded, recompiled and ran, and it looks like the Session Variables were being set Ok.  

I went back into the NetSimple settings for the WebServer procedure and changes the 'Change Session on Log In/Out' flag on ON and the session value stopped working again.  I went straight back in and turned them OFF again (no other changes), and the session value STILL wouldn't work.  Shut everything down, came back later and restarted and it worked again.

It seems that the changes being made in the settings area are perhaps being cached or not re-read correctly until the whole project (and Clarion) is restarted?


And thank Mark, yeah, I knew about the session value not being a LONG any more.  I don't actually store it anywhere myself, just inspecting it via p_web.SessionID when I noticed that my session variables were being reset in between pages.

Bruce, I tested in about 3 browsers here (IE, Chrome and Firefox).  Similar results in all.  The log of the headers show the cookie, but with a null value:

Code: [Select]

GET /EntryPage HTTP/1.1
Host: localhost:88
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.97 Safari/537.22
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: SESSIONID=null
Bit of a mystery, and hit and miss as to whether the session ID gets generated or not...

[Bruce]

ok, so you are getting the cookie - it just has the strange value "null".
Either the server is setting it to null, or the browser is setting it to null, or maybe something in-between the browser and server is setting it to null.

If I had to guess 'd say it's some sort of cookie blocker type thing on the browser itself. ie some sort of browser plugin or extension - but that's just a guess. It might also be a firewall, or router, or proxy, in-between that's stripping the cookies off.

first test;
in your project defines set
NetShowSend=>1
Then you can see the _outgoing_ packets in debugview.
See what the session cookie is being set to there.

second test - have a look at the incoming request in Firebug, and see what the cookie is being set to there.

cheers
Bruce

[Devan]

Thanks for the suggestions Bruce,

I have been doing some other research since my last reply above.

I found that if I added the line:

p_web.DeleteCookie('SESSIONID')

in my logout procedure, then things seemed to work MUCH better.  I am thinking that perhaps an old, invalid cookie still hangs around causing the issues that we see here.  As for what was setting it to 'null', I have no idea.  There is no routine in NetTalk that sets the cookie to null?

In any case, after this change above, I got a couple of users to test by forcing a logout and re logging back in and it SEEMS to be working OK at present...

Thanks for all your help.

Devan

[Bruce]

>> I found that if I added the line:

I suspect that is a red-herring. I think something completely differnent is in play here.

>> As for what was setting it to 'null', I have no idea.  There is no routine in NetTalk that sets the cookie to null?

it's actually the word "null" and I'm pretty sure there's nothing in NetTalk that comes even close to that.

cheers
Bruce