Tomcat 7 writing same JSession cookie on browser restart - session

I have the following configuration in tomcat configuration files :
<session-config>
<session-timeout>10</session-timeout>
<cookie-config>
<domain>myapp.mycompany.com</domain>
<http-only>true</http-only>
<secure>false</secure>
</cookie-config>
<tracking-mode>COOKIE</tracking-mode>
<Context path=""
docBase="ROOT"
sessionCookieName="mycookiename"
sessionCookieDomain="myapp.mycompany.com"
sessionCookiePath="/"
useHttpOnly="true"
reloadable="false">
<WatchedResource>WEB-INF/web.xml</WatchedResource>
</Context>
As configured above , the cookie is getting set as "session only" in browser ..and on browser quit its getting deleted as expected. But when I am opening the browser again and hitting my application URL again, same JSESSIONID is getting written to the cookie.
Why is it behaving that way ? Isn't it supposed to write a new jsessionid every time ?

It finally appears that the issue was that in Mac i have to actually quit the browser, rather than hitting its close button ...

Related

How can I eliminate "Content-Language" header from Liberty's response?

WebSphere Liberty and Open Liberty, all version.
I want remove "Content-Language" header from Servlet/JSP response, because of browser translation function accidentally popup. It seems that Liberty adds this header on all response in default, and there is no setting option to prevent this behavior. I've tried response.setLocale(Locale.ROOT); and servlet filter that ignore setHeader/addHeader of Content-language. But I couldn't eliminate the header.
Does anyone have an idea?
There is no direct way to stop or remove the response "Content-Language" header. However, if you set response header "Content-Language" before the response is committed, the server won't change it and retain your setting.
Thanks,
As of Open Liberty 21.0.0.12 you can use the "Configurable Response Headers" support to remove any header you want. See the following blog post for additional details on how to use the feature: https://openliberty.io/blog/2021/11/26/jakarta-ee-9.1.html.
For instance you can do the following in your server.xml:
<httpEndpoint id="defaultHttpEndpoint"
httpPort="9080"
httpsPort="9443">
<headers>
<remove>Content-Language</remove>
</headers>
</httpEndpoint>

How to change the session timeout in Jahia?

I need to change the session timeout in a Jahia application. Which property/file should I change to achieve that? Also will that be valid for edit mode also?
Thank you
The default session timeout can be changed in the file jahia_installation/tomcat/webapps/ROOT/WEB-INF/web.xml
The following configuration has to be set:
<session-config>
<session-timeout>30</session-timeout>
</session-config>
For the users in the edit mode, the session timeout can be set in jahia.properties file under jahia_installation/digital-factory-config/jahia/jahia.properties
# This property sets the session lifetime (minutes)
sessionExpiryTime = 60

Invalidating previous session at Login: JSF 2

I have a filter to be called which finds, after every page is requested if the user & session is privileged and valid respectively. But I want to invalidate the session at beginning, just before the login. Because if someone does not log out it is capturing that session if active, while next login. There is an index.jsp which is redirecting to the page after doing this job. but if the login page is hit directly then it captures the previous session.
LoginManagedBean.java
public LoginManagedBean() {
super(FacesContext.getCurrentInstance().getExternalContext());
System.out.println(FacesContext.getCurrentInstance());
System.out.println(FacesContext.getCurrentInstance()
.getExternalContext());
user = new UserBean();
}
Index.jsp
request.getSession(false).invalidate();
String redirectPage = null;
redirectPage = request.getContextPath()+"/xhtml/login/loginHome.xhtml";
Another problem is although I have index.jsp as welcome-file the "loginHome.xhtml" still opens directly from hitting the context root. Thats when the session invalidation is not happening.
web.xml
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
Thanks.. !!

How to close the session sharing under tomcat7?

I have two host in tomcat:
<Host name="host1.domain.com" .../>
<Host name="host2.domain.com" .../>
I found that when i login host1,which will save a "USER_ID" in session,host2 could also get a "USER_ID" in session.
Does it mean tomcat7 will sharing session under a ?
Then how to disable it, i don't want them share the session.
Each webapp has its own set of sessions that do not overlap with any other webapp. Even if the same webapp has been deployed twice (once under host1 and once under host2), they are considered distinct and the sessions will not be shared.

Proxy config for cross site Ajax (JSON) calls in Websphere Portal 7

First off, I'm new to portal development in general, and thus have no previously experience with Websphere Portal. Note: URLs have been changed to protect the innocent.
I have a portlet on Websphere Portal 7 where I'm trying to make an Ajax call (a POST in this case) to another server. I know I have to create the proxy-config and wire up the ProxyServlet so Portal will allow the cross site ajax call, and I have done that. However, I'm getting a 403 Forbidden message when calling the proxied service.
Here's my proxy-config.xml:
<proxy:proxy-rules
xmlns:proxy="http://www.ibm.com/xmlns/prod/sw/ajax/proxy-config/1.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<proxy:mapping contextpath="/proxy" url="*"/>
<proxy:policy acf="none" url="*">
<proxy:actions>
<proxy:method>GET</proxy:method>
<proxy:method>POST</proxy:method>
</proxy:actions>
</proxy:policy>
<proxy:policy acf="none" url="https://subdomain.domain.org/ss/services/*">
<proxy:actions>
<proxy:method>GET</proxy:method>
<proxy:method>POST</proxy:method>
</proxy:actions>
</proxy:policy>
<proxy:meta-data>
<proxy:name>max-connections-per-host</proxy:name>
<proxy:value>5</proxy:value>
</proxy:meta-data>
<proxy:meta-data>
<proxy:name>max-total-connections</proxy:name>
<proxy:value>100</proxy:value>
</proxy:meta-data>
</proxy:proxy-rules>
Here is the ProxyServlet in web.xml:
<servlet>
<servlet-name>ProxyServlet</servlet-name>
<servlet-class>com.ibm.wps.proxy.servlet.ProxyServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>ProxyServlet</servlet-name>
<url-pattern>/ss/services/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>ProxyServlet</servlet-name>
<url-pattern>/proxy/*</url-pattern>
</servlet-mapping>
And here is the URL that I'm attempting to call from javascript (via jQuery):
"wps/proxy/https/subdomain.domain.org/ss/services/service1"
I'm currently getting 403 Forbidden "The URL you tried to access through the proxy is not allowed" error message. And this is the URL Firebug shows the portlet is hitting (seems to be correct):
http://portalsubdomain.domain.org:77777/wps/proxy/https/subdomain.domain.org/ss/services/service1.
Based on the proxy docs for wp7, I know 403 means one of the following:
The request was not accepted by the proxy, that is the proxy found no matching access policy that grants access to the target server.
Basic authentication failed.
It should've found the proxy policy since I have it defined for all URLs, so what am I missing? I'm figuring I either haven't configured the proxy policy correctly (authentication?) or I haven't constructed the URL in the JSON call correctly. I reviewed the format "rules" but haven't been able to come up with a solution that works.
A couple of things to note:
This portlet is on a child page of another page, and dojo is part of a custom theme we created
We are using LDAP to log into the portal, so not sure if that makes any difference as well. I'm logging in with portal admin rights when running this.
The URL for the page where the portlet is being loaded (and thus the page/space structure) is http://portalsubdomain.domain.org:77777/wps/demoportal/home/demo/ajaxTest. Not sure what the proxy is looking for, but the proxy-config.xml is located within my portlet's WEB-INF folder.
If I change the URL in my JSON call to wps/demoportal/home/demo/ajaxTest/proxy/https/subdomain.domain.org/ss/services/service1, I get the HTML for the ajaxTest page in return.
Found the solution! I needed to get the context path of the portlet and prepend it to the service URL.
Since my service call is in a separate .js file (via JavascriptMVC & jQuery), my quick and dirty fix is to create a JavaScript variable on the .jsp in order to get the portlet context path like so:
var globalRequestContextUrl = "<%= renderResponse.encodeURL(renderRequest.getContextPath()) %>";
then in my ajax call, I prepend the context url to my call to the proxy like so:
globalRequestContextUrl + "https/subdomain.domain.org/ss/services/service1"
Now I'm fighting SSL certificate issues, but I'm definitely getting through the proxy now.

Resources