I have a tomcat 8 server in which i have two web app. I want to give access to both application by authenticating once an user.
I did it by setting sessionCookiePath="/" in catalina/conf/context.xml like this :
<Context useHttpOnly="false" sessionCookiePath="/">
Now the problem i am facing is tomcat is not changing session ID anymore. I got a warning message.
Warn org.springframework.security.web.authentication.session.SessionFixationProtectionStrategy - your servlet container did not change the session id when a new session was created
On the link, it is said that tomcat is taking care of that by default.
http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection
How can i fix it ?
Thanks
Yes, this is expected behaviour. The documentation hints at this but
does not make it explicitly clear.
Setting sessionCookiePath="/" is treated as a special case to support
portlet implementations. Once one web application obtains a session all
subsequent sessions for any web application also configured with
sessionCookiePath="/" will always get the same session ID. This holds
even if the session is invalidated and a new one created.
If a set of web application operates in this mode, changing the session
ID is a lot harder. You'd have to write a custom Tomcat component to do
it for you and even then I'm not sure that you can guarantee a smooth
change over.
Related
My MVC application connects in Oracle database. We created a lot of triggers to save all data changed by users.
inside the trigger, we used the code bellow to get authentcated user:
UPPER(SYS_CONTEXT('USERENV', 'OS_USER'))
When i'm running my application in localhost, the database get the correct user, but when i plublish it on server (IIS), the database always get as user the application pool name.
Is there some IIS configuration that i need to set to get "Windows authentication" user? Is there another way to get this information inside oracle function/trigger?
You would realistically want to use a secure application context which is basically a user-controlled context unlike the system-controlled USERENV context. When the application code gets a connection from the pool, it would call a stored procedure that sets the application username in the new application context. Your triggers would then reference the new context rather than USERENV. Your application needs to ensure that the context is set appropriately every time a connection is acquired from the pool-- if the application fails to set the context correctly, your triggers will get the wrong information.
If you don't want to create your own context, you could use the CLIENT_IDENTIFIER in USERENV which you can set via dbms_session whenever you get a connection from the pool. Functionally, this is basically identical to creating your own context. The nice thing about creating your own context, though, is that you can seamlessly add attributes in the future as you identify the need (i.e. adding the IP address of the client browser or a tier attribute if you have gold, silver, and bronze customers).
There are alternate ways to approach the problem such as using proxy authentication. In general, though, that's not going to work as well with connection pools particularly when you have very large numbers of users.
I have a webapp deployed successfully in Jetty webserver.
The webserver responds to requests fine.
When I access the app it renders the home page.
Recently I noticed that when I don't use the app for certain period of time it breaks somehow. The period is somewhere around 2/3 weeks.
When I access the webapp after 2/3 weeks of idle I receive this output.
If I try to access any other link, i.e. the login page (/login.faces) I receive:
Problem accessing /error/not-found.faces. Reason:
/error/not-found.xhtml Not Found in ExternalContext as a Resource
which normally used to work before idling.
If I restart the webserver everything returns to normal and works fine. There are scheduled tasks set which make the app interact every day with database. (There is a scheduled task for fetching currency rates via webservice).
Therefore, my question is what would be the cause which breaks the site and makes it unavailable after idling? Is this a webserver (jetty) issue? Am I missing any setting which is crucial?
FYI, the project structure is: Java with Spring, Hibernate, JSF (PrimeFaces) and Jetty
This occurred due to permissions in CentOS.
If anyone faces the same issue make sure to check the logs have appropriate permissions to read and write
I am using Tomcat 7.0, Spring 4.0.2, Web Module 3.0 in eclipse for my web application.
And I configured my session timeout in app/web.xml as well as tomcat/conf/web.xml.
<session-config><session-timeout>10</session-timeout></session-config>
I am sending one request called captureLastActiveTimeForCurrentFile after every 5 mins.
I need to ignore one request (suppose, captureLastActiveTimeForCurrentFile) from updating lastAccessedTime of session.
According http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Sessions (org.apache.catalina.core.StandardHostValve.ACCESS_SESSION) default behavior of tomcat is : every request that is associated with a session will cause the session's last accessed time to be updated if the request explicitly accesses the session.
I am not accessing session explicitly from request (HttpServletRequest object) captureLastActiveTimeForCurrentFile. So According to my understanding tomcat should invalidate session after 10 min from any request done which is accessing session explicitly. But In my case tomcat never invalidate session because I am sending captureLastActiveTimeForCurrentFile after every 5 mins. But according to docs it should be. Can Anyone help me to understand what is happening here? Thanks in advance.
EDIT : I found some discussion regarding this topic here. But still I am not getting actual problem.
I have several tomcat instances running in physically independent machines.
I want to configure the tomcat to share sessions between this instances.
I have tried to configure org.apache.catalina.session.PersistentManager from http://tomcat.apache.org/tomcat-6.0-doc/config/manager.html. But I only see the session file when I shutdown the tomcat instances and I don't know if the instances are sharing this session. I think not. Because It doesn't make sense if tomcat writes down the session only on shutdown.
The other thing that I found is the cluster-howto but I can't do that couse the machines can't see eachother. They only shares a storage path to use.
Other thing that I think I can do is to implement a manager but it seems a litle bit tricky.
I have to add that I am using tomcat for deploying grails war files and I am using the grails session. I thing it has something to do with Spring
So, the question is: What is the best thing you think I can do to accomplish more effectibly the task? Or maybe I am missing something? Can you give me any pointer?
You have the F5 Big IP doing the load balancing in front of the tomcat servers, so it will handle the sessionID for you by sending you back to the correct Tomcat server. Use the sticky-round-robin algorithm.
As per the usecase in your comments -
What I am trying to do is to save some
data in session, then redirect to a
login server, who in a success
scenario it redirects to my servers.
And my concern is what happend if the
load balancer redirects the request to
the server that doesn't previously
saved the needed data in session.
Maybe sticky session is what I need.
So: can I configure sticky session in
a non tomcat-cluster enviromnent?
At the successful login - you redirect back first to the BigIP. It will pick up the sessionID from the browser. It will send you to the correct Tomcat and you should be able to retrieve the session data.
If not, looks like you need to store the "sessionID" itself against some "user Id" in a database but thats a bad design. I think the former should work
I have a Spring 2.5.6/Flex application setup and running with Spring Security 2.0.4. Recently a load balancer (A Foundry ServerIron 4g http://www.foundrynet.com/products/a...ems/si-4g.html) was put into place and now I am getting cross domain errors. Basically the load balancer is firing off a request to myloadbalancer.abc.com and myrealserver1.abc.com is being returned as the domain name. Spring security is forwarding the request to the real server somehow. How can I get around this?
Also the ConcurrentSessionFilter is no longer working. The application is set up to disable concurrent logons, but this functionality stopped after the application was put behind the load balancer. I believe there are multiple Oracle Application Servers being clustered together as well. I have never dealt with clustering or load balancers before and I wasn't aware that the software had to be written differently in certain areas.
These sound like separate issues to me, but I need help for both.
Concerning your second problem:
If the ConcurrentSessionFilter stopped working (i.e. does not prevent concurrent sessions anymore), that could be due to clustered application containers with sticky sessions.
In such a setup, each of the cluster's nodes works independently and doesn't share state with other nodes. Instead, the load balancer makes sure that existing sessions will always be served by the same node.
Now Spring Security's ConcurrentSessionController works by mapping sessions to principals. The controller itself relies on the HttpSessionEventPublisher sending ApplicationEvents on start and termination of user sessions.
Everything is will work fine if someone intending to open more than one session ends up on the same node he already has a session opened. HttpSessionEventPublisher informs the concurrent session mechanism of the session's creation and authentication will fail because there is already a session associated with this user. On a different node however, there is no session for that user yet, so ConcurrentSessionController does not complain and login succeeds.
Fortunately, solving the problem should be easy: Implement your own SessionRegistry and use a shared data store for all nodes (e.g. the application's database).