5 Replies Latest reply on May 7, 2008 7:21 AM by Newsgroup_User

    Problems with Sessions

    LukeDD
      ANY SUGGESTION IS APPRECIATED


      I have a application that at the beginning, create this big empty session structure (and arrays). Users go through a series of forms that populates the structure. All data validation for mandatory forms is done server-side. For some reason, data is lost. I have session variables (random) that are populated from the same form end up empty and some not. I know this is an up in the air question, but what's the first thing I should look at. Any help is better than nothing. I've trying to solver this for quite some time.


      thank you
        • 1. Re: Problems with Sessions
          Level 7
          LukeDD wrote:
          > I know this is an up in the air question, but what's the first thing
          > I should look at.

          1) The code the creates and sets the variables?

          2) Make sure you understand the nature of sessions and applications and
          how they relate in ColdFusion. As well as how they rely on an
          'application name' string.

          • 2. Problems with Sessions
            LukeDD Level 1
            Thanks Ian.

            Below is the code that creates the session. Once that's done the users goes through the "wizard-like" forms and populates the keys.

            As for #2, I'm not sure what you mean by As well as how they rely on an
            'application name' string.

            <cfparam name="session.proc" default="#structNew()#" />
            <cfparam name="session.proc.delivery" default="" />
            <cfparam name="session.proc.CopyOriginator" default="" />
            <cfparam name="session.proc.reqType" default="" />
            <cfparam name="session.proc.reqsubtype" default="" />
            <cfparam name="session.proc.regionCd" default="" />
            <cfparam name="session.proc.originator" default="" />
            <cfparam name="session.proc.recipient" default="" />
            <cfparam name="session.proc.sessionkey" default="" />
            <cfparam name="session.proc.shipping" default="" />
            <cfparam name="session.proc.invoicing" default="" />
            <cfparam name="session.proc.copyShipping" default="" />
            <cfparam name="session.proc.co_rc" default="" />
            <cfparam name="session.proc.end_dt_day" default="" />
            <cfparam name="session.proc.end_dt_month" default="" />
            <cfparam name="session.proc.end_dt_year" default="" />
            <cfparam name="session.proc.sourceJustify" default="" />
            <cfparam name="session.proc.standing" default="" />
            <cfparam name="session.proc.start_dt_day" default="" />
            <cfparam name="session.proc.start_dt_month" default="" />
            <cfparam name="session.proc.start_dt_year" default="" />
            <cfparam name="session.proc.suggestedsup" default="" />
            <cfparam name="session.proc.supcontact" default="" />
            <cfparam name="session.proc.supphone" default="" />
            <cfparam name="session.proc.SUPADDRESS" default="" />
            <cfparam name="session.proc.supfax" default="" />
            <cfparam name="session.proc.ssJustification" default="" />
            <cfparam name="session.proc.ss_other_info" default="" />
            <cfparam name="session.proc.UPLOADDIRNAME" default="" />
            <cfparam name="session.proc.other_information" default="" />
            <cfparam name="session.proc.order" default="#arrayNew(1)#" />
            <cfparam name="session.proc.currency" default="" />
            <cfparam name="session.proc.tempFC" default="#structNew()#" />
            <cfparam name="session.proc.fc" default="#arrayNew(1)#" >
            <cfparam name="session.proc.ty" default="" >
            <cfparam name="session.proc.cRate" default="" >
            <cfparam name="session.proc.isDocCompleted" default="0" >
            <cfparam name="session.proc.attachments" default="#arrayNew(1)#" >
            • 3. Re: Problems with Sessions
              Level 7
              LukeDD wrote:

              > As for #2, I'm not sure what you mean by As well as how they rely on an
              > 'application name' string.

              >

              In order for the ColdFusion server to know what session any given
              request it receives belongs to, it uses the application name string
              defined in a <cfapplication name="aString"...> or Application.cfc
              this.name = 'aString'. If any template is associated with a different
              application string OR no string at all, then it will have a different
              session scope and not be able to access any data in other session scopes.

              • 4. Re: Problems with Sessions
                LukeDD Level 1
                Ok Thanks,

                All templates are part of one Fusebox application. So technically they should all be under one application name. If this is the case, If multiple users are on the application, the cf server cannot get mixed up in the sessions, can it?

                Again thank you for doing this.
                • 5. Re: Problems with Sessions
                  Level 7
                  LukeDD wrote:
                  > If this is the case, If multiple users are
                  > on the application, the cf server cannot get mixed up in the sessions, can it?


                  The CF server tells multiple users apart by the cfide & cftoken cookie
                  values. It is possible for an application to mishandle these cookies
                  and cause sessions to be mixed up. In the old days, some poor quality
                  proxy servers would do this. They would cache cookies at the proxy and
                  cause all users passing through them to use the same values.

                  This does bring up the point that users with cookies disabled or blocked
                  will not have session state maintained when they use the application.
                  CF will detect no cookies and generate a new set, rebuilding the session
                  scope, every time a request is received from such a user.