I'm going to guess that you're dropping sessions because your HTTP cookies aren't secure, and your HTTPS cookies are, issuing a new identity to the browser every time it switches back & forth. Putting your entire site in SSL mode is not a bad way to go, a lot of sites are doing that these days, but I understand not wanting to go that way if you can help it.
>From the way you described it, it seems like the easy way may be to give your less-secure application side its own application name and cookie domain and path, then when you go secure, you get a new cfapplication name, and new cookies for the domain and path. If they hit the insecure site it wouldn't matter because the cookies can't collide. That may or may not work depending on how the application is laid out. Still though, I think I've done things like this and I don't remember having this problem. It was a lot of years ago though. You know, back when security was job #2 (or 3...)! Actually I wonder if somewhere in your code you are issuing new cookies on HTTPS that are secure, and those wouldn't be readable from plain HTTP. It's a possible security hole (http interception, man-in-the-middle - not likely but possible) to keep your cookies insecure, but it would probably fix it. If you insist on keeping it all tight together, you might be able to pass your HTTPS sessionid over a URL link to the insecure site after the user is authenticated. That way they should have the same exact session. Again, you're passing HTTPS cookies over HTTP, so consider if this risk is ok for you. nathan strutz [www.dopefly.com] [hi.im/nathanstrutz] [about.me/nathanstrutz] On Tue, May 15, 2012 at 11:43 AM, Nick Gleason <[email protected]>wrote: > > Hi folks, > > > > With our CMS / CRM application, we are looking at moving from a reliance on > client variables towards more reliance on session variables, including as > it > relates to logins. One challenging scenario happens when a client is using > SSL for ecommerce transactions. If a user logs in, using session variables > for persistence, then goes to a page that is not in https and then goes to > a > page (e.g. an ecommerce screen) that uses https, sessions are dumped when > the site goes into https and the login can be lost. > > > > We are probably going to solve that problem by just requiring the whole > site > to go into https. However, I wanted to know if there are other good ways > to > solve this. > > > > We have solved that kind of problem in a related scenario (with attribute > scoped variables that need to survive https) by using wddx to store > variables in the client scope and then get them back from there after > moving > into https. That has worked pretty well, but feels a bit complex. > > > > As we look at expanding our use of sessions, it seems like a good time to > look at other options. So, are there other or better ways to keep session > variables alive when a logged in user goes to an https encrypted page? > > > > Thanks in advance, > > > > Nick > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:351175 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
