What's the best way to figure out if sessions are ...
# lucee
a
What's the best way to figure out if sessions are on? I know the top-level Application.cfc knows it, but if I'm down in the weeds of a template and I touch session-scope, I get zapped. Can I do better than just catching that exception? Is adding a request-scope flag up in Application.cfc's onRequestStart the best I can do?
r
Are you talking about the session struct randomly getting cleared out when traversing pages or just wondering if a variable is already set in the scope when you are in a template? If it's the second - you should either param the variable to a default that works for your business logic OR you need to do an if StructKeyExists() for the specific variable you are going to use in your logic before you try to reference it. Typically if a session scoped variable is missing - it means the user didn't authenticate or things timed out and they need to be sent back to the start of the process.
a
No, session isn't like other scopes -- if session management isn't turned on, you can't test session, because that's not valid, it's not a "use structkeyexists" situation. For various reasons I had a bit of code that was interested in certain contents of the session scope, if they were available, but was happy to run in other parts of the infrastructure that didn't have sessions turned on.
r
then do a try/catch and try to test for the session scope. if it errors into the catch, sessions are not on.
b
If you look at ColdBox, we have some session detection and it's different between CF engines :)
I think in one engine, we use
isDefined( 'session' )
and for another engine we use
getApplicationMetadata()
a
That's enough for me to test with. Thanks!
b
Right on, this might help too. <cfscript> try{ myvar = session.myvar; } catch( any e ){ myvar = ""; dump(e.message) }; </cfscript>
b
I wouldn't recommend the try/catch approach for any sort of production load. There's noticeable overhead in creating an exception
b
True, I could be wrong, but I think he was just fact finding.
b
In that case, just use it and look for an error, lol
He actually asked for a method to test without catching an exception in his OP
Can I do better than just catching that exception?
On that note-- if this is something you'll want to check over and over, I do recommend setting a request -level variable in your application.cfc
I helped a client with this recently. We disabled sessions just for the API portions of their app, and then it turned out there was some performance issues (this was LUcee) with the isDefined() approach under very heavy load. So we just checked it once and then set a request var which he used everywhere else
a
That's what I was arriving at, if the right answer was "glomf some metadata object that's I-don't-know how expensive to build".
b
the getApplicationmetada() BIF performed terribly under load when the same client used it. Lucee does some try/catch crap behind the scenes for every call.
I can't speak to how Adobe does it, but generally there's a LOT of info returned form that BIF which isn't necessary just to check one flag if you're doing it a lot
but if you're actually toggling the session management in your application.cfc based on the request (like my client was doing) then you don't even need to test it. Just set the request variable at the same time you toggle the session and be done with ti
a
Sticking
REQUEST.LiveSessions = this.sessionManagement;
in onRequestStart is sounding like the kindest answer.
👍 1