Backward compatibility and support for varies deployment.

[lav023]

As of now there is no backward compatibility with CSRF 3.1.0 and currently CSRF supports only war deployment.
There should be support for other deployment too.

[forgedhallpass]

Hello @lav023,

As of now there is no backward compatibility with CSRF 3.1.0

What exactly do you mean by backward compatibility? The only thing you need to update is the dependencies and maybe some configuration in the properties file, because of the newly added functionalities (which is as easy as it can get, especially because of the default values). Besides, the solution has been heavily refactored and extended, as the version change from 3.x to 4.x (MAJOR, see https://semver.org/) suggests.

and currently CSRF supports only war deployment.

CSRFGuard is integrated through a Servlet Filter, how else would you like it to be integrated? With the current approach, you can configure it for WARs, EARs and embedded, executable JARs.

There should be support for other deployment too.

As in? Also, I hope you meant "it would be nice" instead of "should".

p.s. When creating tickets, please use the issue template(s) and provide as many details as you can.

[lav023]

Hello @forgedhallpass

In earlier release CSRF 3.1.0 , if a request only wants the master token , there was a method for it (fetchCsrfToken ) in csrfguard/src/main/java/org/owasp/csrfguard/servlet/JavaScriptServlet.java , which has been removed in new release , So if we can add that method back then we can retain the backward compatibility with older release .

[forgedhallpass]

Hello @lav023,

In earlier release CSRF 3.1.0 , if a request only wants the master token , there was a method for it (fetchCsrfToken ) in csrfguard/src/main/java/org/owasp/csrfguard/servlet/JavaScriptServlet.java , which has been removed in new release

That change was intentional. See: #52 (comment)

So if we can add that method back then we can retain the backward compatibility with older release.

I don't see any reason for adding it back. Again, I don't know what backwards compatibility are you talking about...My previous answer still stands.

[lav023]

Hello @forgedhallpass

The current working of CSRF GUARD would work fine , where we exploded the war during the deployment phase , but it would failed where we are not exploded war it into files. So instead of reading file from the file system , if we read file file using servlet context , then we can provide for other types of deployments too.

[lav023]

We can follow following link to see the code changes which I am suggesting.

lav023@f0b28a9

[forgedhallpass]

but it would failed where we are not exploded war it into files. So instead of reading file from the file system , if we read file file using servlet context , then we can provide for other types of deployments too.

For this problem, please create in issue and describe all the necessary details and steps to reproduce (preferably using the test application). After the issue is created, you can create a PR with only that change, and link it to the issue, and I'll accept/merge it.

[lav023]

Hello @forgedhallpass

In our project we are only using master token and we have disabled the page token. And for the testing we are using rest call to get the master token , which we append in the subsequent call to perform the test. But now since in the current CSRF GUARD there is no support to get FETCH-CSRF-TOKEN directly due to which test cases are failing .

So is there any way to get the FETCH-CSRF-TOKEN , which I can use in my project to resolve this problem .

[forgedhallpass]

You were relying on the internal workings of a solution, which is/was not considered a part of the "public API", hence making it subject to change. Also, please refer back to my first comment, a MAJOR version change (3.x -> 4.x) suggests (potential) breaking changes.

Normally, for back-end integration tests you could just disable CSRFGuard, as you want to test your application's functionalities, not CSRFGuard itself (feel free to contribute such integration tests in this repository though). CSRF protection only makes sense in a browser context. For UI/e2e tests, you should use a UI framework (e.g. Selenium), in which case the CSRF protection/integration is implicitly tested.

That being said, if you still intend to move forward with your approach you can just retrieve the whole JS code and extract the master token from it just as easily...