Copy link to clipboard
Copied
We've been having a problem with session loss when using J2EE session management in CF, ever since we upgraded to version 10. It appears as though CF is doing the following:
1. If the session begins over http, the cookie is set as secure=no
2. If the session begins over https, the cookie is set as secure=yes
This is a problem, because if #2 happens, and a user then transfers to an http page, they will lose their session (because the browser can no longer read the secure cookie). At that point, they get handed a new, non-secure cookie and they have to start their session over again.
We've searched around but are unable to find any way to change this behavior. Is there something we're missing? How do we get it to stop automatically setting secure cookies?
@Smurf, I realize this is a 3-week old thread, but did you ever resolve your problem?
I had tried to offer this reply then, but I see now I had a mail server failure (yep, I read and reply to these forums via email), so it was never delivered.
If still unresolved, what I had asked was: So are you talking only about the session cookies CF creates and uses (like CFID/CFTOKEN, or in your case, Jsessionid)? Or do you mean cookies you set? (And are these related to you using CFCOOKIE or CFHEADER?)
Assum
...Copy link to clipboard
Copied
No one?
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Forgive me, but I'm not sure how that link was supposed to help me. I understand how cookies work, and I understand the various settings for cookies. That article seemed like nothing so much as a primer. If however, you were asking me what CFAdministrator settings I have set, I can tell you that the httpOnly box is checked, and the secure box is unchecked.
My website serves up both https and http pages, and needs to be able to hold its session across protocols. For clarity, I'll quote my problem:
ColdFusionSmurf wrote:
This is a problem, because if #2 happens, and a user then transfers to an http page, they will lose their session (because the browser can no longer read the secure cookie). At that point, they get handed a new, non-secure cookie and they have to start their session over again.
This is changed functionality in CF10. In CF9, cookies did NOT get automatically set with secure=yes just because the user started on an https connection. I need to know how to fix this behavior.
Copy link to clipboard
Copied
@Smurf, I realize this is a 3-week old thread, but did you ever resolve your problem?
I had tried to offer this reply then, but I see now I had a mail server failure (yep, I read and reply to these forums via email), so it was never delivered.
If still unresolved, what I had asked was: So are you talking only about the session cookies CF creates and uses (like CFID/CFTOKEN, or in your case, Jsessionid)? Or do you mean cookies you set? (And are these related to you using CFCOOKIE or CFHEADER?)
Assuming it’s just about the first point above, have you seen this discussion:
http://www.petefreitag.com/item/817.cfm
See also the many comments, including from Shilpi (at Adobe), myself, and others.
/charlie
Copy link to clipboard
Copied
Charlie,
Thanks for the link. It was a surprisingly concise explanation of the issue and helpful in general. I wish we had seen that article weeks ago, event though it didn't really tell us anything new. Sometimes just having somebody confirm the issue so you prove to yourself you're not alone is help enough. To answer your questions....
I was talking about the JSESSIONID cookie that gets set automatically by Coldfusion through its internal session management process. Cookies we set ourselves were unaffected. Really, this was exactly the issue that Pete outlines, and the fact that its hard-coded in Tomcat makes a lot of sense as to why we couldn't fix it.
Yes, we still have the issue. We eventually figured out the header rewrite work-around that Pete suggests, but we really didn't like that idea so we decided against it. In the end, we gave up on J2EE cookies altogether and went back to CFID/CFTOKEN cookies, which does not exhibit the problem.