joeclark-phd / granite Goto Github PK

Authentication with REST API should issue both an access token and a refresh token. Refresh tokens should have a long expiration and there should be an endpoint you can submit the refresh token to get a new access token.

When requesting an access token, the client should also get the precise expiration date for it, so he can know when to refresh.

• test that login page works as expected
• test that logout page works as expected
• test that Spring default folders are NOT public (i.e. /css, /images)
• test that my replacement for those, /public, IS public
• test that the public can see the index page "/"
• test that the public cannot see other pages without authentication
• test that roles work: SUPER and AGENT
• test that REST API authentication works the same way as Website authentication
• test that database can be used to authenticate
• test that password hashing and validation of hash works correctly

For example, how to import headers/footers from other files.

they should at least have timestamps. also maybe different HTTP codes and messages depending on reason for error. without giving away too much info that might create a security risk.

• create a mock UserDetailsService
• create different access levels (user, admin, etc)
• create separate security configurations for Web and REST API endpoints
• make sure it's fully tested
• link it to the application's real database

JWTAuthenticationFilter could probably be replaced by an endpoint in a RestController, and the part that extracts information from the POST may be made simpler and clearer as well.

The "refresh token" flow could then go into the same RestController.

get JWT authentication working for API at an endpoint like /api/login without using the "loginForm()" directive.

Find an answer to this SO:
https://stackoverflow.com/questions/58983086/how-to-make-a-custom-usernamepasswordauthenticationfilter-register-at-an-endpoin

[ ] do one thing
[ ] do another

Vulnerabilities

DepShield reports that this application's usage of com.fasterxml.jackson.core:jackson-databind:2.9.9 results in the following vulnerability(s):

• (CVSS 9.8) [CVE-2019-16943] A Polymorphic Typing issue was discovered in FasterXML jackson-databind 2.0.0 th...
• (CVSS 9.8) [CVE-2019-16942] A Polymorphic Typing issue was discovered in FasterXML jackson-databind 2.0.0 th...
• (CVSS 9.8) [CVE-2019-16335] A Polymorphic Typing issue was discovered in FasterXML jackson-databind before 2...
• (CVSS 9.8) [CVE-2019-14540] A Polymorphic Typing issue was discovered in FasterXML jackson-databind before 2...
• (CVSS 9.8) [CVE-2019-17267] A Polymorphic Typing issue was discovered in FasterXML jackson-databind before 2...
• (CVSS 9.8) [CVE-2019-14379] SubTypeValidator.java in FasterXML jackson-databind before 2.9.9.2 mishandles de...
• (CVSS 9.8) [CVE-2019-17531] A Polymorphic Typing issue was discovered in FasterXML jackson-databind 2.0.0 th...
• (CVSS 7.5) [CVE-2019-14439] A Polymorphic Typing issue was discovered in FasterXML jackson-databind 2.x befo...
• (CVSS 5.9) [CVE-2019-12814] Information Exposure
• (CVSS 5.9) [CVE-2019-12384] Deserialization of Untrusted Data

Occurrences

com.fasterxml.jackson.core:jackson-databind:2.9.9 is a transitive dependency introduced by the following direct dependency(s):

• io.jsonwebtoken:jjwt:0.9.1
        └─ com.fasterxml.jackson.core:jackson-databind:2.9.9

_{This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.}

It takes over 15 lines of code to spin up a testcontainer in AgencyControllerIntegrationTest, which will have to be copied over into potentially dozens of other test cases. Using the JDBC URL method of setting up Testcontainers would be better, but I don't know if it can be done with our custom database image.

If possible, find a way to do it, preferably generating the image on the fly. If not, consider whether we can get the same result using a library image and calling our scripts some other way.

This will make sure JUnit5 is correctly specified in the POM file and that tests run when expected during the build.

this is so test containers won't conflict with any other service(s) listening on port 5432

The test database should be deployed as a docker image (with version number) and so should the Granite application itself.