the same set of
application variables, these variables are not appropriate for
client-specific or session-specific information. To target variables for
specific clients, use client or session variables.
~|
Order the Adobe
, because all clients running an application see the same set of
application variables, these variables are not appropriate for client-specific
or session-specific information. To target variables for specific clients, use
client or session variables
or session-specific information. To target variables for
specific clients, use client or session variables.
~|
Order the Adobe Coldfusion Anthology now!
http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag
, persistent data.
However, because all clients running an application see the same set of
application variables, these variables are not appropriate for
client-specific or session-specific information. To target variables for
specific clients, use client or session variables
Were you using relative paths to the CFCs. That could become hairy if you
move things around.
I'll generally define a CFC path variable in the application.cfm then use
that everywhere. Never had a problem. Of course, this assumes all the
CFC's are in the same location.
Robert Harrison
Full
later when the fires are out.
Thanks,
William
--
William Seiter
-Original Message-
From: John Pullam [mailto:jpul...@mcleansystems.com]
Sent: Wednesday, January 28, 2015 8:57 AM
To: cf-talk
Subject: Re: Cannot access session variables in a cfc
I know
You will need to pass your session variables as a parameter in order to use
them in the CFC, this is best practices anyways.
The difficulty is that there a lot of cfc calls and some of them are in bind
expressions so the chance of making errors is high. That's why I am so anxious
to find one
On Wed, Jan 28, 2015 at 1:57 PM, Robert Harrison rharri...@aimg.com wrote:
try adding an Application.cfc in the root physical directory
I don't that that will work. It would still be a separate application pool,
and I think you need the CFID and CFTOKEN cookies to have session vars.
@Dean,
Looked into this a bit further on CF10.
root
- Application.cfc
- ApplicationProxy.cfc (extends Application)
- cfc-folder
- - Application.cfc (extends ApplicationProxy)
- - myCFC.cfc
This does not work without the cfc/application.cfc having
extends=root.ApplicationProxy, where 'root' is
Byron, the ApplicationProxy.cfc needs to be in the root directory along
with the main Application.cfc. When you extend a CFC, CF will first look in
the same directory to see if that CFC exist. If it doesn't CF will start
looking for the CFC from the application root down. So by simply adding
Hmm, that's odd as I use that setup on numerous sites and I never have to
map the applicationproxy. I am currently using it on both ACF 10 and 11,
but I started using this around 8 or 9 and haven't changed it for new
version. I don't believe that you could use the root.(dot) notation in 8 or
9,
My app is running in a CF10 system and since I moved my cfc's out of the
document root, they are losing access to the session variables. It seems that
they work for around a day and then can no longer be found. I initialize them
in my application.cfm to a value and I can still cfdump them
What other method than session variables can I use to pass a common
variable that won't require me to include it as a parameter of every calling
routine?
Since you've moved your CFCs out of the application I cannot think of any
other method beside passing them all as arguments.
Robert
If you moved your cfc's above the application.cfc (or application.cfm) file,
the session variables will not be accessible. Session and application vars
are accessible from the application file down.
Robert Harrison
Full Stack Developer
AIMG
rharri...@aimg.com
Main Office: 704-321-1234 ext.118
If you moved your cfc's above the application.cfc (or application.cfm) file,
the session variables will not be accessible. Session and application vars
are accessible from the application file down.
That's what we did.
What other method than session variables can I use to pass a common
the application.cfc (or application.cfm) file,
the session variables will not be accessible. Session and application vars
are accessible from the application file down.
That's what we did.
What other method than session variables can I use to pass a common variable
that won't require me to include
Thanx. That's what I think I will do for the time being.
It is hard for me to come up with all the symptoms that we started seeing on
the cfc's now and I don't think I could do justice to any explanation of those
issues. It seemed to me that it was all quite normal stuff. All pages and cfc's
You shouldn't, as it breaks encapsulation
Honestly, I too think you should reconsider moving the CFC out of the web
root.
Maybe if you moved them out then created objects from them in the
application.cfc, then you may be able to use session vars, as I think the
objects would still be in the
You will need to pass your session variables as a parameter in order to use
them in the CFC, this is best practices anyways.
Good news, however, is that you can send them as a complete struct, you
don't necessarily need to have them send all separately.
cfargument name=sSession type=struct
I know this isn't ideal, but it is a live application and the decision to move
the cfc's outside of the doc root was taken because CF was having trouble
finding them (for no obvious reason). Code that has worked since CF7 started
breaking.
So we moved them and this problem began.
I am
Well, I'd hate to do this, but you could define an application.myvar type
variable and put all the variables you need to pass in that as a structure
or list, then send that variable in your arguments. That would get to one
variable ... but then you're still going to need to deconstruct it before
versions.
On Wed, Jan 28, 2015 at 11:08 AM, John Pullam jpul...@mcleansystems.com
wrote:
My app is running in a CF10 system and since I moved my cfc's out of the
document root, they are losing access to the session variables. It seems
that they work for around a day and then can no longer
try adding an Application.cfc in the root physical directory
I don't that that will work. It would still be a separate application pool,
and I think you need the CFID and CFTOKEN cookies to have session vars.
Robert Harrison
Full Stack Developer
AIMG
rharri...@aimg.com
Main Office:
You could also extend the main application.cfc. You can't do this directly
if the cfc's are in a sub-directory though. If that is the case, you could
use a proxy, I do this all the time. Here would be the structure.
root
- Application.cfc
- ApplicationProxy.cfc (extends Application)
- cfc-folder
John,
There are some pretty significant advancements to CFCs since CF 7,
especially around scoping. You definitely want to look at the difference
up the version chain.
Cutter
On 1/28/2015 12:02 PM, John Pullam wrote:
Thanx. That's what I think I will do for the time being.
It is hard for
Thanks for that reminder... it's been years since
I've even used cflocation! My how knowledge, unused,
is fleeting...
-Original Message-
From: Azadi Saryev [mailto:azadi.sar...@gmail.com]
Sent: Monday, February 27, 2012 9:20 PM
To: cf-talk
Subject: Re: Session variables not working
I normally use an application.cfc, but this was just a quick
proof-of-concept that I threw together to test something.
-Original Message-
From: James Holmes [mailto:james.hol...@gmail.com]
Sent: Monday, February 27, 2012 10:56 PM
To: cf-talk
Subject: Re: Session variables not working
Thanks, Jay!
Rick
-Original Message-
From: Jay Pandya [mailto:jaypandy...@gmail.com]
Sent: Tuesday, February 28, 2012 12:49 AM
To: cf-talk
Subject: Re: Session variables not working
Hi Rick,
When you are using session variables and you want to get its value
in other page
It's been awhile since I used session variables,
but this is simple. Why won't this work?
session-test.cfm
cfset session.name = 'rick'
cfoutput#session.name#/cfoutput
cflocation url=session-test-2.cfm
session-test-2.cfm
--
cfoutput#session.name#/cfoutput
Have you enabled session management in the application.cfc?
On Mon, Feb 27, 2012 at 3:14 PM, Rick Faircloth r...@whitestonemedia.comwrote:
It's been awhile since I used session variables,
but this is simple. Why won't this work?
session-test.cfm
cfset session.name
#session.name#/cfoutput
I get 'rick'...
But that's on the same page.
Would that work but not session variables between pages
with session management being enabled in application.cfc?
Rick
-Original Message-
From: Steve Milburn [mailto:scmilb...@gmail.com]
Sent: Monday, February 27, 2012 3
yes you must have an application.cfm/cfc in order to enable session
variables.
On Mon, Feb 27, 2012 at 8:28 PM, Rick Faircloth r...@whitestonemedia.comwrote:
There's no application.cfc at this point...the only
two pages involved are what's in this email.
Is enabling session management
that with:
cfoutput#session.name#/cfoutput
I get 'rick'...
But that's on the same page.
Would that work but not session variables between pages
with session management being enabled in application.cfc?
Rick
-Original Message-
From: Steve Milburn [mailto:scmilb...@gmail.com]
Sent: Monday
You will need an application.cfc (or .cfm) for session variables to work.
In your example, your cfset session.name = 'rick' was actually stored in
the variables scope on that page as variables.session.rick, and not
actually in the session scope. That is why it was not available on the
other
'
and then output that with:
cfoutput#session.name#/cfoutput
I get 'rick'...
But that's on the same page.
Would that work but not session variables between pages
with session management being enabled in application.cfc?
Rick
-Original Message-
From: Steve Milburn [mailto:scmilb
Thanks for the reminder!
Rick
-Original Message-
From: Steve Milburn [mailto:scmilb...@gmail.com]
Sent: Monday, February 27, 2012 3:42 PM
To: cf-talk
Subject: Re: Session variables not working
Correction on my previous post:
The variable was stored in variables.session.name
Subject: RE: Session variables not working
There's no application.cfc at this point...the only
two pages involved are what's in this email.
Is enabling session management in an application.cfc
necessary for session management to work?
As you can see below when I use:
cfset session.name
wrote:
yes you must have an application.cfm/cfc in order to enable session
variables.
On Mon, Feb 27, 2012 at 8:28 PM, Rick Faircloth r...@whitestonemedia.com
wrote:
There's no application.cfc at this point...the only
two pages involved are what's in this email.
Is enabling session
Hi Rick,
When you are using session variables and you want to get its value in
other page after using cflocation then you need to enable seclientcookies true
in cfapplication tag. More description you can read on
http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=Tags_a
On Thu, Feb 2, 2012 at 10:22 AM, Raymond Camden raymondcam...@gmail.com
wrote:
I'd also argue that sometimes race conditions may not matter.
On project I've worked on, this is true 99.9% of the time.
Consider a session variable that tracks the # of pages you have viewed
in your session.
...and this is a pretty unusual use case with all the analytics packages
out there. Really, I have a pretty hard time thinking of a good use case
with race conditions that goes beyond a contrived impractical example.
Someone on cf-talk had a race condition just last week, around their
.
Someone on cf-talk had a race condition just last week, around their
authentication process. Of course, it was because of how their code
was structured, and probably didn't need CFLOCK to resolve.
Race conditions certainly exist. Specifically though, race conditions
involving session variables
their
authentication process. Of course, it was because of how their code
was structured, and probably didn't need CFLOCK to resolve.
Race conditions certainly exist. Specifically though, race conditions
involving session variables which can be resolved using CFLOCK, are
relatively uncommon
Race conditions certainly exist. Specifically though, race conditions
involving session variables which can be resolved using CFLOCK, are
relatively uncommon.
In my personal experience anyway...
+!
In my experience anything that would really be effected by race conditions
shouldn't
On Fri, Feb 3, 2012 at 12:10 PM, Dave Watts dwa...@figleaf.com wrote:
I'm not sure I'm disagreeing with you. Most race conditions that I see
can be resolved without CFLOCK, but not all - specifically around
components used during authentication/user initialization/etc. The
primary reason for
On Wed, Feb 1, 2012 at 7:37 PM, James Holmes james.hol...@gmail.com wrote:
Race conditions in session variables can only occur when two requests from
the same session execute concurrently. This is more likely with ajax
requests or framesets. Since everyone uses ajax requests these days (even
a simple stat and it's not perfect, then I'd
ignore the hassle of locking the write/reads.
On Thu, Feb 2, 2012 at 7:11 AM, Cameron Childress camer...@gmail.com wrote:
On Wed, Feb 1, 2012 at 7:37 PM, James Holmes james.hol...@gmail.com wrote:
Race conditions in session variables can only occur when
.
On Thu, Feb 2, 2012 at 7:11 AM, Cameron Childress camer...@gmail.com
wrote:
On Wed, Feb 1, 2012 at 7:37 PM, James Holmes james.hol...@gmail.com
wrote:
Race conditions in session variables can only occur when two requests
from
the same session execute concurrently. This is more likely
in the case I was referring to Dave, there was no locking, and it was
copying all scopes into sessions (variables, url and form) and then back
again
so it really was for no good reason :-)
however all programmers work different and have a tendency to slate the way
others have done things, thus
I would agree with what some others have written, in that an apparent
over-use of session variables is not inherently bad, unless it is
causing server instability or memory problems. Make sure the
programmer is using session variables for a specific reason, and that
he is aware of the issues
On Wed, Feb 1, 2012 at 1:55 PM, Mike Chabot mcha...@gmail.com wrote:
One thing most developers neglect to do when using lots of session
variables is making the session code thread safe, which takes a
relatively high skill and experience level to accomplish. Unless you
see a lot of cflock
wrote:
I would agree with what some others have written, in that an apparent
over-use of session variables is not inherently bad, unless it is
causing server instability or memory problems. Make sure the
programmer is using session variables for a specific reason, and that
he is aware
Race conditions are what I am referring to and they are a problem,
even in CF9. Many developers either heard or read that the earlier
problems with session variables have been fixed and that they no
longer need to ever lock them, but this is not true. It is one of the
most common CF
Race conditions in session variables can only occur when two requests from
the same session execute concurrently. This is more likely with ajax
requests or framesets. Since everyone uses ajax requests these days (even
though no-one uses framesets any more), it is still an issue, as you say
In addition to AJAX (and Flex/Flash remoting calls) and framesets (and
iframes), issues with session variables can also occur if a user has
two separate browser tabs open, double clicks links or form submit
buttons (some users double click everything), rapidly and repeatedly
presses a submit
I'm an old school programmer who watches every bit and byte and really
practices resource management in my coding practices.
I've got a new programmer working for me (on contract) and I'm finding he's
using session Vars all over the place. He creating session Vars on forms that
have a hundred
It depends.
It could be no big deal, but it definitely sounds like there is a
significant risk of oops! there goes the server!. As a general rule, you
are correct: keep the session as lean as possible. More specifically, don't
use it unless there is a damn good reason to do so.
Maybe it's time
on some pages because session variables get
overwritten from elsewhere?
Only after you are certain the code is functionally correct memory
optimizations come into play
Jochem
--
Jochem van Dieten
http://jochem.vandieten.net
As a general rule in life, I believe, everything in moderation - The
extremes on either side will always get you into trouble.
Modern servers have tons of RAM, session vars, especially vars that are
just strings, are pretty light weight. It's hard to imagine making common
senses use of them
I generally would keep the variable as long as you need it and no longer.
If it's just needed for the request, there is no reason at all it should
be in the session scope. Performance is a concern, but so is data leaking
from page to page. If you're putting alot in session and not paying
Thanks for all the input. Besides the fact that the application could
conceivably have hundreds of thousands of session Vars in memory, I'm concerned
about collision too.
I see no scope referencing in these Vars and see they are all 'common names'. I
also see no routines to clear any vars
I think I ran across that guy once (lol). IMO, loading anything other
the absolute minimum required info to identify a unique session into
session variables is bad coding practice.
On Tue, Jan 31, 2012 at 8:01 AM, Robert Harrison
rob...@austin-williams.com wrote:
I'm an old school programmer
the absolute minimum required info to identify a unique session into
session variables is bad coding practice.
On Tue, Jan 31, 2012 at 8:01 AM, Robert Harrison
rob...@austin-williams.com wrote:
I'm an old school programmer who watches every bit and byte and really
practices resource
I've got a new programmer working for me (on contract) and I'm finding he's
using session Vars all over the place. He
creating session Vars on forms that have a hundred fields, he putting arrays
into session Vars, etc. I just went through
a few of the programs he wrote and used them, then
IMO, loading anything other the absolute minimum required info to identify a
unique session into
session variables is bad coding practice.
What does that mean? The absolute minimum required info to identify a
unique session would be the session ID. Are you saying any other use
of session
I have come across some similar code also, moving variables scope into
sessions and back again for no reason.
There's actually a reason why that might be, in some cases. Not a good
reason, but a reason nonetheless. It used to be the case (CF 5 and
earlier) that you had to worry about locking a
Thanks. I'll try that.
-Original Message-
From: Russ Michaels [mailto:r...@michaels.me.uk]
Sent: Friday, December 30, 2011 7:05 PM
To: cf-talk
Subject: Re: Lost SESSION variables - sometimes
it is probably a cookie issue as this is how the session is tracked.
clear the cookies
CF8
My home page populates a session variable. I did a dump to make sure this was
happening.
Mozilla (Firefox) - newest download
On one machine I go to another page off my menu and it displays correctly.
I go to another machine and I get an error - no session variable defined. The
entire
it is probably a cookie issue as this is how the session is tracked.
clear the cookies and cache on that browser and see if it helps.
Also make sure cookies are not disabled.
On Fri, Dec 30, 2011 at 7:26 PM, Stephens, Larry V steph...@indiana.eduwrote:
CF8
My home page populates a session
cfapplication name=newapp
sessionmanagement=yes
sessiontimeout=#CreateTimeSpan(14,0,0,0)#
My session expires in as little as 20 minutes, I dont understand why so early
when I set the timeout for 14 days.
~|
Order the Adobe
What is the maximum time-out period defined for memory variables on your
server?
By default session variables have a maximum timeout period of 20 minutes.
You can manually specify a timeout of something less than that value, but
nothing more. If you want your sessions to timeout in 14 days
Rick,
What is your applicationtimeout set to? If it's set to 20 minutes, it
will clear your session cache as well (I think). Also, check your
application and session timeout settings in CF Admin.
HTH,
Carl
On 10/18/2011 10:32 AM, Rick T wrote:
cfapplication name=newapp
Thanks guys!
cfapplication name=newapp
sessionmanagement=yes
sessiontimeout=#CreateTimeSpan(14,0,0,0)#
My session expires in as little as 20 minutes, I dont understand why
so early when I set the timeout for 14 days.
By default session variables have a maximum timeout period of 20 minutes.
You can manually specify a timeout of something less than that value, but
nothing more. If you want your sessions to timeout in 14 days, then you
have to change the maximum timeout values on your server to something
+1 as Dave said.
it seems what you really want is probably a remember me function
that keeps users logged in, this will simply save a cookie with an
encrypted copy of their username/password and log them in again when
the session expires.
If you specifically want to store the session data for 14
Hi guys, just came in this morning. thanks for the responses will try out the
suggested code and get back to you.
I'm on CF9/Fusebox 5.5
~|
Order the Adobe Coldfusion Anthology now!
Thanks Matt your suggestion worked.
cfset session.myvariable = duplicate(form) /
cflocation url=foo.cfm /
Odd this is the first time I've encountered this specific behaviour in
Coldfusion. Thanks a byunch was spinning my wheels on this.
Cool beans. Always glad to help. Thanks for reporting back. :-)
~|
Order the Adobe Coldfusion Anthology now!
http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion
Archive:
Presumably you are doing something like so...
cfset session.myvariable = form /
cflocation url=foo.cfm /
I have not tested it, but I am guessing that you are loosing the session
variables because you are creating a _reference_ to the form scope. When
you redirect, the form scope is now
are creating brand new variables that will are _value_ based
rather than simply a reference to the form scope. If this is what you are
doing, then, of course, changing the form scope (of form-scoped variables)
will have no bearing on the session variables you created.
HTH
On Sun, Feb 13, 2011 at 11:36 AM, Matt Quackenbush wrote:
The only way to pass a structure in CF by reference is by using
duplicate().
Oops. That is suppose to say
The only way to pass a structure in CF by value is by using duplicate().
On Sun, Feb 13, 2011 at 9:36 AM, Matt Quackenbush quackfu...@gmail.com wrote:
Dave, as you well know I usually agree with you. However, in this case, I
do not agree with you at all. Why? Because you are 100% wrong in your
statement. What I showed is **exactly** how references work.
Well,
On Sun, Feb 13, 2011 at 7:59 PM, Sean Corfield seancorfi...@gmail.com wrote:
I tried it on Railo and discovered that the form scope is somehow
reused across multiple requests - so on Railo, your logic would be
correct. That's interesting and I'll have to take that up with
engineering to find
I have two different CF9 installations that behave the way I described. It
actually caught me out on a quickie application I did for someone awhile
back, because I did not expect that behavior. But that's exactly what it
does on two different installations. shrug
On Sun, Feb 13, 2011 at 8:58 PM, Matt Quackenbush quackfu...@gmail.com wrote:
I have two different CF9 installations that behave the way I described.
Odd. I couldn't repro on CF9.0.1 locally. Do you have a small test
case that shows form scope behaving like that for you? I'd love to try
it on
I have some code where I am transferring the contents of a form submission into
a session variable.
According to some cfdumps, the form variables do get set in session.
but after the cflocation redirect, the session variables are there but empty.
Any ideas
Presumably you are doing something like so...
cfset session.myvariable = form /
cflocation url=foo.cfm /
I have not tested it, but I am guessing that you are loosing the session
variables because you are creating a _reference_ to the form scope. When
you redirect, the form scope is now empty
/
-Original Message-
From: Rob Voyle [mailto:robvo...@voyle.com]
Sent: Wednesday, 26 January 2011 5:09 PM
To: Andrew Scott; cf-talk@houseoffusion.com
Subject: Re: Session variables security
Hi Andrew
have you used this firewall or others that are out there?
I find I have a great
Hi Folks
I have several large forms connected to mySql tables.
I use cfqueryparam when querying and inserting data from the form after it has
been validated for content that I need (no blank fields etc.)
I created the following validation to check for scripts etc being injected.
Is there
...@voyle.com]
Sent: Wednesday, 26 January 2011 11:53 AM
To: cf-talk
Subject: Re: Session variables security
Hi Folks
I have several large forms connected to mySql tables.
I use cfqueryparam when querying and inserting data from the form after
it
has been validated for content that I need
Hi,
When the user logs in, I save their username to the session scope.
Would i need to re-validate that username at the top of every page that uses it
in a database query?
I previously thought this was not necessary but if it is possible for someone
to send malicious sql injection then
a
vulnerable piece of code that can give unexpected and undesired results
because of malicious inputs form the client, then you have a problem.
But it is not an insecurity in the session variables is is an insecurity
in your application and how it is setting those variables. There is no
way for a user
.
But it is not an insecurity in the session variables is is an insecurity
in your application and how it is setting those variables. There is no
way for a user to send random code at a CF server and have it do
anything to session variables unless it is happening somewhere in the
CFML codebase
We have an issue with early timeout using session and client variables. We are
using ColdFusion 5. We have set up sessiontimeout for 2 hours in CFAPPLICATION
as well as in CF Admin (maximum timeout and default timeout). But Session
variables expire in approximately 45 sec. The same behavior
for 2 hours in
CFAPPLICATION as well as in CF Admin (maximum timeout and default timeout).
But Session variables expire in approximately 45 sec. The same behavior is
with client variables.
Do you have any idea what it can be? Any help is appreciated
, 2011 at 1:26 PM, Maneesha Aggarwal ma...@columbia.edu wrote:
We have an issue with early timeout using session and client variables. We
are using ColdFusion 5. We have set up sessiontimeout for 2 hours in
CFAPPLICATION as well as in CF Admin (maximum timeout and default timeout).
But Session
hours in
CFAPPLICATION as well as in CF Admin (maximum timeout and default timeout).
But Session variables expire in approximately 45 sec. The same behavior is
with client variables.
Do you have any idea what it can be? Any help is appreciated.
Thanks
From time to time I go back and read my CF books to see if I can glean
something new. I was reading the section again on locking and I'm (rather
belatedly) confused.
The book says you should act on SESSION variables within a cflock because of
potential collisions. But are my SESSION variables
The book says you should act on SESSION variables within a cflock because of
potential collisions. But are my SESSION
variables not mine and inaccessible to anyone else? How could there be a
collision?
The same browser can make multiple concurrent requests; they will all
be in the same
Think iframes or Ajax calls or other types of situations where A User may
be session-linked to more than one current thread / process. In those
cases, if there is potential for simultaneous writes to a session var, then
you could theoretically have a clash. If your app uses no Ajax and has
1 - 100 of 1178 matches
Mail list logo
