http://coldfusion.com logo
Join Slack
Powered by
Need help understanding how session works in eithe...
# cfml-general
d
Need help understanding how session works in either cfengine.
On step 1 myservice.com creates a new session and saves {sessionid,userid, state} for user 313 and lets say the sessionid ends with B456. On step 6 I expect myservice.com to have the same sessionid, but instead a new session is created that ends with X111. How can myservice.com persist the session? Application.cfc {sessionmanagement=true, sessiontimeout=30mins}
Or what other way can I persist state without using a database?
message has been deleted
p
Do you have some sample code your referring to, this is is exactly how session management works.
d
I can whip some up. But all I'd be showing is how in the first request I'm doing 
session.userid = userid
and in subsequent requests I'm simply checking to see what the userid is.
Wait…myservice.com is a coldbox app. And I believe I need to whip some code so you can how I'm using handlers and models in these requests.
a
Hi, Do make sure the setClientCookies is set to true in Application.cfc and in the browser is enabled for cookie storing.
p
Ahhh, yea are you actaully talkign ajac or is this 2 servicee calling each other over http
cfhttp wont be sending the cookie which is needed for the session
d
Yes client cookies is set to true but it's Ajax calls.
a
So once the user has be authenticated and session has been created and the response has been sent back do you see cfid & cftoken in the developer tools's application section?
Also do check out what Paul suggested. Is the set cookie being returned back from the http call with cfid & cftoken cookies.
Also if it's web service then better to stick to jwt instead of the session as web service would be a stateless affair.
🤔 1
d
Ok I'll try passing cfid/cftoken back and forth.
Web service, stateless affair and jwt - I'm listening. It is a web service and every other type of request is stateless. But im not using jwt yet. Oh boy!
a
So to help you understand it better, when a session is created it sends back cfid & cftoken cookies to the client(browser) which is then saved in that browser and is automatically added in every request. So when the cf sees the same cookies it recognises the client and sends back response otherwise it creates new cfid & cftoken cookies. The cfid & cftoken cookies help in recognising the client.
👍🏾 1
d
These new requests do need some state. Me thinks now I should move it to my main app.
p
This is when cfsessions start to hurt themselfs, and why people move to jwt
Quick and easy for apps that don't cross domains.
👍 1
👍🏾 1
a
technically if you send the cfid & cftoken back & forth then that can replicate to maintain session but I guess it's more work to just maintain a state of a stateless nature.
👍🏾 1
d
Thanks fellas. I'll try asiahd suggestion but ultimately I believe I have to rethink this design.
a
Daniel, do mind that sending the same session all the time would be a security flaw. Do take that into consideration as well.
✅ 1
d
explain
I don't know what you mean by "sending session all the time"
a
That would be cfid & cftoken to be precise.
d
oh right
a
Sending the same values all the time without would make the app vulnerable to session hijacking and for that reason we have sessionrotate & sessioninvalidate(if using jsession)
✅ 1
If it would be a stateful application then it would have been fine to just rotate the session after successful login. However in the stateless case you are not sure of where the request might come from.
✅ 1
4 Views
Open in Slack
PreviousNext
Powered by