I launched two different instances of JBoss AS 7.1 on my machine on two different ports and deployed the same application (with the same root context) to both of them. This configuration gave me, deterministically, the following exception as I was doing tabbed browsing with the same browser (either Chrome or Firefox or Conkeror):
javax.servlet.ServletException: viewId:/whatever.xhtml - View /whatever.xhtml could not be restored.
javax.faces.webapp.FacesServlet.service(FacesServlet.java:606)
org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62)
When I was browsing with different browsers things were ok.
Upon further investigation on how different browsers store cookies I discovered that the combination (IP / path) has to be unique to avoid such tabbed browsing problems and that the port does not come into play. I.e. cookies are stored per IP and per path but not per port. So doing tabbed browsing with the same browser on two different applications deployed on the same IP and path (but obviously on separate ports) will result in expired views as the browser mixes up the two sessions. I recognize that my setting is unlikely to arise in a production environment but I would like to ask:
is there any standard that defines this cookie organizing behavior?
are there any best practices one must be aware of in order to avoid session mixups when doing tabbed browsing in multiple JSF applications?
does the javax.faces.STATE_SAVING_METHOD have any bearing on this (in my setting it was set to "server") ?
is there any standard that defines this cookie organizing behavior?
Version 0 cookies (Netscape spec cookies) do not support ports in any way.
Version 1 cookies (RFC2965 spec cookies) supports the Port attribute. If this is absent, then version 0 behavior is used.
The average servletcontainer sets the JSESSIONID cookie as a version 0 cookie. You could theoretically override this by providing a custom "Session Manager" in the servletcontainer. Note that MSIE 9 does still not support version 1 cookies.
are there any best practices one must be aware of in order to avoid session mixups when doing tabbed browsing in multiple JSF applications?
The canonical approach in real world projects is to use a different subdomain (on same port!). E.g. beta.example.com, dev.example.com, update.example.com, test.example.com, etc.
does the javax.faces.STATE_SAVING_METHOD have any bearing on this (in my setting it was set to "server") ?
If you set it to client, then the ViewExpiredException will indeed disappear as the view is not stored in the session anymore, but instead in a hidden field of the form. But you might still face other session-related trouble, for sure if you're storing some stuff in the session, such as session scoped managed beans and the logged-in user.
Related
So now that Chrome has rolled out its newest safety measures against CSRF attacks with ensuring cookies are set w the "samesite" attribute to either lax, strict or none - is there a way to override this new behavior for specific sites? Particularly sites running on the old Azure servers which are sending me cookies without this attribute set and causing all kinds of browsing frustrations whilst using a webapp hosted there. Any ideas?
I have disabled all 3
chrome://flags/#same-site-by-default-cookies
chrome://flags/#enable-removing-all-third-party-cookies
chrome://flags/#cookies-without-same-site-must-be-secure
You don't need to changechrome://flags/#enable-removing-all-third-party-cookies, you can leave this on default. This is just controlling UI currently and does not affect site behaviour.
If you are using a managed version of Chrome, e.g. enterprise enrolled in an organisation that can apply policies, then you can make use of LegacySameSiteCookieBehaviorEnabledForDomainList to specify a list of (as the name implies) domains to retain the legacy cookie behaviour. See: https://www.chromium.org/administrators/policy-list-3/cookie-legacy-samesite-policies
Aside from that, I don't believe there's a built-in way of excluding specific sites from the new behaviour.
At the moment I'm dealing with implementing everything is to be safe against the security risks of the Top 10 Project
For #4 of the Top 10 - Insecure Direct Object References the OWASP refers to the OWASP Application Security Verification Standard
So I was reading all the suff in V3, but I have now some questions implementing it.
I'm using JBoss-AS 7.0.1 with Java EE6 and JSF 2.0
V3.4 Verify that the session id is never disclosed other than in cookie headers; particularly in URLs, error messages, or logs. This includes verifying that the application does not support URL rewriting of session cookies.
I read some articles here on stackoverflow how to avoid that the jesssion is in the URL for the first time a user is visiting the side...
But many answers are like: use the URL rewriting ... what does this means in contrast to the does not support URL rewriting of session cookies
What is the normal way to deal with jsessions on the first entry? What is a save way to handle it?
V3.10: Verify that only session ids generated by the application framework are recognized as valid by the application.
How you do this in JSF2.0 / JavaEE?
V3.12: Verify that cookies which contain authenticated session tokens/ids have their domain and path set to an appropriately restrictive value for that site.
What does this mean? When i look with my Firebug into the the cookie, I run the webapp from the URL http://localhost:8080/projectname/
and in the cookie i get: Path: /projectname
is this what the OWASP means with have their domain and path set to an appropriately restrictive value for that site. ?
Thank you!
V3.4 Verify that the session id is never disclosed other than in cookie headers; particularly in URLs, error messages, or logs. This includes verifying that the application does not support URL rewriting of session cookies.
The servlet container is by default configured to support session tracking by cookies and URLs. The session tracking by URL is also known as "URL rewriting" wherein you see the ;jsessionid=[session id] to appear in URLs. This will be triggered automatically when the client has cookies disabled. To disable tracking by URL, you need to explicitly specify a tracking mode by cookie only. Add this to the webapp's web.xml:
<session-config>
<tracking-mode>COOKIE</tracking-mode>
</session-config>
Further you need to make sure that the JSF code is nowhere printing the session ID to the HTML output by among others <h:outputText value="#{session.id}" />.
V3.10: Verify that only session ids generated by the application framework are recognized as valid by the application.
The servlet container will by default already do that. Only Tomcat 6.x (and inherently thus also JBoss 5.x) had the security issue that when the server-wide session sharing is been enabled, then the server will use exactly the session ID as supplied by the client in the Cookie request header. Tomcat 7.x (and inherently thus also JBoss 6.x/7.x) will not do that anymore. See also among others the Tomcat 6.x <Connector> documentation for some more background information (check the emptySessionPath attribute description).
V3.12: Verify that cookies which contain authenticated session tokens/ids have their domain and path set to an appropriately restrictive value for that site.
The servlet container will by default already do that. Only when you configure the servlet container to use server-wide session sharing (thus, the same session is been shared between all deployed applications), then it violates the rule. See also the previous point.
Please note that most of those rules have very little to do with JSF. They have more to do with general server and webapp configuration. JSF is merely a component based MVC framework.
I have a problem similar to
proof of concept for multiple clients in JSF 2.0
Our application is deployed as a single ear file within the ROOT context in Weblogic. However we need to support multiple client websites on the same application. The client name is appended in the URL e.g. http://myApp/client1/home.jsf , http://myApp/client2/home.jsf .
There is absolutely no problem when the different URLs are accessed from different machine or even different browsers. However when accessed through different tabs in Firefox, they share the data from one application to the other because of the same JSession ID. Is there any way to use custom scoped beans that look at the client URL before creating the session beans.
Having multiple ear files for each application is not an option as we support 100+ client websites. :(
Suitable scopes for this situation are conversation, request and view. Unsuitable scopes are session and (depending on your usage) application. Although CDI doesn't have a view scope, there are a number of 3rd party implementations you can use. (View scope is handy for ajax.)
Conversation scope acts like request scope until a conversation is explicity started. Until you end the conversation, it is tied to the view in which is was initiated, so you can have multiple instances of a conversation scoped bean, one per browser window.
For data security and privacy reasons I want to know why Magento uses two cookies for one frontend session.
All I know is that one of them is being set in Mage_Core_Model_Cookie::set(..) and the other one in Zend_Session::expireSessionCookie(), but still I can't seem to figure out what they are used for.
I just can't think of any reason why one would need a second cookie for the same domain.
I'm going to call this one vestigial code. Varien relies heavily on the Zend Framework as the underpinning for Magento, so many of the classes (Zend_Session for instance) are used as parent classes for Magento implementations.
The Varien-set cookie labeled "frontend" is namespaced for the section of the site you visit (e.g. you will have a separate "admin" cookie if you log in through the backend), whereas the Zend cookie appears to be global.
Also note that I was able to delete the Zend cookie without any apparent deleterious effects (my login session and cart remained accessible, and the cookie was not immediately replaced).
I was able to fix this by reversing the order of the session_start() call and the statement that sets the cookie in Mage_Core_Model_Session_Abstract_Varien::start(..). Those two lines now look like this:
$cookie->set(session_name(), $this->getSessionId());
session_start();
It now only creates one single cookie and it does not seem to have any side-effects.
BTW: The other cookie was not created in Zend_Session as I assumed, but instead both of them came from Mage_Core_Model_Session_Abstract_Varien::start(..).
That is interesting. I just checked on an install of enterprise edition and only "PHPSESSIONID" is set, "frontend" and "admin" are missing even when logged into both. Perhaps this is something still actively being developed.
I found that IE7 maintains same session for multiple tabs in a single browser window and thus doesn't support different sessions for different tabs in a single browser window. My client needs that the application should work perfectly in two different tabs in a single browser window. i think this is because of session and cookie problem. Is there a workaround for this.
Appreciate your help in this regard.
Thanks,
Manoja Swaro
Browser tabs share cookies (and not just in IE, in Firefox and the others as well), and the cookies contain the session ID.
You could switch to cookie-less sessions however this has security and usability concerns. URL based sessions are easily hijacked, and it breaks bookmarking as well, as each page has a unique URL per session.
IE7 doesn't maintain a 'session' as such, you're talking about a cookie with a session ID in it, I would guess. All browsers will have one value for a cookie, it doesn't vary by window/tab.
If you want a session ID to travel with the click trail, you're going to have to pass it from page to page, by (for instance) passing it as a URL parameter and ensuring that you add the parameter to the URL within the page. (Or do without a session.)
The real solution is to change your application so it doesn't assume each session has only one page. An application that can't be open in multiple tabs is broken.
This can be hard if this assumption is already deeply embedded in your code.