[ColdBox 3.5.0 Final] Persisting an existing session

[Keith]

I am brand new to Coldbox and this group, please forgive me if am
doing something wrong. I did some searching first and didn't see an
answer to this question.

Scenario:
We have a unified login across our entire network. Dozens of
applications share a session so that you can navigate from application
to application seamlessly without logging in each time. Each
application uses its own structure within the session scope to manage
application specific session information (e.g.
session['currentAppName']). None of the other applications use
Coldbox, this new app is the first implementation of CB on the
network.

Issue:
When visiting the CB app, the session gets overwritten by CB.
Considered copying the session using the SessionStorage plugin, but
that does not solve the issue of persisting the existing session for
when a user wants to leave the app and move back to another existing
app. I tried copying the session onSessionStart, but I think I run
into a race condition there.

Summary:
I need to persist an existing session into the CB session.

P.S. I have some in service meetings that may make it difficult for me
to reply to additional information requests until Thursday. I will
try my best to get back on here before then, I just don't want anyone
to think it is an abandoned thread.

[Aaron Greenlee]

First, Welcome to the community, Keith!

Now, can you elaborate: " When visiting the CB app, the session gets overwritten by CB." ?

ColdBox should not replace anything in the session scope. Some variables may be added to the session scope for debugging or when Flashing variables between requests or using the SessionStorage plugin; however, I don't belive ColdBox does anything like. structClear(session).

Bottom line
Anything you put into the session scope should not be impacted by ColdBox. I think there is something else going on within the application.

Try This

What happens when you go to the Application.cfc onRequestStart method and add the following code to the top of the function so it executes before ColdBox can grab the request?

<cfset writeDump(var=session,abort=true) />

Thanks,

Aaron

[Keith]

Thanks for reaching out Aaron. So far I am really enjoying the CB
framework, sometimes I feel like I am drowning in the more advanced
features, but on the basic level it performs a lot like I have always
wanted frameworks to perform.

I have to run to meetings, but I will give you the info on the dumps
when I can get back to the code. I did try that at one point, I just
don't remember the results off hand. Below is some more detailed
information about what you asked about.

When I arrive at the application, lets call it QAR (since that is its
name), you can scroll down to the debugging information and see all of
the previously existing data (previously set, global values user_id,
group_id, etc). To begin using the application the user must select
an item to work on (a QAR), from a select list and hit submit.

When I arrive to the next page, and scroll down to the debug
information, all the global session information is gone. Now, during
that submission, I can set information (e.g. a QAR_id), and that will
be there. But all of global session keys are gone.

On Apr 16, 11:34 am, Aaron Greenlee <aarongreen...@gmail.com> wrote:
> First, Welcome to the community, Keith!
>
> Now, can you elaborate: " When visiting the CB app, the session gets
> overwritten by CB." ?
>
> ColdBox should not replace anything in the session scope. Some variables
> may be added to the session scope for debugging or when Flashing variables
> between requests or using the SessionStorage plugin; however, I don't
> belive ColdBox does anything like. structClear(session).
>

> *Bottom line*

> Anything you put into the session scope should not be impacted by ColdBox.
> I think there is something else going on within the application.
>

> *Try This*

[Sana Ullah]

Hi Keith,

Coldbox does not override any session variables but I think the problem could be due to different Application name.

Please make sure you have same Application name across different Apps.

Application.cfc this.name = "-----"

Thanks

--
You received this message because you are subscribed to the Google Groups "ColdBox Platform" group.
To post to this group, send email to col...@googlegroups.com
To unsubscribe from this group, send email to coldbox-u...@googlegroups.com
For more options, visit this group at http://groups-beta.google.com/group/coldbox
For News, visit http://blog.coldbox.org
For Documentation, visit http://wiki.coldbox.org

[Richard Herbert]

Hi Keith,

Sana is right about the need to have the same application name as defined in Application.cfc/.cfm for session variables to be shared between applications. The only worry would be that all session variables will be share, as all the applications would be seen as one, so that could mean that aspects of one application could "bleed" into another causing unexpected results.

Have you thought about moving your shared variables into the Server scope? That way they will be available to all applications on the server without the session vars on each "application" messing with each other. 

Richard

[Andrew Scott]

Actually I would not suggest the server scope for session management as it never expires, and a user would never be logged out either.

If this is for single sign on, the session is the best place to put it and the Application Name will need to be the same across all your applications.

-- 

Regards,

Andrew Scott

WebSite: http://www.andyscott.id.au/

Google+: http://plus.google.com/108193156965451149543

--

[Richard Herbert]

This is true. Whilst the server scope does not expire you could delete the user server scope variables used to check if the user is logged in with a "logout" event.

Just wanted to offer an alternative to using the session scope across "applications" that share the same application name which can have unexpected results if one "application" amends a session variable that another "application" depends on.

Richard

To unsubscribe from this group, send email to coldbox-unsubscribe@googlegroups.com

[Andrew Scott]

How would you fire the logout event if the user just closes the browser.

-- 

Regards,

Andrew Scott

WebSite: http://www.andyscott.id.au/

Google+: http://plus.google.com/108193156965451149543

To unsubscribe from this group, send email to coldbox-u...@googlegroups.com

[Richard Herbert]

I think I have agreed that it's not perfect.

[Richard Herbert]

I think I have agreed that it's not perfect.

[Keith]

Sorry for disappearing for a while there. I discussed it with some of
the other developers in the other division and they said that they had
no problems across application names. I don't have access to their
code base, so I cannot confirm that.

With that said, I have just done some initial testing, and it seems
like defining the appName as "" in the Coldbox.cfc is preserving the
existing session data. As best as I can tell, the framework was not
wiping the existing session as much as launching a brand new session
and ignoring the previously existing one. When you guys mentioned the
appName, it was a complete facepalm, I hadn't thought of
troubleshooting that and it made complete sense.

It looks like the issue is resolved, thank you everyone for the
advice, you all were a huge help at giving me a different perspective.

[Tom Miller]

Hi keith,

Sessions are always based around the application name - otherwise on a
shared server you'd cause havoc with other peoples apps structClear(session)
for example!!!

[Keith]

First, I am not sure how this occurred, but it says that unwittingly
changed the name of the thread. I am not sure how I did that, but my
apologies to Andrew. His format followed the forum guidelines and I
went and messed it up some how.

Second, I am seeing a disconnect between the session dump in the debug
information and when I actually dump the session. In this case once I
set the app name to "" I was seeing the previously existing session
information in the debug dump, hence my excitement about the
solution.

Unfortunately as I changed the code to reference that information, it
caused an error, saying that it didn't exist. I changed the code
back, relogged in, saw the information in the debug dump, then dumped
it myself to find that the two were not consistent. Stuff that I was
setting wasn't showing up in the debug, and stuff in the debug was not
showing up for my code.

I am going to get in touch with some more of the developers from the
other team and see if I can look at the code base and find out if
there is a unified application name that they are unaware of for some
reason. Any other suggestions are welcome.

Keith

On Apr 17, 4:50 am, Andrew Scott <andr...@andyscott.id.au> wrote:
> Actually I would not suggest the server scope for session management as it
> never expires, and a user would never be logged out either.
>
> If this is for single sign on, the session is the best place to put it and
> the Application Name will need to be the same across all your applications.
>
> --
> Regards,
> Andrew Scott
> WebSite:http://www.andyscott.id.au/
> Google+:http://plus.google.com/108193156965451149543
>

> On Tue, Apr 17, 2012 at 6:00 PM, Richard Herbert <rich...@infoweb.co.uk>wrote:
>
>
>
>
>
>
>
> > Hi Keith,
>
> > Sana is right about the need to have the same application name as defined
> > in Application.cfc/.cfm for session variables to be shared between

> > applications. The only worry would be that *all *session variables will

[Keith]

ok, everyone. Here is the new wrench in it. After finding out more
about their environment (I was a bit in the dark before), from what I
have gathered they are not using Application.cfc's anywhere. What
they are doing is using the Application.cfm files and then including
the file further down the file structure to persist the the over all
session. Yes, my mind is a bit blown...

So, I have a simple question, which I am almost certain the answer is
"No", but I just figured I would get it from some experts before
giving up on this fiasco. Can CB be bootstrapped using the
Application.cfm instead of the Application.cfc?

K

[Andrew Scott]

Why would you want too?

The thing to remember is that whether it is Application.cfc or Application.cfm, there is still a requirement that they both need to use and Application name. In Application.cfm this will be done by the use of the <cfapplication /> tag where as Application.cfc would be done by setting this.name to the name you want.

-- 

Regards,

Andrew Scott

WebSite: http://www.andyscott.id.au/

Google+: http://plus.google.com/108193156965451149543

[Keith]

I am at as much of a loss as you are Andrew. Unfortunately, I am not
in a position to affect standards in the position I am in. I have
been told that right now my options are to include the ../
application.cfm with in coldbox, or abandon coldbox and build with out
using a framework (which seems to be their standard route). I
figured I would reach out to all of you, since it is such an odd
situation.

[Andrew Scott]

Wow.... What reason do they have for making such a statement?

-- 

Regards,

Andrew Scott

WebSite: http://www.andyscott.id.au/

Google+: http://plus.google.com/108193156965451149543

[Keith]

I am sure they have their reasons, even if I cannot fathom it; it is a
large entity that has been making a lot of CF applications. I just am
not privy to their reasons and architecture because I am not actually
on the "development team". I am working for another department on
some pet projects. Unfortunately this particular pet project has to
fit into their existing eco system.

K

[Andrew Scott]

Well the thing is that it can fit in, it doesn't need to use Application.cfm to do that. But if you must use Appliction.cfm there is no reason why you can't, the only problem is that you loose the benefits of all the events like onRequestStart, onSessionStart etc., and not to mention you also loose the fact that Application.cfc is much more thread safe than Application.cfm which is pretty much a requirement for any frameworks these days.

Once you set the Application name to the same as theirs, it will inherit all the Application and session variables, but will not not be able to use any of the functions that they may have in Application.cfm.

I have never seen a standard of using Application.cfm over Application.cfc, that is just weird in itself. I could see more of a use case for a standard to use Application.cfc as a standard over using Application.cfm but they must have a good reason for it.

The question I would ask, if you are in a different department you will have your own standards, but what does it matter what you use as long as it works?

-- 

Regards,

Andrew Scott

WebSite: http://www.andyscott.id.au/

Google+: http://plus.google.com/108193156965451149543

--
You received this message because you are subscribed to the Google Groups "ColdBox Platform" group.
To post to this group, send email to col...@googlegroups.com
To unsubscribe from this group, send email to coldbox-u...@googlegroups.com
For more options, visit this group at http://groups-beta.google.com/group/coldbox

For News, visit http://blog.coldbox.org
For Documentation, visit http://wiki.coldbox.org

[Keith]

They don't actually care what I do, but the only solution they will
give me for the session disappearing is this one; and I have to have
this session.

> > For News, visithttp://blog.coldbox.org
> > For Documentation, visithttp://wiki.coldbox.org

[Andrew Scott]

Well like I said and others will say the same thing, you just need to use the same application name.

So if they have

<cfapplication name="myApplication" />

You use in Application.cfc

this.name = "myApplication";

or

<cfset this.name = "myApplication" />

I assume the application will run in the same server as theirs, which it sounds like if they are asking you to include their application.cfm?

-- 

Regards,

Andrew Scott

WebSite: http://www.andyscott.id.au/

Google+: http://plus.google.com/108193156965451149543

[Keith]

Indeed. I have literally been going back through old documentation
trying to remember how to use the old Application.cfm, it has been
that long.

Any idea where the "argument.targetPage" value comes from? I figured
instead of extending coldbox.system.Coldbox, I would need to use
createObject, that way I can use the reloadchecks() and
processColdBoxRequest() methods. I am just not sure where they are
getting the targetPage value from. I mean, it looks like it is just a
manipulation of the url.

K

[Andrew Scott]

targetPage comes from ColdFusion, when a request is started ColdFusion if there is an Application.cfc will fire the event onRequestStart, or onRequestEnd or onRequest in your Application.cfc and passes the name of the page.

As for ColdBox if you download the full package it has examples of using non inheritance.

So you can do this

component {

this.sessionManagement = true;

this.sessionTimeout = createTimeSpan(0,0,45,0);

this.setClientCookies = true;

// Mapping Imports

import coldbox.system.*;

}

Notice the import!! Also if you are going to use ColdBox that is not stored in the webroot, then you will need to make sure you define the mapping for it as well.

For example

this.mappings["/ColdBox"] = expandPath("../coldbox");

Will grab it from the next directory up, and set that as the mapping.

-- 

Regards,

Andrew Scott

WebSite: http://www.andyscott.id.au/

Google+: http://plus.google.com/108193156965451149543

[Keith]

Andrew,

So here is what my cfm page looks like. It seems to be working
smashingly. Here is the irony, as long as I include their
application.cfm, the session persists no matter what I call my
application. There is something that is really disturbing about their
set up, but you have to work with the cards you are dealt.

<cfapplication name="QAR" clientmanagement="Yes"
sessionmanagement="Yes" />

<cfset cb = CreateObject("component", "coldbox.system.Coldbox") />

<!--- Must include lower level application file in order to persist
the global session variables --->
<cfinclude template="../../application.cfm">

<!--- Reload Checks --->
<cfset cb.reloadChecks()>

<!--- Process Request --->
<cfset cb.processColdBoxRequest()>

[Andrew Scott]

That is because you are defining the application name before the include, so it is switching the name to theirs, which confirms that the session is lost because you are not using the same name in the Application.cfc when you use ColdBox's way of doing it.

Personally, I would go with the Application.cfc and just change the name of the Application to what it should be.

You will also need to remember that any ORM is not able to be used in Application.cfm, and there is also a good chance that some other aspects of the framework might be broken. So rather than trying to fix a problem, that you have ignored right from the start, and then having to deal with any other issue that may pop up, I would just stick with the Application.cfc and just ad the correct name.

Sorry to say this, but if you are not able to see that the session is being held now, and why it is being held. And that the fact that the application name is being over ridden when you include it, then I am bowing out of this thread. I see no use in trying to get it to work with an Application.cfm when all you had to do was change the application name, and this latest post from you now confirms what we told you right from the word go.

-- 

Regards,

Andrew Scott

WebSite: http://www.andyscott.id.au/

Google+: http://plus.google.com/108193156965451149543

[Keith]

After a few revelations, I felt it was only fair of me to let you guys
know the conclusion; especially since it includes an unexpected
behavior.

After much prodding, I was giving access to the code base only to find
out that the information I had been given was incorrect. Every
application was indeed sharing an application name, although all using
Application.cfm rather than .cfc. This allowed me to go back to the
original configuration of coldbox. Here were a couple of things that
were interesting.

1) coldbox.appName does not set this.name, at least not at first load.
Sure, it is obvious when you look at the code, not to mention it
probably wouldn't be possible. It does make me wonder what function
coldbox.appName performs. I would guess perhaps specifically making
coldbox aware of which application is which. Still doing some
investigation on that.

2) I found that if I changed this.name="x" and coldbox.appName="x", I
would run into that exact same issue with session overwriting. The
first page would have the "x" session (according to the debug
information), the second page (which was a form submit to get in to
the app from the welcome page) would have a totally different session
(also according to the debug information).

The good news is, with this.name and coldbox.appName different, it
works perfectly.

[Andrew Scott]

Well to be honest Keith I think it is a no brainer that it had to have an Application name, but you never know what some rouge developers might do.

As for your other questions.

1) No and neither should it either they are two different things. If you think about that problem for a minute you will realise that once ColdBox is running it can't manipulate anything in the Application this scope.

2) if I recall right the appName defined in ColdBox is used for Enterpirse versions, or any version of ColdFusion that uses a context in the URL.

-- 

Regards,

Andrew Scott

WebSite: http://www.andyscott.id.au/

Google+: http://plus.google.com/108193156965451149543

--
You received this message because you are subscribed to the Google Groups "ColdBox Platform" group.
To post to this group, send email to col...@googlegroups.com
To unsubscribe from this group, send email to coldbox-u...@googlegroups.com
For more options, visit this group at http://groups-beta.google.com/group/coldbox

[Keith]

You are absolutely right. I think that was why it was such a
difficult issue for me to try and figure out. Here I was being told
that they definitely didn't share an application name, when that was
the only sensible way of doing it.

Them not being the same makes absolute sense, it was more that I
couldn't figure out what the use of the coldbox setting would be,
since it obviously could affect the "this" scope. The reasons you
mentioned make a lot of sense.

Thank you again Andrew, and everyone else who reached out, for helping
me not feel insane when I was getting misinformation.

Keith

[Andrew Scott]

Your welcome.

-- 

Regards,

Andrew Scott

WebSite: http://www.andyscott.id.au/

Google+: http://plus.google.com/108193156965451149543