Unique id for browser session?

Is there some kind of unique id for a browser session? e.g., I have two
browser windows open, pointing to same web page on server. How can the
server identify the difference between the two? I tried using cfid but
unfortunately it is the same between the two browser windows (prob because
it’s a cookie).

I need to differentiate because I need the same server messages to go from
server to both browser windows. I have the server store the messages
already sent to client in a session variable (currently based on clientid).

Thanks.

No one has any thoughts on this? :(On Friday, April 17, 2015 at 9:30:15 PM UTC+2, Cage Sarin wrote:

Is there some kind of unique id for a browser session? e.g., I have two
browser windows open, pointing to same web page on server. How can the
server identify the difference between the two? I tried using cfid but
unfortunately it is the same between the two browser windows (prob because
it’s a cookie).

I need to differentiate because I need the same server messages to go from
server to both browser windows. I have the server store the messages
already sent to client in a session variable (currently based on clientid).

Thanks.

setclientcookies=false?On Apr 18, 2015 8:49 AM, “Cage Sarin” <@Cage_Sarin> wrote:

No one has any thoughts on this? :frowning:

On Friday, April 17, 2015 at 9:30:15 PM UTC+2, Cage Sarin wrote:

Is there some kind of unique id for a browser session? e.g., I have two
browser windows open, pointing to same web page on server. How can the
server identify the difference between the two? I tried using cfid but
unfortunately it is the same between the two browser windows (prob because
it’s a cookie).

I need to differentiate because I need the same server messages to go
from server to both browser windows. I have the server store the messages
already sent to client in a session variable (currently based on clientid).

Thanks.


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/74db66f1-e4c4-4960-adc4-e6b94733b61f%40googlegroups.com
https://groups.google.com/d/msgid/lucee/74db66f1-e4c4-4960-adc4-e6b94733b61f%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

No one has any thoughts on this? :frowning:

It is the weekend.

But in short: no. Browser tabs don’t intrinsically identify themselves
discretely.

If you want to do that you need to roll your own solution. This is kinda
“out of scope” for this forum as its a browser issue, and the CFML server
doesn’t itself interact with the browser (or know anything about “browsers”
or “browser tabs” and the like). I’m sure if you googled your question
you’ll come up with some well-informed solution (which is what I’d do in
this situation in the first instance), but I’d = and this is me so it’s
not well informed! - probably start by looking at getting JS on the
client to set some sort of request-specific header (or something? something
not session-based or shared between browser tabs like cookies) which the
server then uses to cross reference back to a subkey in the session scope
or something. But that is just giving it 1min thought. Which is not how I’d
approach the solution to this: I’d google first.On Saturday, 18 April 2015 13:49:39 UTC+1, Cage Sarin wrote:


Adam

Your mention of sending messages “from server to both browser windows”
prompts me to +1 Seth’s reply to use Pusher. To follow your “unique id”
path, you could create that in Javascript in each browser window/tab and
pass that to any requests to your server to identify to the server which
window/tab of the common browser session made the request.

Paul

Is there some kind of unique id for a browser session?

Yes, the session ID cookie identifies the session.

e.g., I have two browser windows open, pointing to same web page on
server. How can the server identify the difference between the two?

Not, there is no window ID or tab ID.

I need to differentiate because I need the same server messages to go from

server to both browser windows.

Are you sure that is the requirement? If it is, you don’t need to
differentiate. Just use a websocket to send it to all windows.

But I would guess your actual requirement isn’t that you need to send it to
both windows, but that you need to show the message in both windows? And
do you mean both windows or all windows? Because if that is the case I
would send it with whichever request comes in first, store it to the
browser local storage and make the rendering work from local storage
instead of from the server message.

JochemOn Fri, Apr 17, 2015 at 9:30 PM, Cage Sarin wrote:


Jochem van Dieten
http://jochem.vandieten.net/

I thought your intention was to have a separate session for each window, in
which case turning off cookies would accomplish that.

If you are looking to send the same message to different windows
simultaneously take a look at Pusher. It’s a very easy way to do that.

SethOn Apr 19, 2015 3:45 AM, “Jochem van Dieten” <@Jochem_van_Dieten> wrote:

On Fri, Apr 17, 2015 at 9:30 PM, Cage Sarin wrote:

Is there some kind of unique id for a browser session?

Yes, the session ID cookie identifies the session.

e.g., I have two browser windows open, pointing to same web page on
server. How can the server identify the difference between the two?

Not, there is no window ID or tab ID.

I need to differentiate because I need the same server messages to go from

server to both browser windows.

Are you sure that is the requirement? If it is, you don’t need to
differentiate. Just use a websocket to send it to all windows.

But I would guess your actual requirement isn’t that you need to send it
to both windows, but that you need to show the message in both windows?
And do you mean both windows or all windows? Because if that is the case
I would send it with whichever request comes in first, store it to the
browser local storage and make the rendering work from local storage
instead of from the server message.

Jochem


Jochem van Dieten
http://jochem.vandieten.net/


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CABPCP-1xNbx3%3DerAjBpWiuhS5KPgGdxA992cCHsj5ome1Z6aUA%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CABPCP-1xNbx3%3DerAjBpWiuhS5KPgGdxA992cCHsj5ome1Z6aUA%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

Thanks to all for your suggestions. I had similar code in ACF and it
appeared that the messages were being sent to all the browser windows using
cfid. But I guess that wasn’t exactly true when I went back to test again.
Based on my false recall, I thought there might have been a different in
implementation between ACF and Lucee, hence my question here.

Unfortunately, I can’t use Pusher or other similar systems as the app
contains sensitive data that clients would not want leaving the confines of
the firewall.

I’ve implemented code to account for above - thanks again for people’s
help.

Ciao,
CageOn Sunday, April 19, 2015 at 7:01:11 PM UTC+2, Paul Cormier wrote:

Your mention of sending messages “from server to both browser windows”
prompts me to +1 Seth’s reply to use Pusher. To follow your “unique id”
path, you could create that in Javascript in each browser window/tab and
pass that to any requests to your server to identify to the server which
window/tab of the common browser session made the request.

Paul

@cage:

You can still use pusher or some other service with sensitive data. Instead
of pushing the data directly, let a notification by pusher trigger a server
call to get the data. That way you’re in control what goes over the line
and data can stay within the firewalls ( and make it cheaper than pushing
large chunks of data through pusher).

Hope that helps,

MichaelOn Monday, April 20, 2015, Cage Sarin <@Cage_Sarin> wrote:

Thanks to all for your suggestions. I had similar code in ACF and it
appeared that the messages were being sent to all the browser windows using
cfid. But I guess that wasn’t exactly true when I went back to test again.
Based on my false recall, I thought there might have been a different in
implementation between ACF and Lucee, hence my question here.

Unfortunately, I can’t use Pusher or other similar systems as the app
contains sensitive data that clients would not want leaving the confines of
the firewall.

I’ve implemented code to account for above - thanks again for people’s
help.

Ciao,
Cage

On Sunday, April 19, 2015 at 7:01:11 PM UTC+2, Paul Cormier wrote:

Your mention of sending messages “from server to both browser windows”
prompts me to +1 Seth’s reply to use Pusher. To follow your “unique id”
path, you could create that in Javascript in each browser window/tab and
pass that to any requests to your server to identify to the server which
window/tab of the common browser session made the request.

Paul


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/a338dc7a-0d80-4591-bcba-a32d02368159%40googlegroups.com
https://groups.google.com/d/msgid/lucee/a338dc7a-0d80-4591-bcba-a32d02368159%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.


Sent from Gmail Mobile

Good point. Thank you Michael. Cage>