faces/FlashSecretKey and faces/ClientSideSecretKey are missing in spec

[BalusC]

As per eclipse-ee4j/mojarra#5552 I found out that predefined JNDI variables faces/FlashSecretKey and faces/ClientSideSecretKey are nowhere mentioned in https://jakarta.ee/specifications/faces/4.0/jakarta-faces-4.0.

I wonder if these should be mentioned in the Faces spec at all?

@tandraschko How exactly does MyFaces deal with encrypted Flash state and Client Side state across server restarts without session persistence and/or across distributed systems? The goal is of course that any encrypted Flash state and/or Client Side state needs to be decryptable after server restart and/or on a different server with same session. I scanned for these JNDI variables in MyFaces source code but I couldn't find any.

[tandraschko]

i dont think we use JNDI here for something.
user must configure the secrets via web.xml to allow all of that

[BalusC]

Ok, probably we should align and set in stone in spec.

JNDI has the advantage that it's overrideable from within server config without rebuilding the WAR, like as currently already specced for jakarta.faces.PROJECT_STAGE. JNDI vars are also settable in web.xml as <env-entry>.

[tandraschko]

Maybe its a good point to rely on Jakarta config?
It has all the stuff like jndi, env vars and so on?

[BalusC]

That's indeed a nice opportunity.

cc: @arjantijms

[tandraschko]

I would personally also just see the @FacesConfig as marker (maybe more as @FacesBootstrap), without all those params. But likely only my opinion :)

[BalusC]

Fair point. That new API has by the way the primary goal to have an enumeration of context params provided by public API rather than that they "need" to be defined on @FacesConfig (so that e.g. Spring Boot / Quarkus people don't need to hardcode these and/or to retrieve configured/default values). It's just that the @FacesConfig was already there and that it would make sense to be able to set context params on it. Spring Boot / Quarkus people could in long term even reuse it.