Coldfusion sessions - how exactly is CF identifying a connection / unique client
After doing some digging with remote CFCs I called from Word VBA I found they set sessions also. Which got me to thinking and Googling (unsuccessfully) for an explanation of just how CF does distinguish between different clients. I had previously assumed it was a browser cookie being set to identify the client, but then here I was consuming a web service through a word app and still getting the session variables and sessionID set.
So if I load and login to my app via browser (chrome) and hit a test page I get jsessionID = 123,If I fire up firefox and login I get a different jsessionid = 234 as expected. If I hit a remote cfc as a web service wsdl using Word VBA I can see jsessionid=345 returned to the VBA module. If I close Word and reopen my macro (containing a login request to the web service) I get a new jsessionID=567
So what is it about the request that CF is identifying and how does it persist the identification of the client?
This is the same issue in a VBA http call
Sub doHTTP()
Dim MyRequest As Object
Dim Val
httpString = "http://localhost:8888/test.cfm"
Set MyRequest = CreateObject("WinHttp.WinHttpRequest.5.1")
MyRequest.Open "GET", httpString
' Send Request.
MyRequest.Send
MsgBox MyRequest.ResponseText
'now pass in the session urltoken we have just retreived
MyRequest.Open "GET", httpString & "?urltoken=" & MyRequest.ResponseText
' resend a request, this time with the urltoken.
MyRequest.Send
'take a look and see if the session variables are correct
MsgBox MyRequest.ResponseText
End Sub
in a test.cfm
<cfif isdefined("URL.urltoken")>
<cfset session.urltoken="#URL.urltoken#">
<cfelse>
<cfset session.username="bob">
</cfif>
<cfoutput>session.urltoken="#session.urltoken#"</cfoutput><br>
<cfoutput>session.username="#session.username#"</cfoutput><br>
<cfoutput>session.sessionID="#session.sessionID#"</cfoutput>
OK that now works, interesting, I will need to remember for web service or http calls not using a browser I will need to pass the sessionID in the URL manually.
Definitely session maintained based on browser cookie. On first request from browser server assign token and this will used to make session connection in rest of the request. If browser cookies are disabled then you may need it pass CFID and CFTOKEN in URL for every request and in case of j2ee session management you may need to pass jsessionId as well (best way is to append session.URLToken in every request.)
In word macro you get new jsessionId because word may not have cookie and not able to persist connection but just try to concat session.URLToken in next Webservice call and you will get all your session back even after reopening word or even you can try copy session.URLToken from chrome browser request and append it in firefox request and you will get same session available in Chrome (same thing will work if you trying from different computer as well).
So moral of story is combination of CFID,CFTOKEN,JSessionId(in case of J2ee session management) use for connection between client and server either through URL or Cookie.
Related
I am sending a websocket connection to the API server on a different host:
new WebSocket("ws://localhost:3000")
Whereas my front end is hosted on localhost:8080.
Inside my API's websocket connection handler I'm able to set a key on the session (with Sinatra's enable :sessions) but every time I refresh the html page, the data is lost.
Is there some requirement for sessions that the front end share the same host as the server? Or is there some way I can get around this? By the way, the front end is running on a Webpack server (Node).
I also tried adding a cross_origin allowance for the API's root route http://localhost:3000 and then doing this in the client (this example in coffeescript):
$.get "http://localhost:3000", ->
new Websocket("ws://localhost:3000")
My thinking was that maybe the session needed to be "initialized" over http:// instead of ws:// but it didn't work either. The session didn't work for the $.get "http://localhost:3000" request either. Refreshing the page shows that the session clears each time.
As we've discussed in comments, you probably have a problem with 3rd party session cookies in the browser.
Here's a scheme that you could use to work around it.
Client makes webSocket connection for the first time.
Server sends a webSocket message back with sessionID in it.
Client stores sessionID in a first party cookie (e.g. a cookie in the host web page).
User hits refresh.
Web page checks to see if it has a webSocket session cookie in the cookies for the host page. If so, it constructs a URL for the webSocket connection that includes that session ID `new Websocket("ws://localhost:3000?session=xyslkfas")
When server accepts webSocket connection, it checks the query parameters to see if there is already a session being specified. If so and that session is still valid, it hooks up that connection to that session. If not, it creates a new session and goes back to step 2.
I am trying (for days) to make this work: I want to connect to a Media Servers using RTMPT netConnection. In order to reach that, I have to pass an authentication cookie along with my request. In Chrome and IE it works, but in Firefox it doesen't pass the auth_cookie.
When I look into logs I see the /open/1 request, but it has no cookie atached. Againg: in Chrome and IE it uses the cookie. The cookie doesn't have the HttpOnly flag.
Another weird scenario that I encountered is: Because it dosen't pass the cookie, the ApplicationServer wich holds the autentication, asks me for credentials. If I enter them it takes the cookie and works, and any subsequent connections work (firefox passes the auth_cookie along the /open/1 request); but if I delete all the cookies in browser (via CookieController-> Remove ALL cookies and DOM storage) the credentials are requested again (no cookie is passed).
Any sugestions? I've searched all the internet for a solution but I can't find anything...
I have very simple question with request and session in web. When I requested a same page page for multiple time from same browser with different tabs or through new window, session ID and session creation time was same.
This I have done from internet explorer. But when in use a different browser like google chrome and access the same page then different session id and session creation time was there. As far as my understanding says http request is stateless.
So, in my case it does not seem to be stateless within same browser as for different http request new thread is created by creating new servlet by container. So I have come to following conclusion:
If request is send from same browser with different tabs opened or through another new window at that time, the request always use the same thread for servlet operation with same session Id. If request is send from different browser then new http request is sent with new session ID.So,my question is then when it is stateless? If the request is send concurrently from different browser? If i declare scope="request"> and scope="session"> in spring then it also follows the same case ? If I am wrong in my understanding please correct me.
Spring
scope="request"
Creates new instance of bean per request.
scope="session"
Creates new instance of bean per session.And maintains instance of bean throughout the session life-cycle
Refer this for better understanding
Irrespective of browsers, Http protocol is stateless. State-fullness is implemented via cookies and session.
When request is sent from the browser, servers creates session and sends back a unique id to the client. And the client uses this id(Cookie) in subsequent request so that server could identify request and associate it with the session.
As far as requests are concerned, server creates separate thread to handle each request irrespective of window, tab or browser. However there will be only one session created per browser.
Note: Latest browsers share the session and the request made from tab, or new window will use the same session. Ex latest IE releases IE7, IE8 and IE9 are well know as Loosely-Coupled IE (LCIE). check this for more details LCIE
When your server application starts a new session, the servlet container sends a Set-Cookie header with a JSESSIONID back to the browser. The browser saves that cookie, and sends it back to the server with each request regardless of what tab you are making the request from. Obvoiusly other browsers don't have access to that cookie, so they will receive another one from the server.
When your server receives a request with a JSESSIONID cookie, it can correlate that request with requests with the same id made earlier. The serlvet container is able to associate different attributes with that id, and persist these attributes between requests. The http session object is basically a container for these attributes, to which your server application has a read/write access. Basically this is how statefullness is implemented with http sessions on top of the otherwise stateless http protocol.
As for the threads: each request can be processed by any random thread, because the session data is not bound to a particular thread. It is the servlet container that maintains the mapping from session id to the session object containing the different attributes. Consequently any random thread can access the session object belonging to the current request based on its session id.
In Spring, request scope means that a bean instance gets newly created for each request, while the lifecycle of the session scoped beans is bound to that of the http session.
I am interested to see what people are storing in my session and cookies when I visit websites. Is there any way to see what's in there between request and when I'm on pages in Safari, Chrome, or Firefox?
In Firefox you can use among others Firebug to check the cookies being sent forth and back. Check the Net panel for complete request and response headers. The cookies are present as Set-Cookie response header whenever the session starts and as Cookie request header on all subsequent requests in the same session.
Here's a screenshot of the transferred headers when requesting this topic:
(note that I removed the user cookie value from the screenshot, else someone else would be able to copy it and login as myself)
You cannot check in the client side in any way what's been stored in the server side session since that's usually not exposed in the cookie values. Only the session identifier is stored as cookie value. You can at highest make some guesses based on the behaviour of the website across the requests.
I have developed a simple web-app with 2 servlets A and B.
I have a few doubts related to session management for the web-app by Tomcat.
NOTE - I have disabled cookies in my web-browser (Chrome) while accessing the web-app.
1.) When the web-app is first hit, Servlet A gets invoked. Servlet A accesses the session from the request and does a simple sysout of the session hashcode. It then does a sendRedirect to servlet B.
[According to my understanding, since this is the first request, Tomcat will send a cookie containing the new session ID back to the browser. However, since we have not "encoded" the redirect URL using HttpResponse.encodeRedirectURL(), the redirect URL will not contain the session ID appended to it. Please correct me if I am wrong here.]
2.) Since cookies are disabled in my browser, it'll ignore the session ID sent back in the cookie and issue a new request to the redirect URL (which also does not have the session ID appended to it).
3.) The new request causes servlet B to be invoked, whoch also accesses the request session and does a sysout of the session hashcode.
What perplexes me is that both Servlets A and B output the same session hashcode, which means that they get the same session from both requests.
How does the second request from the browser map to the same session as before, even though no session ID has been sent ?
Thanks !
There are only 2 ways to pass sessions between requests: Cookie and URL rewrite. If you don't see the session ID in the URL, it must be cookies.
Are you sure the cookie is disabled? It should be easy to see from a HTTP header trace.
Are you certain you've disabled "in memory" cookies? Often browsers will let you disable persistent cookies which are saved to disk, but they'll still allow the transient in memory cookies which only stay resident during a browser session.
I recommend Wireshark for analyzing the HTTP stream. That way you can see the cookies that are sent and received by your browser.
This is strange.
When I tested the application yesterday, it was exhibiting a behaviour similar to what I have described. However, as I test the application now, it behaves perfectly, as I expect it to.
The cause could probably be that I did not restart my browser session after disabling cookies.
Will let you guys know if I experience the same behaviour again.
Thanks for your time guys !