LiftMagicID with Mongo Session Persistence

[Ryan Cino]

I'm currently upgrading to Jetty 9.4, which has changed up its Session Management, and I'm currently working to implement Jetty's Mongo Persistence to make use of ContainerVars across server restarts and server clustering.

However, mongo persistence continues to fail, because Lift, in HTTPServletSession, uses:

 private val LiftMagicID = "$lift_magic_session_thingy$"

Was wondering if there was any way we could overwrite this value, since Mongo blows up when trying to set that in the db with the leading "$".

Thanks in advance,

Ryan

[Matt Farmer]

Hey Ryan,

I did some investigation into ways to route around this. It looks nontrivial, but doable. You'd have to:

1. Provide a custom implementation of HTTPServletSession that changes this value.
2. Extend HTTPRequestServlet such that "def session" returns your new HTTPServletSession.
3. Extend LiftFilter and override doFilter to create your custom request type instead of the one we use.
4. Change your web.xml to use your new LiftFilter.

This certainly isn't ideal at all. I think that ideally we'd provide a LiftRule that would let you change any value that gets sent to the underlying ContainerSession. I'm going to noodle this for a bit and file a ticket on our end, but I don't see us being able to ship that before Lift 3.2.0-M2 in the middle of September.

Have you looked at potentially tweaking how Jetty's Mongo Persistence works? Is that a library or built in to the core? If it's a library, it might be a sensible change to sanitize those IDs before trying to write them.

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matt Farmer]

Oh, it's also worth noting that you could, potentially, do some wizardry with Java reflection to get around the encapsulation. I'm not sure I would recommend that route, but it is theoretically possible.

[Matt Farmer]

Unless there's significant objection here, I'm going to create a ticket to add a LiftRule to change what this magic value is. =)

[Matt Farmer]

Issue here: https://github.com/lift/framework/issues/1894

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.

[Matt Farmer]

I've confirmed my PR is capable of resolving the bug! Woohooo!

Issue here: https://github.com/lift/framework/issues/1894

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.