search

isapir / lucee-websocket

Enables server WebSockets for Lucee via JSR-356 compliant servlet containers (e.g. Tomcat 8, Jetty 9.1, etc.)
GNU Lesser General Public License v2.1
17 stars 6 forks source link

Unable to reliably get correct session/application scopes in Listener Components #3

Closed redtopia closed 6 years ago

redtopia commented 7 years ago

I cannot reliably setup my Lucee environment so that the correct sessionScope/applicationScope arguments are passed into my Listener Component methods. I am running Windows 7, and accessing Lucee directly through port 8888.

I am also running multiple apps defined as a separate Host elements in my tomcat/conf/server.xml file. Here's an example:

<Host name="local.app1.com" appBase="webapps">
    <Context path="" docBase="C:\Dev\app1\" />
</Host>

<Host name="local.app2.com" appBase="webapps">
    <Context path="" docBase="C:\Dev\app2\" />
</Host>

I define these hosts in my Windows hosts file: C:\Windows\System32\drivers\etc\hosts as:

127.0.0.1 local.app1.com
127.0.0.1 local.app2.com

And I browse to my apps by going to: http://local.app1.com:8888/

The behavior I'm experiencing is that I can only get one app to work correctly at a time. In other words, no matter how many apps I try to run that use the websockets extension, only one will receive the correct applicationScope/sessionScope arguments in my listeners.

I'm also noticing that one app (let's call this app1) will always work when defined anywhere in my server.xml file. In order to get another app to work, I have to remove app1 (comment it out). My method to getting an app to work is by editing the server.xml file, though I honestly don't know what I'm doing that will make it work. As a last ditch effort, I'll remove all apps except the one I'm working on.

A clue could be that when I get an app to work correctly, log entries are written to the app's log folder (\WEB-INF\lucee\logs). But when it's not working, it will write log entries to another app's log folder. This tells me that the current context of the websocket extension is relevant to solving this issue.

dklmuc commented 7 years ago

Same problem here...

Local Environment: Windows 10 Lucee 5.2.1.9 Websocket Extension 1.1.3.1 Sites running under local domains defined in hosts (to 127.0.01)

When running more than one single context in server.xml I got this result for a session dump (stUser is a key added by the site):

{
    "cfid": "574fd54a-7371-4849-9e21-38706e8891a9",
    "timecreated": "May, 03 2017 17:22:56 +0200",
    "sessionid": "projectwww_574fd54a-7371-4849-9e21-38706e8891a9_0",
    "urltoken": "CFID=574fd54a-7371-4849-9e21-38706e8891a9&CFTOKEN=0",
    "lastvisit": "May, 03 2017 17:23:05 +0200",
    "cftoken": "0",
    "stUser": { ... }
}

Session echoed by Websocket Extension in onMessage():

{
    "cfid": "574fd54a-7371-4849-9e21-38706e8891a9",
    "timecreated": "May, 03 2017 17:23:08 +0200",
    "sessionid": "projectwww_574fd54a-7371-4849-9e21-38706e8891a9_0",
    "urltoken": "CFID=574fd54a-7371-4849-9e21-38706e8891a9&CFTOKEN=0",
    "lastvisit": "May, 03 2017 17:34:00 +0200",
    "cftoken": "0"
}

=> Same session ID, but different create time and the stUser Key is missing.

When I disable all other contexts in server.xml, e.g. running the application as the default host, then I get the same session as cfdump and in the websocket echo and all is running fine.

Small repro script: chat.zip

dklmuc commented 7 years ago

And to make it real confusing, using some live enivornment: Debian 8 Lucee 5.2.1.9 (running behind Apache2, websocket connections are proxied to Tomcat) Websocket Extension 1.1.3.1

It's running two contexts (different projects under different subdomains).

cfdump of the session:

{
    "cfid": "42ab21ed-2e1a-41f5-891f-d56fbc392c33"
    "cftoken": "0"
    **"customkey": "June, 09 2017 15:57:48 +0200"**
    "lastvisit": "June, 09 2017 16:03:20 +0200"
    "sessionid": "acr_event_42ab21ed-2e1a-41f5-891f-d56fbc392c33_0"
    "timecreated": "June, 09 2017 16:03:20 +0200"
    "urltoken": "CFID=42ab21ed-2e1a-41f5-891f-d56fbc392c33&CFTOKEN=0"
}

echo of the websocket:

{
    "cfid": "42ab21ed-2e1a-41f5-891f-d56fbc392c33"
    "cftoken": "0"
    **"customkey": "June, 09 2017 15:57:48 +0200"**
    "lastvisit": "June, 09 2017 16:06:02 +0200"
    "sessionid": "acr_event_42ab21ed-2e1a-41f5-891f-d56fbc392c33_0"
    "timecreated": "June, 09 2017 16:03:20 +0200"
    "urltoken": "CFID=42ab21ed-2e1a-41f5-891f-d56fbc392c33&CFTOKEN=0"
}

=> Same session ID, same create time and my custom key is there with th right value

redtopia commented 7 years ago

I noticed the behavior where, from within my websocket connection, cfid and sessionid are the same as the client's session, but my custom session properties are missing.

dklmuc commented 7 years ago

Maybe a linux/windows difference? Couldn't imagine it's something because of local domains vs. real domains.

isapir commented 7 years ago

@redtopia is it possible that the session expired? default timeout is 20 minutes, which Application Name do you see if you log #arguments.applicationScope.ApplicationName# from within the listener's event handler? is it the correct Application?

redtopia commented 7 years ago

@isapir, I'll have to dig into this again and setup my environment so it doesn't see the correct session. I'll report back when I have some time to test it out.

isapir commented 7 years ago

Does the issue happen when multiple Hosts utilize WebSockets or only a single Host uses WebSockets but the other Hosts are regular Lucee applications?

redtopia commented 7 years ago

I've never gotten more than one host to work at one time.

isapir commented 7 years ago

It looks like a bug in the Lucee core. I opened a ticket at https://luceeserver.atlassian.net/browse/LDEV-1369

dklmuc commented 7 years ago

Nice finding, thx for looking after the problem.

isapir commented 6 years ago

Fixed for 2.0.1 -- please see README.md for update on installation etc.