Flash messages with session key prefix

[janko]

Today I recorded a live stream, where I was adding an admin account type to a demo Rails app, to be used in a separate admin section. Since these were two completely different types of users, I wanted to keep the authentication states separate, so I configured session_key_prefix "admin_".

However, what I didn't expect was that this prefix will also be applied to flash keys, so now instead of :notice and :error, flash messages for admins were saved in :admin_notice and :admin_error, which was undesired. While I wanted to keep session states separate, I naturally still want to have a shared flash. Flash messages disappear on the next request, so there is no need to keep them separate, and I then get to reuse the same flash rendering logic.

I was considering potential changes for not applying the session key prefix to flash messages, but I couldn't find any straightforward path. Another idea that came to mind is introducing session namespaces, where main configuration uses session[:account_id], but :admin configuration would use session[:admin][:account_id] (or we'd use session[:"rodauth"][:account_id] and session[:"rodauth.admin"][:account_id]). What do you think?

[jeremyevans]

I'm guessing session_key was used for the flash notices due to how it handles the conversion to string if the :sessions_convert_symbols Roda app option is set. I wasn't considering the session key prefix when doing so, and agree it is unexpected and undesired.

Removing the session key prefixing from flash messages is a backwards incompatible change. My guess is in cases like yours, removing the prefixing would fix more cases than it would break. However, for cases where the session key is used without multiple Rodauth configurations, it's likely such a change will break code that expects the prefixing.

Taking that all into consideration, I think it's best to bite the bullet and break backwards compatibility here. The flash key prefixing is definitely a bug, and we should fix it even if it causes some code to break. I'll work on that shortly.

[janko]

Thank you for you input, I was thinking the same, that it's worth breaking backwards compatibility in this case 👍🏻

[jeremyevans]

Fix committed at 4dbb4fc

[janko]

Thanks a lot 🙏🏻