ariables are convenient for application-global, 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 vari
venient for application-global, 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-spec
ata.
>
> 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.
>
>
.
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
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, wh
@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
exten
On Wed, Jan 28, 2015 at 1:57 PM, Robert Harrison 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.
>
Did a simple t
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 fo
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
> 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: 704-321-12
ecent versions.
On Wed, Jan 28, 2015 at 11:08 AM, John Pullam
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 be
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
w
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
>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 an
up
with BP 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
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
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.
Hope this helps,
Wi
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 lookin
> 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
> 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 argume
#x27;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
>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
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 ex
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
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
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 n
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 wo
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
gt; 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 >wrote:
>
> >
> > There's no application.cfc at this point...the only
> > two pages involved are what's in th
o work?
>
> As you can see below when I use:
>
>
>
> and then output that with:
>
> #session.name#
>
> I get 'rick'...
>
> But that's on the same page.
>
> Would that work but not session variables between pages
> with session management
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 (not
Correction on my previous post:
The variable was stored in variables.session.name (not
variables.session.rick)... but you probably knew what I meant.. ;-)
On Mon, Feb 27, 2012 at 3:39 PM, Steve Milburn wrote:
> You will need an application.cfc (or .cfm) for session variables to w
You will need an application.cfc (or .cfm) for session variables to work.
In your example, your 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 page.
On Mon, Feb 27, 2012 at
n.name#
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 wrote:
>
> There's no application.cfc at this point...the only
> two pages involved are what's in this email.
>
> Is enabling session managem
7;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:18 PM
To: cf-
Have you enabled session management in the application.cfc?
On Mon, Feb 27, 2012 at 3:14 PM, Rick Faircloth wrote:
>
> It's been awhile since I used session variables,
> but this is simple. Why won't this work?
>
> session-test.cfm
>
>
>
>
It's been awhile since I used session variables,
but this is simple. Why won't this work?
session-test.cfm
#session.name#
session-test-2.cfm
--
#session.name#
I get the error 'Element NAME is undefined in SESSION.'
???
Session var
On Fri, Feb 3, 2012 at 12:10 PM, Dave Watts 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 them seems to
>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 condition
alk 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
> in
le.
>
> 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
in
> ...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
authe
On Thu, Feb 2, 2012 at 10:22 AM, Raymond Camden
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. If I pop open a new
t; ignore the hassle of locking the write/reads.
>
> On Thu, Feb 2, 2012 at 7:11 AM, Cameron Childress
> wrote:
> >
> > On Wed, Feb 1, 2012 at 7:37 PM, James Holmes
> wrote:
> >
> >> Race conditions in session variables can only occur when two requests
> from
t's just 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 wrote:
>
> On Wed, Feb 1, 2012 at 7:37 PM, James Holmes wrote:
>
>> Race conditions in session variables can only
On Wed, Feb 1, 2012 at 7:37 PM, James Holmes 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
> t
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
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
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
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
On Wed, Feb 1, 2012 at 1:55 PM, Mike Chabot 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 tags
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 that
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 why
> 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
> 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
o
> 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, t
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
> wrote:
> >
> > I'm an old school programmer who watches every bit and byte and really
> practices r
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
wrote:
>
> I'm an old school programmer who watche
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 af
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
attent
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 causi
u get weird results 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/
~
"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 ti
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
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 co
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 wrote:
>
> CF8
>
> My home page populates a session variable. I did a
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 SES
+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
> 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 yo
Thanks guys!
> 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 Ado
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:
>sessionmanagement="yes"
> sessiontimeout
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
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 Coldfusion Anthology now!
http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?ta
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:
http://www.houseoffusion
Thanks Matt your suggestion worked.
"
"
Odd this is the first time I've encountered this specific behaviour in
Coldfusion. Thanks a byunch was spinning my wheels on this.
~|
Order the Adobe Coldfusion Anthology now!
http://
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!
http://www.amazon.com/Adobe-Coldfusion-Antho
On Sun, Feb 13, 2011 at 8:58 PM, Matt Quackenbush 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 my setup. Thanx!
--
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.
~~
On Sun, Feb 13, 2011 at 7:59 PM, Sean Corfield 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 out why / how it's
On Sun, Feb 13, 2011 at 9:36 AM, Matt Quackenbush 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, yes, your code was
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().
r 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
~|
Order the A
> Presumably you are doing something like so...
>
>
>
>
> 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, and t
Presumably you are doing something like so...
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, and therefore, any and all
references to
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 redirect, the session variables are there but empty.
Any ideas
cott.id.au/
> -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
:robvo...@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 has been validated for content that I need (no blank fields etc.)
>
Hi Folks
I have several large forms connected to mySql tables.
I use
]', checkVariables)>
""
in one of the fields">
">
">
~
gt;
>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 so
in your code for them to do so. If you have 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 set
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 surel
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 is
> with client variables.
>
> Do you have any id
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.
>
>
~
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 ca
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 is
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 no
> 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
>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
1 - 100 of 1223 matches
Mail list logo
