5 Replies Latest reply on Jul 15, 2008 2:39 PM by Newsgroup_User

    scope of a current function

    syslob
      My cold fusioon 8.0 website defines alot of functions using the CFFUNCTION tag, however because of limitations within cold fusion, I cannot call these functions as application or session scope variables because the server will only allow one instance of the function running at once. Instead, I created all of my functions and store them as application scope variables and during each page visit,I define request scope variables off of the application scope variables, and then call the function defined under the request scope.

      For security reasons, I am required to ensure that the application scope version of the CFFUNCTION cannot be called from anywhere within the website. Is there a way to build such a check into a CFFUNCTION to determine what scope it is currently running under so that I can deny anyone who tries to call the application scope version of each function.
        • 1. Re: scope of a current function
          Dan Bracuk Level 5
          Your first paragraph does not make any sense. If the server will only allow one instance of the function to run at once, then nothing you have done so far helps you solve that problem.

          Are you saying that you can't do this?
          <cfinvoke returnvariable = "session.something">?

          If so, why not do this?
          <cfinvoke returnvariable = "somevar">?
          <cfset session.something = somevar>
          • 2. Re: scope of a current function
            syslob Level 1
            My understanding is that session and application scope UDFs act in the same manner, so I stay away from declaring my function in either one of those scopes. The Application scope for an obvious reason, only one web visitor at a time could call the function. The session scope because I had some functions which are called within themselves, which causes a deadlock. I decided to go with declaring application scope UDFs and copying them to the request scope, as such...

            1) I created a bunch of UDFs and declared them under the application scope, such as this...

            <cfif not isdefined("application.myFunction")>
            <cffunction name="myFunction" returntype="boolean" output="false">
            :
            <cfreturn true>
            </cffunction>
            <cflock scope="application" timeout="10"><cfset application.myFunction=myFunction></cfif>
            </cfif>

            2) Then in the application.cfm I declared a request scope of the application scope UDF, which is what I used to call the UDFs.
            :
            <cfset request.myFunction=application.myFunction>
            :

            Some of the application scope UDFs are only copied to the request score if the current user has a certain level of access. I wanted a way to ensure that even if someone found a way to execute an application scope UDF, that it would not perform the action. This is why I was asking if anyone knew of a way of determining the current scope of a running function.
            • 3. Re: scope of a current function
              Level 7
              First of all, I question the value of declaring a function in the
              application scope, if you are not going to use it there. Sounds like a
              waste of memory. Why not just dynamically declare the function on a
              page when it is known that it is going to be used on that page?

              Secondly, I'm not sure this line is doing what you think it is doing.
              > <cfset request.myFunction=application.myFunction>

              My understanding is that generally ColdFusion creates a copy by
              reference of complex variables. I have only seen this discussed in
              relationship to things like arrays and structures so I am unsure how it
              implies to a 'function' variable. But I suspect there is a high chance
              that this line only creates a pointer in 'request.myFunction' to the
              same code referenced in 'application.myFunction' and you have not
              mitigated the issues you seem to be concerned about.

              Thirdly, it really sounds like you are trying to use user defined
              functions as components. You may have cleaner code if you just went
              ahead and made some 'utility' components that encapsulate these functions.

              Finally to answer your question, I know of no mechanism for a function
              to introspect what scope from which it is being utilized. The only hack
              I can imagine is to modify your code when it is copied into the local
              scope. Something like having a boolean, 'runme' lets say, that is set
              to false in the default 'application' scope, but then set to 'true' in
              the local copy.

              But I would still be highly confused by this convoluted looking
              situation you have here. In my world I would have either a utility cfc
              containing functions like this that can be configured, or a simple
              utility cfm file containing these functions and then dynamically set or
              unset these naturally local functions as necessary by business requirements.
              • 4. Re: scope of a current function
                Level 7
                Cheers Ian.

                You saved me typing in pretty much exactly the same thing.

                So... err... "wot he sed".

                --
                Adam
                • 5. Re: scope of a current function
                  Level 7
                  Adam Cameron wrote:
                  > Cheers Ian.
                  >
                  > You saved me typing in pretty much exactly the same thing.
                  >
                  > So... err... "wot he sed".
                  >

                  Ah, shucks you are so kind. There's been many a time you have beat me
                  to the keyboard with the relevant response.

                  I'll take a moment of this mutual adoration to add one point I
                  originally forgot.

                  Some issues that this convoluted solution may be attempting to mitigate
                  might resolve around not properly using 'VAR' scoped local variables.
                  Particularly the comment about having difficulty recursively calling a
                  function speak to non-var scoped, and thus global, variables getting
                  messed up.

                  Other concurrency issues might be better handled with locked code, but I
                  hesitate to suggest this if it continues to foster bad design.