i'm trying out lucee light docker images and i'm a...
# lucee
j
i'm trying out lucee light docker images and i'm already using the ortus redis extension. i'm getting
cache [session] is not enabled to be used as a session/client storage, you have to enable it in the Lucee administrator.
i went to check on the configuration in the lucee admin and saw this: https://gist.github.com/jamiejackson/f700efc410e9b708ea80b76076aae58d (attn: @bdw429s)
does it have an implicit dependency on another extension, or something like that?
i think it does. at least the admin form part of it. i guessed that it wanted the ESAPI extension so i installed it and the form now shows up. it tells me my license isn't activated, so i can chase that issue down, now.
actually, the
server
admin tells me there's no license, but the
web
admin shows it's okay. i think that's actually all expected. however, i'm still getting
cache [session] is not enabled to be used as a session/client storage, you have to enable it in the Lucee administrator
.
b
Yes, our extension assumes the ecodeForXXX() functions will be available. Unfortunately, Lucee doesn't provide any official mechanism for an extension to have dependencies.
@lmajano @jclausen perhaps we should remove our use of the ESAPI extension in the Redis cache so it can work on Lucee Lite and roll our own HTML escaping for the form.
@jamiejackson Regarding the error
cache [session] is not enabled to be used as a session/client storage,
that is pretty straight forward. Have you checked what the error suggests?
It is up to you to create your cache with the storage flag set to true. This is a Lucee restriction.
l
I would have to check. Maybe it’s in the cfml plug-in code
b
Yes, that is where it is
Personally I think the admin itself should have a dependency on ESAPI because Lucee itself needs to protect against XSS. But that's food for @zackster to consider. That way any Lucee extension using an admin plugin can safely assume it is present
j
The session setup code (which has worked for months) hasn't changed. The only thing that's changed is me trying the light image. I'll keep looking into it on Monday. By the way, a third alternative would be to make the ESAPI stuff native. I'm away from my machine now but I'm pretty sure my code needs it, as well. IIRC, it provides important functionality to fix weak native functions. Is that a correct characterization?
b
The session setup code (which has worked for months) hasn't changed
Hmm, I'd guess there is another error related to an extension dependency and the error is getting swallowed. Check the logs for any clues
j
Seems like maybe another vote in the direction making ESAPI native (attn: @Adam Cameron). https://cfml.slack.com/archives/C06TA0A9W/p1692717843781139?thread_ts=1692703542.434609&cid=C06TA0A9W
interested in LAS's take, @zackster
z
being an extension means we can rollout security updates out of band plus lots of people are running older versions of lucee which wouldn't be updated If you decided to roll your own distribution of lucee with light, it's up to you to look at the standard bundled extensions and decide which ones you don't need Every function which comes from an extension is clearly labeled as such on Lucee Docs https://docs.lucee.org/reference/functions/esapiencode.html
j
I will remove that ESAPI dependency on the next release.
👍 1
z
or just do an ExtensionExists() with a fall back or fail nicely
j
@zackster, those are good arguments, thanks.
TIL:
extensionExists()
exists
b
@jamiejackson
extensionLIst()
also returns a query object of installed extensions
I use it all the time from the CLI to see what's installed there like so
Copy code
#extensionLIst | printTable