scope of a current function

[Guest]

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.

[Dan_Bracuk]

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>

[Guest]

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.

[Newsgroup_User]

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.

[Newsgroup_User]

Cheers Ian.

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

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

--
Adam

[Newsgroup_User]

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.