CSRF error due to url-rewrite (cookie-path, contextPath)

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

CSRF error due to url-rewrite (cookie-path, contextPath)

Todd Java
I'm picking-up where the following thread stopped -

Java.net @
https://java.net/projects/dwr/lists/users/archive/2011-09/message/100

Nabble @
http://dwr.2114559.n2.nabble.com/CSRF-error-when-using-more-than-1-tab-
in-browser-td6776437.html

!! Please read that thread for the necessary background information.

-----------------------------------------------------------------------
--------

Now fast-forward to DWR 3.0.0-rc3
  * SVN rev - trunk @ #4032
  * Bamboo build #514

We experienced the same problem due to the fact that our servlet
contextPath is "/codename" but our public-facing urls do not
contain/expose this path. Our Tomcat servlet sits behind Apache, which
we have configured with url-rewrite rules that direct requests to the
proper location.

The answer as to why we do this is quite long, but it amounts to the
desire to shorten and beautify public-facing urls by removing our
internal project codename.

Support for url-rewriting was partially addressed in 3.0-rc2 by the
following Jira issue -
        "Unable to override context path for static engine.js"
        http://directwebremoting.org/jira/browse/DWR-197

The changes for DWR-197 allow us to override "pathToDwrServlet" in
engine.js, which controlls the url end-point where DWR requests are
made. While this is quite helpful, it only constitutes partial-support
for url-rewriting in my opinion. The missing piece is giving users the
ability to override the contextPath (and thus the cookie-path) as
determined on the server-side.

In order to fix this problem, we made the following changes in
engine.js -
        /** The webapp's context path (used for setting cookie path) */
        if (typeof dwrContextPath != "undefined") {
                dwr.engine._contextPath = dwrContextPath;
        }
        else {
                dwr.engine._contextPath = "${contextPath}";
        }

We are then defining "dwrContextPath" in our javascript code prior to
loading engine.js
In our case, we're defining it as root "/".

This approach is quite similar to the fix made for DWR-197. The js
piece of the fix in engine.js looks like this -
        /** The default path to the DWR servlet
         *  pathToDwrServlet is aids cross-domain. If pathToDwrServlet
         *  is defined before engine.js is included pathToDwrServlet
will
         *  be used.
         */
        if (typeof pathToDwrServlet != "undefined") {
                dwr.engine._pathToDwrServlet = pathToDwrServlet;
        }
        else {
                dwr.engine._pathToDwrServlet = "${pathToDwrServlet}";
        }

Anyhow, just wanted to get feedback on this approach and see if you
guys think it's worthwhile to submit a patch, or whether my approach is
too hacky. I was thinking it might be best to take the same approach as
the "overridePath" init-param -
       
http://directwebremoting.org/dwr/documentation/server/configuration/ser
vlet/index.html

Thanks all,
Todd
Reply | Threaded
Open this post in threaded view
|

Re: CSRF error due to url-rewrite (cookie-path, contextPath)

david@butterdev.com
Thanks Todd.  I know Mike has put some thought into this very issue so
he may have a better recommendation for you.

On 05/30/2013 02:28 PM, [hidden email] wrote:

> I'm picking-up where the following thread stopped -
>
> Java.net @
> https://java.net/projects/dwr/lists/users/archive/2011-09/message/100
>
> Nabble @
> http://dwr.2114559.n2.nabble.com/CSRF-error-when-using-more-than-1-tab-
> in-browser-td6776437.html
>
> !! Please read that thread for the necessary background information.
>
> -----------------------------------------------------------------------
> --------
>
> Now fast-forward to DWR 3.0.0-rc3
>    * SVN rev - trunk @ #4032
>    * Bamboo build #514
>
> We experienced the same problem due to the fact that our servlet
> contextPath is "/codename" but our public-facing urls do not
> contain/expose this path. Our Tomcat servlet sits behind Apache, which
> we have configured with url-rewrite rules that direct requests to the
> proper location.
>
> The answer as to why we do this is quite long, but it amounts to the
> desire to shorten and beautify public-facing urls by removing our
> internal project codename.
>
> Support for url-rewriting was partially addressed in 3.0-rc2 by the
> following Jira issue -
> "Unable to override context path for static engine.js"
> http://directwebremoting.org/jira/browse/DWR-197
>
> The changes for DWR-197 allow us to override "pathToDwrServlet" in
> engine.js, which controlls the url end-point where DWR requests are
> made. While this is quite helpful, it only constitutes partial-support
> for url-rewriting in my opinion. The missing piece is giving users the
> ability to override the contextPath (and thus the cookie-path) as
> determined on the server-side.
>
> In order to fix this problem, we made the following changes in
> engine.js -
> /** The webapp's context path (used for setting cookie path) */
> if (typeof dwrContextPath != "undefined") {
> dwr.engine._contextPath = dwrContextPath;
> }
> else {
> dwr.engine._contextPath = "${contextPath}";
> }
>
> We are then defining "dwrContextPath" in our javascript code prior to
> loading engine.js
> In our case, we're defining it as root "/".
>
> This approach is quite similar to the fix made for DWR-197. The js
> piece of the fix in engine.js looks like this -
> /** The default path to the DWR servlet
> *  pathToDwrServlet is aids cross-domain. If pathToDwrServlet
> *  is defined before engine.js is included pathToDwrServlet
> will
> *  be used.
> */
> if (typeof pathToDwrServlet != "undefined") {
> dwr.engine._pathToDwrServlet = pathToDwrServlet;
> }
> else {
> dwr.engine._pathToDwrServlet = "${pathToDwrServlet}";
> }
>
> Anyhow, just wanted to get feedback on this approach and see if you
> guys think it's worthwhile to submit a patch, or whether my approach is
> too hacky. I was thinking it might be best to take the same approach as
> the "overridePath" init-param -
>        
> http://directwebremoting.org/dwr/documentation/server/configuration/ser
> vlet/index.html
>
> Thanks all,
> Todd
>

Reply | Threaded
Open this post in threaded view
|

Re: CSRF error due to url-rewrite (cookie-path, contextPath)

Mike Wilson
Administrator
Hey guys,
I'll look into this after the weekend ;-)
Best regards
Mike

David Marginian wrote:

> Thanks Todd.  I know Mike has put some thought into this very
> issue so
> he may have a better recommendation for you.
>
> On 05/30/2013 02:28 PM, [hidden email] wrote:
> > I'm picking-up where the following thread stopped -
> >
> > Java.net @
> >
> https://java.net/projects/dwr/lists/users/archive/2011-09/message/100
> >
> > Nabble @
> >
> http://dwr.2114559.n2.nabble.com/CSRF-error-when-using-more-th
an-1-tab-

> > in-browser-td6776437.html
> >
> > !! Please read that thread for the necessary background information.
> >
> >
> --------------------------------------------------------------
> ---------
> > --------
> >
> > Now fast-forward to DWR 3.0.0-rc3
> >    * SVN rev - trunk @ #4032
> >    * Bamboo build #514
> >
> > We experienced the same problem due to the fact that our servlet
> > contextPath is "/codename" but our public-facing urls do not
> > contain/expose this path. Our Tomcat servlet sits behind
> Apache, which
> > we have configured with url-rewrite rules that direct
> requests to the
> > proper location.
> >
> > The answer as to why we do this is quite long, but it amounts to the
> > desire to shorten and beautify public-facing urls by removing our
> > internal project codename.
> >
> > Support for url-rewriting was partially addressed in 3.0-rc2 by the
> > following Jira issue -
> > "Unable to override context path for static engine.js"
> > http://directwebremoting.org/jira/browse/DWR-197
> >
> > The changes for DWR-197 allow us to override "pathToDwrServlet" in
> > engine.js, which controlls the url end-point where DWR requests are
> > made. While this is quite helpful, it only constitutes
> partial-support
> > for url-rewriting in my opinion. The missing piece is
> giving users the
> > ability to override the contextPath (and thus the cookie-path) as
> > determined on the server-side.
> >
> > In order to fix this problem, we made the following changes in
> > engine.js -
> > /** The webapp's context path (used for setting cookie path) */
> > if (typeof dwrContextPath != "undefined") {
> > dwr.engine._contextPath = dwrContextPath;
> > }
> > else {
> > dwr.engine._contextPath = "${contextPath}";
> > }
> >
> > We are then defining "dwrContextPath" in our javascript
> code prior to
> > loading engine.js
> > In our case, we're defining it as root "/".
> >
> > This approach is quite similar to the fix made for DWR-197. The js
> > piece of the fix in engine.js looks like this -
> > /** The default path to the DWR servlet
> > *  pathToDwrServlet is aids cross-domain. If pathToDwrServlet
> > *  is defined before engine.js is included pathToDwrServlet
> > will
> > *  be used.
> > */
> > if (typeof pathToDwrServlet != "undefined") {
> > dwr.engine._pathToDwrServlet = pathToDwrServlet;
> > }
> > else {
> > dwr.engine._pathToDwrServlet = "${pathToDwrServlet}";
> > }
> >
> > Anyhow, just wanted to get feedback on this approach and see if you
> > guys think it's worthwhile to submit a patch, or whether my
> approach is
> > too hacky. I was thinking it might be best to take the same
> approach as
> > the "overridePath" init-param -
> >        
> >
> http://directwebremoting.org/dwr/documentation/server/configur
> ation/ser
> > vlet/index.html
> >
> > Thanks all,
> > Todd
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: CSRF error due to url-rewrite (cookie-path, contextPath)

Mike Wilson
Administrator
In reply to this post by Todd Java
Hi Todd,

Can I just verify with you that you are setting pathToDwrServlet
too?
I have an idea that we might be able to set the correct cookie
path based on pathToDwrServlet only, so we don't need any extra
parameter at all.

Best regards
Mike Wilson

Todd wrote:
> I'm picking-up where the following thread stopped -
>
> Java.net @
> https://java.net/projects/dwr/lists/users/archive/2011-09/message/100
>
> Nabble @
> http://dwr.2114559.n2.nabble.com/CSRF-error-when-using-more-th
an-1-tab-

> in-browser-td6776437.html
>
> !! Please read that thread for the necessary background information.
>
> --------------------------------------------------------------
> ---------
> --------
>
> Now fast-forward to DWR 3.0.0-rc3
>   * SVN rev - trunk @ #4032
>   * Bamboo build #514
>
> We experienced the same problem due to the fact that our servlet
> contextPath is "/codename" but our public-facing urls do not
> contain/expose this path. Our Tomcat servlet sits behind Apache, which
> we have configured with url-rewrite rules that direct requests to the
> proper location.
>
> The answer as to why we do this is quite long, but it amounts to the
> desire to shorten and beautify public-facing urls by removing our
> internal project codename.
>
> Support for url-rewriting was partially addressed in 3.0-rc2 by the
> following Jira issue -
> "Unable to override context path for static engine.js"
> http://directwebremoting.org/jira/browse/DWR-197
>
> The changes for DWR-197 allow us to override "pathToDwrServlet" in
> engine.js, which controlls the url end-point where DWR requests are
> made. While this is quite helpful, it only constitutes partial-support
> for url-rewriting in my opinion. The missing piece is giving users the
> ability to override the contextPath (and thus the cookie-path) as
> determined on the server-side.
>
> In order to fix this problem, we made the following changes in
> engine.js -
> /** The webapp's context path (used for setting cookie path) */
> if (typeof dwrContextPath != "undefined") {
> dwr.engine._contextPath = dwrContextPath;
> }
> else {
> dwr.engine._contextPath = "${contextPath}";
> }
>
> We are then defining "dwrContextPath" in our javascript code prior to
> loading engine.js
> In our case, we're defining it as root "/".
>
> This approach is quite similar to the fix made for DWR-197. The js
> piece of the fix in engine.js looks like this -
> /** The default path to the DWR servlet
> *  pathToDwrServlet is aids cross-domain. If pathToDwrServlet
> *  is defined before engine.js is included pathToDwrServlet
> will
> *  be used.
> */
> if (typeof pathToDwrServlet != "undefined") {
> dwr.engine._pathToDwrServlet = pathToDwrServlet;
> }
> else {
> dwr.engine._pathToDwrServlet = "${pathToDwrServlet}";
> }
>
> Anyhow, just wanted to get feedback on this approach and see if you
> guys think it's worthwhile to submit a patch, or whether my
> approach is
> too hacky. I was thinking it might be best to take the same
> approach as
> the "overridePath" init-param -
>        
> http://directwebremoting.org/dwr/documentation/server/configur
> ation/ser
> vlet/index.html
>
> Thanks all,
> Todd

Reply | Threaded
Open this post in threaded view
|

Re: CSRF error due to url-rewrite (cookie-path, contextPath)

Todd Java
Thanks Mike.

Based on the last comment from David M. (Sep 15, 2010) on Jira issue DWR-197, I am not setting "pathToDwrServlet".

I saw that I could set that variable in my js code before loading engine.js, but it sounded like the preferred way is to use the "overridePath" init-param. Here is my code snippet for that -
<dwr:controller id="dwrController" debug="false">
( ... )
<dwr:config-param name="overridePath" value="/dwr"/>
</dwr:controller>

So "dwr.engine._pathToDwrServlet" then gets defined as the value of my init-param.

I'm happy to set the js variable "pathToDwrServlet" instead, I was just trying to follow best-practice. Let me know if you need more details.

Thanks,
Todd


On Mon, Jun 3, 2013 at 3:27 AM, Mike Wilson <[hidden email]> wrote:
Hi Todd,

Can I just verify with you that you are setting pathToDwrServlet
too?
I have an idea that we might be able to set the correct cookie
path based on pathToDwrServlet only, so we don't need any extra
parameter at all.

Best regards
Mike Wilson

Todd wrote:
> I'm picking-up where the following thread stopped -
>
> Java.net @
> https://java.net/projects/dwr/lists/users/archive/2011-09/message/100
>
> Nabble @
> <a href="http://dwr.2114559.n2.nabble.com/CSRF-error-when-using-more-th an-1-tab-" target="_blank">http://dwr.2114559.n2.nabble.com/CSRF-error-when-using-more-th
an-1-tab-
> in-browser-td6776437.html
>
> !! Please read that thread for the necessary background information.
>
> --------------------------------------------------------------
> ---------
> --------
>
> Now fast-forward to DWR 3.0.0-rc3
>   * SVN rev - trunk @ #4032
>   * Bamboo build #514
>
> We experienced the same problem due to the fact that our servlet
> contextPath is "/codename" but our public-facing urls do not
> contain/expose this path. Our Tomcat servlet sits behind Apache, which
> we have configured with url-rewrite rules that direct requests to the
> proper location.
>
> The answer as to why we do this is quite long, but it amounts to the
> desire to shorten and beautify public-facing urls by removing our
> internal project codename.
>
> Support for url-rewriting was partially addressed in 3.0-rc2 by the
> following Jira issue -
>       "Unable to override context path for static engine.js"
>       http://directwebremoting.org/jira/browse/DWR-197
>
> The changes for DWR-197 allow us to override "pathToDwrServlet" in
> engine.js, which controlls the url end-point where DWR requests are
> made. While this is quite helpful, it only constitutes partial-support
> for url-rewriting in my opinion. The missing piece is giving users the
> ability to override the contextPath (and thus the cookie-path) as
> determined on the server-side.
>
> In order to fix this problem, we made the following changes in
> engine.js -
>       /** The webapp's context path (used for setting cookie path) */
>       if (typeof dwrContextPath != "undefined") {
>               dwr.engine._contextPath = dwrContextPath;
>       }
>       else {
>               dwr.engine._contextPath = "${contextPath}";
>       }
>
> We are then defining "dwrContextPath" in our javascript code prior to
> loading engine.js
> In our case, we're defining it as root "/".
>
> This approach is quite similar to the fix made for DWR-197. The js
> piece of the fix in engine.js looks like this -
>       /** The default path to the DWR servlet
>        *  pathToDwrServlet is aids cross-domain. If pathToDwrServlet
>        *  is defined before engine.js is included pathToDwrServlet
> will
>        *  be used.
>        */
>       if (typeof pathToDwrServlet != "undefined") {
>               dwr.engine._pathToDwrServlet = pathToDwrServlet;
>       }
>       else {
>               dwr.engine._pathToDwrServlet = "${pathToDwrServlet}";
>       }
>
> Anyhow, just wanted to get feedback on this approach and see if you
> guys think it's worthwhile to submit a patch, or whether my
> approach is
> too hacky. I was thinking it might be best to take the same
> approach as
> the "overridePath" init-param -
>
> http://directwebremoting.org/dwr/documentation/server/configur
> ation/ser
> vlet/index.html
>
> Thanks all,
> Todd


Reply | Threaded
Open this post in threaded view
|

Re: CSRF error due to url-rewrite (cookie-path, contextPath)

Mike Wilson
Administrator
That sounds fine, Todd. I was mainly looking for if you were telling DWR about the new path or relying on url-rewriting to change it behind DWR's back. It wasn't important which mechanism you use to tell DWR about it.
I'll look into if we can do something smart here!
 
Best regards
Mike
 
Todd wrote:
Thanks Mike.

Based on the last comment from David M. (Sep 15, 2010) on Jira issue DWR-197, I am not setting "pathToDwrServlet".

I saw that I could set that variable in my js code before loading engine.js, but it sounded like the preferred way is to use the "overridePath" init-param. Here is my code snippet for that -
<dwr:controller id="dwrController" debug="false">
( ... )
<dwr:config-param name="overridePath" value="/dwr"/>
</dwr:controller>

So "dwr.engine._pathToDwrServlet" then gets defined as the value of my init-param.

I'm happy to set the js variable "pathToDwrServlet" instead, I was just trying to follow best-practice. Let me know if you need more details.

Thanks,
Todd


On Mon, Jun 3, 2013 at 3:27 AM, Mike Wilson <[hidden email]> wrote:
Hi Todd,

Can I just verify with you that you are setting pathToDwrServlet
too?
I have an idea that we might be able to set the correct cookie
path based on pathToDwrServlet only, so we don't need any extra
parameter at all.

Best regards
Mike Wilson

Todd wrote:
> I'm picking-up where the following thread stopped -
>
> Java.net @
> https://java.net/projects/dwr/lists/users/archive/2011-09/message/100
>
> Nabble @
> http://dwr.2114559.n2.nabble.com/CSRF-error-when-using-more-th
an-1-tab-

> in-browser-td6776437.html
>
> !! Please read that thread for the necessary background information.
>
> --------------------------------------------------------------
> ---------
> --------
>
> Now fast-forward to DWR 3.0.0-rc3
>   * SVN rev - trunk @ #4032
>   * Bamboo build #514
>
> We experienced the same problem due to the fact that our servlet
> contextPath is "/codename" but our public-facing urls do not
> contain/expose this path. Our Tomcat servlet sits behind Apache, which
> we have configured with url-rewrite rules that direct requests to the
> proper location.
>
> The answer as to why we do this is quite long, but it amounts to the
> desire to shorten and beautify public-facing urls by removing our
> internal project codename.
>
> Support for url-rewriting was partially addressed in 3.0-rc2 by the
> following Jira issue -
>       "Unable to override context path for static engine.js"
>       http://directwebremoting.org/jira/browse/DWR-197
>
> The changes for DWR-197 allow us to override "pathToDwrServlet" in
> engine.js, which controlls the url end-point where DWR requests are
> made. While this is quite helpful, it only constitutes partial-support
> for url-rewriting in my opinion. The missing piece is giving users the
> ability to override the contextPath (and thus the cookie-path) as
> determined on the server-side.
>
> In order to fix this problem, we made the following changes in
> engine.js -
>       /** The webapp's context path (used for setting cookie path) */
>       if (typeof dwrContextPath != "undefined") {
>               dwr.engine._contextPath = dwrContextPath;
>       }
>       else {
>               dwr.engine._contextPath = "${contextPath}";
>       }
>
> We are then defining "dwrContextPath" in our javascript code prior to
> loading engine.js
> In our case, we're defining it as root "/".
>
> This approach is quite similar to the fix made for DWR-197. The js
> piece of the fix in engine.js looks like this -
>       /** The default path to the DWR servlet
>        *  pathToDwrServlet is aids cross-domain. If pathToDwrServlet
>        *  is defined before engine.js is included pathToDwrServlet
> will
>        *  be used.
>        */
>       if (typeof pathToDwrServlet != "undefined") {
>               dwr.engine._pathToDwrServlet = pathToDwrServlet;
>       }
>       else {
>               dwr.engine._pathToDwrServlet = "${pathToDwrServlet}";
>       }
>
> Anyhow, just wanted to get feedback on this approach and see if you
> guys think it's worthwhile to submit a patch, or whether my
> approach is
> too hacky. I was thinking it might be best to take the same
> approach as
> the "overridePath" init-param -
>
> http://directwebremoting.org/dwr/documentation/server/configur
> ation/ser
> vlet/index.html
>
> Thanks all,
> Todd