-
Notifications
You must be signed in to change notification settings - Fork 6k
Add Jackson Support for Objects stored in HttpSession #3736
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@rwinch as per my understanding, you want put serialized SecurityContext into session. i. e. Instead of storing whole SecurityContext object, a serialized json string will be stored in session. Please correct me if my understanding is wrong. |
@jeetmp3 Thanks for reaching out! For now I would focus on ensuring we can serialize and deserialize any Spring Security objects that go into session with Jackson. This will help enable users to write hooks to serialize Spring Security with JSON. After that we can add hooks in Spring Security that uses the the serialization mechanisms. |
@rwinch For now only mix-in classes for Spring Security objects will be added right ? |
@jeetmp3 Correct. Pretty much the work you have already done in the Spring Session Sample you added. |
@rwinch let me know when you verified those sample mixins, so that i can start adding those mixins classes into security. |
Once again thank you for your contribution. I was able to verify the mixins and they look pretty good from my perspective.
|
@rwinch thanks for the feedback! I'll start working on tests. Other then |
@rwinch I've updated all the tests. Should we start merging these mix-ins into spring-security? |
@jeetmp3 Thanks for the response! Yes I think we should try and get a separate Pull Request open for merging the Mixins. Thanks again for all your efforts with this :) |
@rwinch thanks for the quick response! Just wants to confirm, should i add these mix-ins in one specific module or in target class specific module ? |
Here are my thoughts, but feedback welcome. We should add them to the module that the class they serialize belongs to. For example I would place them within a package named base-package.jackson. For example, |
Previously the JSON modules didn't use Spring's Assert. This commit changes the assertions to use Spring's Assert and does some minor restructuring. Issue gh-3736
Use package scope when possible Issue gh-3736
Issue gh-3736 * ClassLoader argument - this is required because we do not want to assume the ClassLoader that should be used * Clean up logging - logging is now at debug level because we don't expect all of the modules are loaded (they are quite possibly off the ClassPath) * Remove ObjectUtils as it was being used on methods that expect a Collection or Array with non collection based objects * Polish Javadoc warnings
JSON UserDetails null use to be treated as "". This changes null to be treated as a null Issue gh-3736
Previously the JSON tests unnecessarily had MockitoJUnitRunner. This commit removes MockitoJUnitRunner from the JSON tests. Issue gh-3736
This improves the readability of the JSON strings used for testing JSON serialize / deserialize of Spring Security Issue gh-3736
Closed via #3812 (comment) |
Hi @rwinch , I tried this feature on my application. A following error is occurred when load a security context from a Redis server.
Log is:
|
@kazuki43zoo Thanks for the report! I fixed this in #4120 |
Can I modify SpringSecurityCoreVersion.SERIAL_VERSION_UID to make new and old versions compatible |
It would be nice to provide custom serialization mechanism that uses Jackson for objects Spring Security places in session. This would make serializing much faster and ensure consistency when using things like Spring Session. Some of the interfaces (and classes) are:
We might also try to provide compression on the serialization. For example when UserDetails is the principal of an Authentication, we can derive a UsernamePasswordAuthenticationToken from the UserDetails and assume SecurityContextImpl is used.
UPDATE spring-projects/spring-session#434 has must of the support we would need for this feature. We may want to merge those changes into Spring Security
The text was updated successfully, but these errors were encountered: