Adam/Purdue, it doesn’t matter whether you make the request via https, if you’re simply wanting to see what sort of headers the cfml page returns.
The secure attribute for a cookie does indeed control whether that cookie would be RETURNED to a server in a subsequent request (and only if that request is made via https), but I’m not aware of any limitation by which the page that SETS the cookie needs to be called via https. (There may be, but again I am not aware of it nor would I expect it.)
So that’s why I proposed you run the test that I suggested. Have you tried it?
And I am assuming you are judging results not be what the browser dev tools shows for its display of what cookies are IN the browser (via the application tab in most browsers), but instead you should be looking at the network tab to see what RESPONSE HEADERS are being generated by the specific page you request. You may discover interesting things if you watch that.
And if you may well be already doing that, great. Let us know how it goes testing a page via the built-in web server, again as much for diagnostic purposes.
Finally, to be clear, I have not myself been testing anything as I’ve share my responses. I’ve always been seeing thesd on my phone this weekend, and I’ve just been chiming in where I thought I might offer helpful perspective.
Thanks again. Hate to be a broken record - but you guys are SO helpful. I can’t thank you enough.
So that’s why I proposed you run the test that I suggested. Have you tried it?
For sure. I loaded web pages from the :8888 port as you suggested (which I believe is coming straight from Tomcat). Saw the same exact results. In our configuration, the default path you mentioned above “Lucee webapps/ROOT folder” is not in use. We set a different path in the Tomcat conf files. At any rate, wanted you to know I ran the test. Here is what I saw:
On your other point, about looking at the “Network” tab of Chrome developer tools. Great suggestion! Thank you! I did that.
Here is the output from outside the firewall - running through Apache:
Here is the data from inside the DMZ network, calling directly to Tomcat via Port 8888:
If I’m reading this correctly (and there is a high probability I’m not 
— it seems that Tomcat is not setting the secure flag for the CFID and CFTOKEN cookies despite my settings in Application.cfm. Your test helped isolate this to a Tomcat issue, correct?
The only other real difference I can see between the Tomcat and Apache output is that the Tomcat call includes a JSESSIONID… Is this problem stemming from the fact that I’m running SESSION TYPE = APPLICATION under SCOPE in the Lucee Admin? Do you guys run that Session Type?
So grateful for this community. Thanks a million!
From seeing your direct Tomcat requests at port 8888 I can see that the flags are not being set. Looks like your directive sessioncookie is being ignored somehow.
Now I just saw that you set:
Still, I’m not at home to test… but: You’ve defined cf_ssn_cookies as a struct, but then afterwards you assign it as a string with:
sessioncookie="#cf_ssn_cookies#"
That would be a string, not a struct:
sessioncookie="{httponly=‘true’, secure=‘true’}"
I really don’t now if Lucee would identify that string above as a struct and cast it as a struct. Instead it should be sessioncookie={httponly=‘true’, secure=‘true’} (without the doublequotes).
What happens if you assign it like so:
sessioncookie=cf_ssn_cookies ?
Or even directly:
sessioncookie={httponly=‘true’, secure=‘true’}
You could also try setting it as bracket notarion like so:
sessionCookie[“secure”] = true
SessionCookie[“httpOnly”] = true
Would like to know what happens. I’d test it directly if I had my notebook with me, but I’m just with my mobile right now 
sessioncookie="{httponly=‘true’, secure=‘true’}"
sessioncookie="{httponly=‘true’, secure=‘true’}
No quotes at all:
Your other idea:
None seem to work. Bummer 
What cookies does the lucee admin set?
With our session type = Application, it looks like CFID and CFTOKEN…
sorry, i meant is the admin setting both secure and httponly (i.e the subject of this thread)
Hi Zack!
In a nutshell - the fine people of this forum gave me code to add to CFAPPLICATION - with the hopes that it would set both flags.
Unfortunately, only the httponly flag is being set. We can’t get the “Secure” flag to set.
The only way I’ve found to do it (and I’m about 8 hours into this issue at this point) is to add code to the Apache http.conf to force the flag in the set-cookie header… This allows my PCI Compliance scan to pass…
HOWEVER - Folks in this community have warned against this solution saying it has caused them issues. Any ideas? I’m stumped. The testing against port 8888 shows the Secure flag is NOT being set by Tomcat…
there’s absolutely nothing wrong with doing it in Apache
the old <cfapplication> style might be the problem, I know it works with Application.cfc
1 Like
Thanks Zackster… Glad to hear you have confidence in the Apache approach. We will, of course, do thorough regression testing before pushing this to production…
the old <cfapplication> style might be the problem
I was thinking that too based on my research until a few people chimed-in and said it was working for them.
I will see if I can answer that empirically with a simple Application.cfc test.
another workaround that might help: I remember just setting the flags with cfcookie in the past for a legacy app with application.cfm with cfcookie somewhere after the cfapplication tag like so:
<cfcookie name="CFID" value="#SESSION.CFID#" httpOnly="true" secure="true">
<cfcookie name="CFTOKEN" value="#SESSION.CFTOKEN#" httpOnly="true" secure="true">
That worked in that environment, I don’t know if it would work for you or if it might break something else. But better would be to rewrite your application.cfm to Application.cfc.
Thanks for all the help everyone. For now, we are going to run with the update to the Apache http.conf file.
For future reference, here is the line we added to httpd conf:
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
After a restart of httpd, the secure flag is present on the cookie.
We will report back if there are any issues.
