Re: XSRF protection using GWT example guide broken for Glassfish/ Jetty using JSESSIONID
GWT team appears to be vry reponsive... :\ I have the same problem and still can't find any solution... Does anyone know how to fix it? maybe I should be setting all cookies with / path and remove invalid cookies bu trying to overwrite it using the same name, also / path but setting date expires to current timestamp? So the path is what I'm considering changing. What you guys think? Thanks in advance for any kind of help. Jan W dniu piątek, 1 czerwca 2012 02:47:28 UTC-4 użytkownik Josh napisał: Hi, I recently re-engineered some custom XSRF/CSRF protection code in my open source GWT-based application to use the new recommended protection introduced in GWT 2.3 as described in https://developers.google.com/web-toolkit/doc/latest/DevGuideSecurityRpcXsrf. Since I develop and deploy mainly in Tomcat all seemed well. However some users of the project deploy to Glassfish and Jetty Java Servlet Containers, both of which immediately started having problems with all RPC calls getting blocked throwing a java.lang.IllegalArgumentException: Duplicate cookie! Cookie override attack? exception. Looking into why, I've determined the problem being JSESSIONID, the session cookie and what GWT recommends to base XSRF token from, is in both application and root path for the host for different reasons, causing the exception to be thrown when the application sees both cookies in scope: (tracked on http://code.google.com/p/webpasswordsafe/issues/detail?id=58) *What steps will reproduce the problem?* 1. Glassfish- visit admin console (http://host:4848/ creates JSESSIONID cookie for / , visit WPS (http://host:8080/WPS creates JSESSIONID cookie for /WPS 2. Although on different ports, cookie spec doesn't care and both instances of JSESSIONID cookie are in scope to WPS, the GWT Google code sees both when it calls getCookie() and throws an exception java.lang.IllegalArgumentException: Duplicate cookie! Cookie override attack? and doesn't allow any requests to work. 1. Jetty- visit one of their sample servlets (i.e. http://host:8080/dump/info creates JSESSIONID cookie for / , visit WPS (http://host:8080/WPS creates JSESSIONID cookie for /WPS 2. Although different contexts, Jetty servlet sets its at root path so both are in scope to WPS, blah blah blah same exception and reason as the Glassfish example above. There is no way to configure the GWT code to ignore the duplicate cookie check without modifying their code. It would be ideal if it just checked for and cared about the cookies defined in the /WPS application context and ignored the others or allowed a way to configure it to call com.google.gwt.user.server.Util.getCookie() passing true (allow duplicates) as the last parameter rather than hardcoding false. Admittedly this may not be possible in the former case, and not completely secure in the later case. But basing this all on the JSESSIONID in real world usage isn't working either. The workaround when I had this same issue when I was rolling out my own XSRF protection code previously to GWT 2.3 was to use a different unique cookie name that basically just duplicated the last JSESSIONID value and set that extra cookie when that session was first created. You'd think if this new way was Google's official documented and mandated way to protect against XSRF, even using JSESSIONID in their example, it would just work out of the box. But clearly not, unless their code was never tested with Jetty or Glassfish. Very surprising. Is there a preferred way to handle this from the GWT team that isn't documented, or is my kludge workaround the only way? Preferably a solution that works for all servlet containers, I know there are Tomcat-specific, Jetty-specific, etc settings to tweak default JSESSIONID behavior but those are not standard and even worse kludges. Thanks for your attention to this and any advice as far as best practices, ~Josh -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: XSRF protection using GWT example guide broken for Glassfish/ Jetty using JSESSIONID
GWT team appears to be vry reponsive... :\ I have the same problem and still can't find any solution... Does anyone know how to fix it? maybe I should be setting all cookies with / path and remove invalid cookies by trying to overwrite them using the same name, also / path and setting date expires to current timestamp? So the path is what I'm considering changing. What do you guys think? Thanks in advance for any kind of help. Jan W dniu piątek, 1 czerwca 2012 02:47:28 UTC-4 użytkownik Josh napisał: Hi, I recently re-engineered some custom XSRF/CSRF protection code in my open source GWT-based application to use the new recommended protection introduced in GWT 2.3 as described in https://developers.google.com/web-toolkit/doc/latest/DevGuideSecurityRpcXsrf. Since I develop and deploy mainly in Tomcat all seemed well. However some users of the project deploy to Glassfish and Jetty Java Servlet Containers, both of which immediately started having problems with all RPC calls getting blocked throwing a java.lang.IllegalArgumentException: Duplicate cookie! Cookie override attack? exception. Looking into why, I've determined the problem being JSESSIONID, the session cookie and what GWT recommends to base XSRF token from, is in both application and root path for the host for different reasons, causing the exception to be thrown when the application sees both cookies in scope: (tracked on http://code.google.com/p/webpasswordsafe/issues/detail?id=58) *What steps will reproduce the problem?* 1. Glassfish- visit admin console (http://host:4848/ creates JSESSIONID cookie for / , visit WPS (http://host:8080/WPS creates JSESSIONID cookie for /WPS 2. Although on different ports, cookie spec doesn't care and both instances of JSESSIONID cookie are in scope to WPS, the GWT Google code sees both when it calls getCookie() and throws an exception java.lang.IllegalArgumentException: Duplicate cookie! Cookie override attack? and doesn't allow any requests to work. 1. Jetty- visit one of their sample servlets (i.e. http://host:8080/dump/info creates JSESSIONID cookie for / , visit WPS (http://host:8080/WPS creates JSESSIONID cookie for /WPS 2. Although different contexts, Jetty servlet sets its at root path so both are in scope to WPS, blah blah blah same exception and reason as the Glassfish example above. There is no way to configure the GWT code to ignore the duplicate cookie check without modifying their code. It would be ideal if it just checked for and cared about the cookies defined in the /WPS application context and ignored the others or allowed a way to configure it to call com.google.gwt.user.server.Util.getCookie() passing true (allow duplicates) as the last parameter rather than hardcoding false. Admittedly this may not be possible in the former case, and not completely secure in the later case. But basing this all on the JSESSIONID in real world usage isn't working either. The workaround when I had this same issue when I was rolling out my own XSRF protection code previously to GWT 2.3 was to use a different unique cookie name that basically just duplicated the last JSESSIONID value and set that extra cookie when that session was first created. You'd think if this new way was Google's official documented and mandated way to protect against XSRF, even using JSESSIONID in their example, it would just work out of the box. But clearly not, unless their code was never tested with Jetty or Glassfish. Very surprising. Is there a preferred way to handle this from the GWT team that isn't documented, or is my kludge workaround the only way? Preferably a solution that works for all servlet containers, I know there are Tomcat-specific, Jetty-specific, etc settings to tweak default JSESSIONID behavior but those are not standard and even worse kludges. Thanks for your attention to this and any advice as far as best practices, ~Josh -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: printing problem: when I print content of my iframe (I use gwt-print-it) all what is left on the right side of printable page is cut off and stays not printed at all
no, I don't want to print double-sided document. let me explain it: imagine you have empty page with just one big image inside 'body' element: body img src=... style=width: 3000px; height: 2200px; / /body lets say it looks like this: http://why.net.pl/tmp/0.png and you want to print WHOLE image. So you'd expect your printer to print something like this: http://why.net.pl/tmp/1_.png but instead of this I'm getting something like this printed: http://why.net.pl/tmp/2_.png so it's not whole image. of course my problem is not about image but very big HTML form that has fixed width and height. This form cannot be resized. Fields on this form cannot be positioned differently, they are positioned with absolute positioning and they have to stay in their places. So my question is: what do I have to do in order to print wide elements that won't fit in one page (when it comes to element's width)? as I previously mentioned I already use gwt-print-it. W dniu wtorek, 18 września 2012 16:36:45 UTC-4 użytkownik jchimene napisał: Are you using @media css? http://www.w3.org/TR/CSS2/page.html#page-selectors On Mon, Sep 17, 2012 at 12:29 PM, Jan Przybylo jan.pr...@gmail.comjavascript: wrote: I print big form that has fixed dimensions. If I'd use Letter parer size it should fit in 4 pages (2 pages wide and 2 pages high). I already started using PrintIt class (gwt-print-it) and it solves most basic problems for me. But when I try to print whole big form it only prints top left as the 1st page and top bottom as the 2nd page leaving the right side not printed. Does anyone know proper way of printing wide big pages? -- -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/O6LWSBf8EE0J. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
printing problem: when I print content of my iframe (I use gwt-print-it) all what is left on the right side of printable page is cut off and stays not printed at all
I print big form that has fixed dimensions. If I'd use Letter parer size it should fit in 4 pages (2 pages wide and 2 pages high). I already started using PrintIt class (gwt-print-it) and it solves most basic problems for me. But when I try to print whole big form it only prints top left as the 1st page and top bottom as the 2nd page leaving the right side not printed. Does anyone know proper way of printing wide big pages? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/Nbf7cUYFL2cJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
