best practice on session variable persistence and ssl?

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

As you would be aware going from non SSL to SSL will be seen as a new session by the browser, the one thing that you would need to do is remember to keep your session variables to a minimum. The more you keep in here the more it may end up costing you. What I mean by that is that you will need to way up the cost of growing in relation to how much memory you waste to a user being connected, the more users the more memory. Which means that in time you may find yourself having to go to more servers (clustered) quicker than you may need too. Now you may not be in a situation where that is going to affect you, but you should take that into consideration when deciding your longer plan for the life of your application. -- Regards, Andrew Scott WebSite: http://www.andyscott.id.au/ Google+: http://plus.google.com/108193156965451149543 On Wed, May 16, 2012 at 4:43 AM, Nick Gleason <n.gleason@citysoft.com>wrote: ----- Excess quoted text cut - see Original Post for more -----

your WDDX method has always worked well for me too, and I have used the same method for saving sessions as well. Just dump the entire session scope to WDDX and save it to the users record between page loads, then load it back it in later, such as after login or when switching to https. On Tue, May 15, 2012 at 7:54 PM, Andrew Scott <andrews@andyscott.id.au>wrote: ----- Excess quoted text cut - see Original Post for more -----

Strange how people reply to other peoples posts, and confuse future people who may end up reading these threads. For anyone else who may read this later it was the OP who does the WDDX not me. -- Regards, Andrew Scott WebSite: http://www.andyscott.id.au/ Google+: http://plus.google.com/108193156965451149543 ----- Excess quoted text cut - see Original Post for more -----

I know, but when using gmail, you see the whole threaded conversation not individual emails, so when hit reply at the end you reply to the last post. that is a negative of course for the reason you stated, but the positive is you do at least tend to read the whole thread before before replying, which avoids you giving the same answer that 10 other people have already given, which is a problem for folks who read the emails individually. On Tue, May 15, 2012 at 8:19 PM, Andrew Scott <andrews@andyscott.id.au>wrote: ----- Excess quoted text cut - see Original Post for more -----

Then do what I do, remove the replied thread. I use gmail all the time, and I think it is a poor excuse to being lazy and not thinking. Not being difficult Russ, but I have no problems selecting the right post to reply too, or delete the reply if it is in reply to another. -- Regards, Andrew Scott WebSite: http://www.andyscott.id.au/ Google+: http://plus.google.com/108193156965451149543

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 <n.gleason@citysoft.com>wrote: ----- Excess quoted text cut - see Original Post for more -----

Note on the wddx, we were doing the same thing. We put a to client scope in the onrequestend.cfm and to session in the application.cfm/c This was all good until we started adding a lot of ajax calls and greatly increased the total numbed of http requests. We had all kinds of latency issues and even client db corruption from the number and size (we had rather large session structures) of write operations. This at one point was adding about 1.5 secs per request. We first moved to json serialization which seemed faster and smaller in size than wddx. Though, eventually we moved away from client vars all together and are just using session variables for all apps on our internal cluster. I doubt I'll every use client vars again, even in a cluster, and I've also learned to keep sessions as small as possible. One of our main issues with shared cf hosting are apps that have large sessions which hog resources. Came across a customer today with 100 sessions totalling about 45 MB, and that's just one example. High session timeouts are another factor in performance as well. Often seen customers requesting us to up the maximum to days, no so good :-) Byron Mann Lead Engineer and Architect Hostmysite.com On May 15, 2012 2:44 PM, "Nick Gleason" <n.gleason@citysoft.com> wrote: ----- Excess quoted text cut - see Original Post for more -----

Funny you should mention high session time outs. I was given a task by a friend to look at, on something that I did many years ago. Since then they had another developer come in make some changes and the server fell over about 5 times a day, when I looked at it, the session was set to 2 days, I was like WTF... Change it back to what I had set it at 6 years ago, and 8 months later it hasn't fallen over once. -- Regards, Andrew Scott WebSite: http://www.andyscott.id.au/ Google+: http://plus.google.com/108193156965451149543 On Wed, May 16, 2012 at 3:12 PM, Byr ----- Excess quoted text cut - see Original Post for more -----

I hear ya, since we eliminated the client variables all together and that whole wddx thing, our (internal) cf instances only go down during OS patches.  Can't remember the last time I had to restart the service itself. Should also mention we are using jetty which has seemed to uptick performance all around. Now shared is another ball of wax. Byron Mann Lead Engineer and Architect Hostmysite.com On May 16, 2012 1:30 AM, "Andrew Scott" <andrews@andyscott.id.au> wrote: ----- Excess quoted text cut - see Original Post for more -----

Hey there.  Many thanks on these great responses.  This is very helpful as we think this through.  May have some follow up thoughts / questions as we go. Nick

Hi Byron (and others), Quick follow up re: eliminating client variables (and wddx, etc.).  Are you saying that you are able to maintain login persistence using sessions with the whole site in https so that you don't have to worry about logins being dropped with sessions (which is probably what we will do)?  Or did you move to some other solution for login persistence? Another, related, example would be maintaining a url throughout a login.   For instance, if you are on a site and click on a link to a password protected, you will be re-directed to the login screen.  Once you login, we would like you to be directed automatically to the page. Sessions would be a handy way to do that.  But, if we wanted to maintain the option to not have the whole site in https, then using sessions for this functionality would seemingly have the risk of sessions being dumped when you move into https and you would not be automatically redirected to the target page after login.  So, again, I'd be interested in knowing alternate ways to handle that kind of scenario. (We have a way now but it may not be the most elegant). Thanks again, Nick ---------------------------------------- Return-Path: <listmaster@houseoffusion.com> Received: from mail.houseoffusion.com [64.118.74.225] by mail67.safesecureweb.com with SMTP;    Wed, 16 May 2012 01:37:33 -0400 To: cf-talk <cf-talk@houseoffusion.com> Message-ID: <CAOSLZN=gUmOtmkyYOShWsPjrcoQKqgo6o7=fj0uASANHxd=8JQ@mail.gmail.com> Subject: Re: best practice on session variable persistence and ssl? References: <CACLZGDmaGQBD5e97E-99judpnaguZxh0abD41UYiiUUHVYEXRg@mail.gmail.com> Date: Wed, 16 May 2012 01:37:16 -0400 Precedence: bulk Reply-To: cf-talk@houseoffusion.com From: Byron Mann <byronosity@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Rcpt-To: <n.gleason@citysoft.com> X-SmarterMail-Spam: SpamAssassin 0 [raw: 0], SPF_None, DK_None X-SmarterMail-TotalSpamWeight: 0 I hear ya, since we eliminated the client variables all together and that whole wddx thing, our (internal) cf instances only go down during OS patches.  Can't remember the last time I had to restart the service itself. Should also mention we are using jetty which has seemed to uptick performance all around. Now shared is another ball of wax. Byron Mann Lead Engineer and Architect Hostmysite.com On May 16, 2012 1:30 AM, "Andrew Scott"  wrote: > > Funny you should mention high session time outs. > > I was given a task by a friend to look at, on something that I did many > years ago. Since then they had another developer come in make some changes > and the server fell over about 5 times a day, when I looked at it, the > session was set to 2 days, I was like WTF... > > Change it back to what I had set it at 6 years ago, and 8 months later it ----- Excess quoted text cut - see Original Post for more ----- scope > in > > the onrequestend.cfm and to session in the application.cfm/c > > > > This was all good until we started adding a lot of ajax calls and greatly > > increased the total numbed of http requests. We had all kinds of latency > > issues and even client db corruption from the number and size (we had > > rather large session structures) of write operations. This at one point > was > > adding about 1.5 secs per request. > > > > We first moved to json serialization which seemed faster and smaller in ----- Excess quoted text cut - see Original Post for more ----- resources. > > Came across a customer today with 100 sessions totalling about 45 MB, and > > that's just one example. High session timeouts are another factor in > > performance as well. Often seen customers requesting us to up the maximum ----- Excess quoted text cut - see Original Post for more -----

Reason we were doing the session to wddx to client var, and reverse, was we are in a multi-server environment and not using the jrun session replication from server to server because of jrun's poor performance doing session replication across a cluster. Our load balancing scheme was (at the time) non-sticky.  So a user could jump from server to server, so we needed a more reliable way of transporting the sessions from one server to another, since each user request could wind up at another server. So at the end of a request, we wddx the session structure to a client variable (and into the db), on the beginning of each request, we took the client var, reversed the wddx, and set all the session variables. Thus a lot of overhead. We wound up changing the load balancing to sticky sessions, so first request from a user goes to one server, and all subsequent request go to that same server unless it goes down. At that point it wasn't necessary to "replicate" the sessions with the wddx methodology.  If a server dies, we are ok with a session lost and having the user potentially having to login again. This is a user experience vs. performance trade off we are willing to accept. From your description it sounds like you just want a user to go from http, to https, login, and jump to the original requested page. Session vars would be the way to handle tracking that requested page through the login process and then redirecting to the correct destination.  Once the user is authenticated in the ssl portion of the site, subsequent secure request (from non ssl) would bypass the login and go directly to the requested page. Basically you would have 2 sessions, one http and one https, but after logging in the transition back and forth would be seamless, unless the https session times out from inactivity and the user has to log back in. This is all based on a single server concept. If you are trying to maintain the session across server instances then you would need a mechanism to replicate the user sessions across each instance in you cluster.  Like we did with the session to wddx to client var and back to session, or Jrun in memory server to server session replication. Hope this helps, I think this thread got into two different areas; although somewhat related. Byron Mann Lead Engineer and Architect Hostmysite.com On May 17, 2012 3:16 PM, "Nick Gleason" <n.gleason@citysoft.com> wrote: ----- Excess quoted text cut - see Original Post for more -----

FYI, I found that storing the WDDX session data on disk was quicker than putting it in client scope. If your in a cluster then you most likely have a SAN or NAS anyway, so worth giving it a try and get away form using client vars. -- Russ Michaels www.bluethunderinternet.com  : Business hosting services & solutions www.cfmldeveloper.com        : ColdFusion developer community www.michaels.me.uk           : my blog www.cfsearch.com             : ColdFusion search engine ** *skype me*                     : russmichaels