I often work on multiple CFML engine instances on the same server at the
same time, particularly when checking a behavior difference between
engines. If I’m on an ACF site, then hit a Lucee site in the same browser,
I run into problems with the app’s authentication, in at least two
different apps. The details are specific to those implementations, but at
the root of it, they’re caused by the fact that Lucee creates its CFIF and
CFTOKEN cookies with all lowercase names, while ACF uses uppercase. The
result is that cookies with both cases exist. Deleting the lowercase
versions fixes the problem. I noticed this in Railo for a long time too,
never spoke up about it.
Is this difference intentional, to solve a problem I’m not are of?
If not, I’d suggest matching ACF to avoid this hassle.
I work around this in dev by having different domain names for each
instance / type. EG: lucee.local, cf11.local, cf10.local, etc. I get that
this is not always possible.On 4 February 2015 at 16:45, Dave Merrill <@Dave_Merrill> wrote:
I often work on multiple CFML engine instances on the same server at the
same time, particularly when checking a behavior difference between
engines. If I’m on an ACF site, then hit a Lucee site in the same browser,
I run into problems with the app’s authentication, in at least two
different apps. The details are specific to those implementations, but at
the root of it, they’re caused by the fact that Lucee creates its CFIF and
CFTOKEN cookies with all lowercase names, while ACF uses uppercase. The
result is that cookies with both cases exist. Deleting the lowercase
versions fixes the problem. I noticed this in Railo for a long time too,
never spoke up about it.
Is this difference intentional, to solve a problem I’m not are of?
If not, I’d suggest matching ACF to avoid this hassle.
Different ports won’t help your cookie situation though.Cookies are
domain-based.On 4 February 2015 at 17:42, Dave Merrill <@Dave_Merrill> wrote:
Sure, that’s a workaround, and a valid scenario you might want to try, but
so is different ports, which is what I typically do. Other people can hit
them then too, without any setup.
Just curious if this is an oversight or on purpose.
Sure, that’s a workaround, and a valid scenario you might want to try, but
so is different ports, which is what I typically do. Other people can hit
them then too, without any setup.
Just curious if this is an oversight or on purpose.
DaveOn Wednesday, February 4, 2015 at 12:04:35 PM UTC-5, Adam Cameron wrote:
I work around this in dev by having different domain names for each
instance / type. EG: lucee.local, cf11.local, cf10.local, etc. I get that
this is not always possible.
On 4 February 2015 at 16:45, Dave Merrill <enig...@gmail.com <javascript:> wrote:
I often work on multiple CFML engine instances on the same server at the
same time, particularly when checking a behavior difference between
engines. If I’m on an ACF site, then hit a Lucee site in the same browser,
I run into problems with the app’s authentication, in at least two
different apps. The details are specific to those implementations, but at
the root of it, they’re caused by the fact that Lucee creates its CFIF and
CFTOKEN cookies with all lowercase names, while ACF uses uppercase. The
result is that cookies with both cases exist. Deleting the lowercase
versions fixes the problem. I noticed this in Railo for a long time too,
never spoke up about it.
Is this difference intentional, to solve a problem I’m not are of?
If not, I’d suggest matching ACF to avoid this hassle.
We discovered this issue back in Railo and fixed it there, but a far better
solution would be to allow to configure the cookie names.
Then you can call your cookie whatever you want and hide the fact that it’s
a Lucee server.
Cftoken is always 0 and should be removed from the cookies, allowing to
check for cookie.cftoken and the likes without an error.On Feb 4, 2015 10:02 AM, “Dave Merrill” <@Dave_Merrill> wrote:
Understood, different ports is where I see the problem. I just meant
that’s how I access these different instances on the same box, as opposed
to different domains.
Dave
On Wednesday, February 4, 2015 at 12:45:38 PM UTC-5, Adam Cameron wrote:
Different ports won’t help your cookie situation though.Cookies are
domain-based.
Sure, that’s a workaround, and a valid scenario you might want to try,
but so is different ports, which is what I typically do. Other people can
hit them then too, without any setup.
Just curious if this is an oversight or on purpose.