CsrfGuard.getSessionKey() replacement?

[rdifrango]

We are moving from the 3.0.0 version to 4.1.4 and noticed that CsrfGuard.getSessionKey() has been removed. What is the migration path for this method?

It looks like the following methods were also removed:

• isProtectedPageAndMethod
• isValidRequest

I found this question when the discussion was hosted over on Google Groups, but no real answer to the question.

[rdifrango]

ok, from what I can tell the following is the migration path:

• CsrfGuard.getSessionKey() -> CsrfGuard.getLogicalSessionExtractor().extract(request).getKey()
• CsrfGuard.isValidRequest()- > new CsrfValidator().isValid()
• CsrfGuard. isProtectedPageAndMethod()- > csrfValidator.isProtectedPageAndMethod(uri, method).isProtected()

[forgedhallpass]

Hello @rdifrango,

1. The migration should be seamless once you use the updated csrfguard.js file, the csrfguard.properties and the right dependencies, as stated in the readme.

2. Normally you shouldn't (need to) care about the internal workings of the solution. Could you maybe give some context on what do you want to achieve?

3. GitHub discussions are favored over Google Groups.

4. Have you seen my answers on the discussions below?

• Change in the JavaScriptServlet doPost() logic in 4.1.1 from 3.1.0 #52 (comment)
• Difference between 3.1.0 and 4.1.0 with respect to where the token is saved in the container #51 (comment)
• using csrfGuard without SessionTokenKeyExtractor #44 (comment)
• retrieving tokens from TokenHolder interface #98 (comment)

5. There is a test-jsp module which showcases a default configuration. A pre-built WAR can also be downloaded from the releases section.

[rdifrango]

@forgedhallpass thank you for your answer, the issue is that I'm using the Java code NOT JavaScript and those interfaces 100% changed thus it isn't/wasn't seamless.

• 3.1 - CsrfGuard.java
• 4.1 - CsrfGuard.java

These are the methods that have been removed from CsrfGuard.java:

• getSessionKey
• isValidRequest
• isProtectedPageAndMethod

Now as mentioned and sort of following those answers (though they didn't match my search) I mapped them to the getLogicalSessionExtractor (which was covered in the first link) and CsrfValidator as that seems to be where they are moved.

[forgedhallpass]

the issue is that I'm using the Java code NOT JavaScript

The JavaScript can only be omitted if your application uses JSPs, otherwise it goes hand-in-hand with the Java logic.

those interfaces 100% changed

I am very well aware of the changes, because I made them. You can find the reasoning in the discussion links above.

isn't/wasn't seamless

It is, if you are using it as intended. Normally you would add the CsrfGuardFilter and that should take care of everything. The validation logic is considered internal and was not intended to be used as an API!

My question still stands:

Normally you shouldn't (need to) care about the internal workings of the solution. Could you maybe give some context on what do you want to achieve?

[rdifrango]

Well, CsrfGuard is a public class so there's nothing preventing its direct use? :)

As to usage, I'm going to ask the team I'm working with why they used CsrfGuard and what the intention is.

I'll also add that they also used ILogger and that was removed but that code in this case could be safely removed.

[forgedhallpass]

Well, CsrfGuard is a public class so there's nothing preventing its direct use? :)

Just because you can, it doesn't mean you should ;) The internal logic of the solution is always subject to change, without notice and explicit explanation/documentation.

As to usage, I'm going to ask the team I'm working with why they used CsrfGuard and what the intention is.

The reason why I am asking is because I usually receive such questions as outcomes of potentially bad architectural decisions or practices.

I'll also add that they also used ILogger and that was removed but that code in this case could be safely removed.

The logging was replaced by SLF4J. You can add your preferred implementation on the class path. An example is provided in the test application mentioned earlier.

[rdifrango]

Good choice here (and something that we are doing as well):

The logging was replaced by SLF4J. You can add your preferred implementation on the class path. An example is provided in the test application mentioned earlier.

I hear you on usage, but if it's not to be used, package protected and/or private should be used to prevent unintended usages :)

And I'll be honest; I'm just helping this team out so I have no idea why they used CsrfGuard directly instead of the filter; once I do I'll post back here.

[forgedhallpass]

I hear you on usage, but if it's not to be used, package protected and/or private should be used to prevent unintended usages :)

That's not really possible in a multi-module maven project. Some classes need to be accessible from other modules or sub-modules, from within the same project.