Can these properties used to disable the session mechanism completely?
server.session.persistent=false
server.session.timeout=0
If not, how to do this?
had success with setting it to an empty set: server.servlet.session.tracking-modes=
#see https://docs.spring.io/spring-boot/docs/2.2.0.RELEASE/reference/htmlsingle/#server-properties
#see https://docs.spring.io/spring-boot/2.2.0.RELEASE/current/api/org/springframework/boot/web/servlet/server/Session.html#setTrackingModes-java.util.Set-
try type in application.properties:
spring.session.store-type=none
...to disable spring session
See: https://docs.spring.io/spring-boot/docs/2.2.0.RELEASE/reference/htmlsingle/#boot-features-session
A couple of notes for posterity:
Persistent sessions are sessions that survive server restarts, thus, when you enable that, Spring will serialize and store your session somewhere to load it later.
For a complete discussion on how to reliably disable sessions, please see this post: Can I turn off the HttpSession in web.xml?
Related
As long as I know the duration of the default session is 30 mins and I
wanna change this for my specific flow that I created using Spring
Webflow? My question is How can i achieve this?
I have researched and found some interesting articles and solutions but none of them seems to work for me and also their solution not straightforward
To change a single request's session we should set HttpSession's setMaxInactiveInterval right? So if it is, How and Where I should set it? IN SPRING WEBFLOW?
HttpSession session = request.getSession();
session.setMaxInactiveInterval(10*60);
To get to the raw HttpSession in Web Flow, you need to use the ExternalContext. Like this:
((HttpServletRequest)
RequestContextHolder.getRequestContext().getExternalContext()
.getNativeRequest())
.getSession())
https://docs.spring.io/spring-webflow/docs/current/api/org/springframework/webflow/context/ExternalContext.html#getNativeRequest--
So I already success implement SSO using spring session and redis on development localhost domain.
But when I deploy to server using two sub domain.
login.example.com
apps.example.com
They always create new session Id on each sub domain.
I already try to configure using Context in tomcat configuration.
<Context sessionCookieDomain=".example.com" sessionCookiePath="/">
But no luck.
Spring session moves the session management on application level, so no surprise that trying to configure the container (in your case tomcat) has no effect. Currently there is a TODO in spring-session code to allow setting the domain, but is not implemented.
Maybe it is best to open an issue to allow setting the domain or comment/vote on https://github.com/spring-projects/spring-session/issues/112.
Meanwhile a workaround would be to go with your own implementation of MultiHttpSessionStrategy based on CookieHttpSessionStrategy.
Finally I succeeded to setdomain on application level.
You're right, I hope in the future they implement the feature to set domain.
For now I create CustomCookieHttpSessionStrategy for my own implmentation.
private Cookie createSessionCookie(HttpServletRequest request,
Map<String, String> sessionIds) {
...
sessionCookie.setDomain(".example.com");
// TODO set domain?
...
}
And then register bean as HttpSessionStrategy.
I use to hibernate before and I require an opensession to use Hibernate.Initialize()
but apparently for Spring, if OpenSessionInViewInterceptor is set up properly, it can use Hibernate.Initialize() anywhere.
My question is, what must I setup to use Hibernate.Initialize() in JUnit?
The whole point of OpenSessionInViewInterceptor is precisely to leave the Hibernate session open until the view has been rendered. This is why you can call Hibernate.initialize() "anywhere": Spring doesn't close the session until the request has been completely handled by the view.
So the answer is always the same: to be able to call this method, the session must be opened.
So we're using spring-security-redirect as a parameter in the form that is sent to j_spring_security_check, in order to send the user to the correct page after a successful login. Migrating from Spring security 3.0 to 3.1, this stopped working. We use a subclass of SavedRequestAwareAuthenticationSuccessHandler, overriding onAuthenticationSuccess(), and debugging that method I see that getTargetUrlParameter() returns null. isAlwaysUseDefaultTargetUrl() returns false.
Browsing around I can't find anyone having similar problems... I find some references to AbstractAuthenticationTargetUrlRequestHandler.DEFAULT_TARGET_PARAMETER, which seems to have disappeared in 3.1.
Any ideas?
As per Spring security 3.1 xsd,
Attribute : authentication-success-handler-ref
Reference to an AuthenticationSuccessHandler bean which should be used to handle a successful authentication
request. Should not be used in combination with default-target-url (or always-use-default-target-url) as the
implementation should always deal with navigation to the subsequent destination.
So, in your subclass, you have to perform the redirection.
I'm looking to disable jsessionid from being used in the https headers.
Is there a way to turn this off or disable this being set as a cookie in tomcat 7?
I either want the jsessionid to arrive embedded into a GET method url name value pairs or to be part of a POST request name value pairs.
I know all the advantages and disadvantages of using cookie based sessioning and url rewriting but I have specific needs for specific impl of restful web services.
I need tomcat 7 to accept jsessionid without using the http header: jsessionid.
Thanks.
UPDATE:
so I looked around some more and found this which is implemented using the web.xml conf.
However the following doesn't seem to work with Tomcat 7.
<session-config>
<tracking-mode>URL</tracking-mode>
</session-config>
is it a case of TC7 not fully implementing the servlet 3.0 spec?
The web.xml setting works for me with Tomcat 7.0.20.
Log and check the effective (and maybe the default) session tracking modes:
logger.info("default STM: {}" , servletContext.getDefaultSessionTrackingModes());
logger.info("effective STM: {}" , servletContext.getEffectiveSessionTrackingModes());
Maybe your app override somewhere in the code the session tracking modes. An example:
final Set<SessionTrackingMode> trackingModes =
Collections.singleton(SessionTrackingMode.COOKIE);
servletContext.setSessionTrackingModes(trackingModes);
Check ServletContext.setSessionTrackingModes() calls in your code.
It's also possible to set default session tracking modes in the Tomcat's context settings but I found that web.xml settings override them.