-
Notifications
You must be signed in to change notification settings - Fork 265
KNOX-2554 - Implemented JDBC Token State Service #433
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
moresandeep
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great Sandor!!
I did a quick review and noted few observations. Also, synchronization can be issue here, might want to consider using CompletableFutures for optimization, failures and thread safety.
...-server/src/main/java/org/apache/knox/gateway/services/token/impl/JDBCTokenStateService.java
Outdated
Show resolved
Hide resolved
...way-server/src/main/java/org/apache/knox/gateway/services/token/impl/TokenStateDatabase.java
Outdated
Show resolved
Hide resolved
...way-server/src/main/java/org/apache/knox/gateway/services/token/impl/TokenStateDatabase.java
Outdated
Show resolved
Hide resolved
| public class TokenStateDatabase { | ||
| private static final String TOKENS_TABLE_NAME = "KNOX_TOKENS"; | ||
| private static final String ADD_TOKEN_SQL = "INSERT INTO " + TOKENS_TABLE_NAME + "(token_id, issue_time, expiration, max_lifetime) VALUES(?, ?, ?, ?)"; | ||
| private static final String REMOVE_TOKENS_SQL_PREFIX = "DELETE FROM " + TOKENS_TABLE_NAME + " WHERE token_id IN ("; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a thought, why not list them under resources as a *.sql statements so all of them are in one place and easy to manage and look at.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if I follow. Do you think that having a .sql file is better than having all token-related SQL statements in one place (in this DAO class)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have seen this implemented in other projects where SQL was used heavily. The idea being all SQL stays in one resource place and if you need to tweak the SQL statements you don't have to worry about changing the java files. Even better if you can have them as external resources you could change them at runtime without changing class files (but that is not what I am expecting just something that came to me while writing :) )
I am not opposed to having it in DAO but my thinking is SQLs statements are more like resources.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found this article on SO. Let me quote the pros/cons of my approach and I do agree with them:
Hardcoded/encapsulated in DAO layer
Pros:
SQL is kept in the objects that access data (encapsulation)
SQL is easy to write (speed of development)
SQL is easy to track down when changes are required
A simple solution (no messy architecture)
Cons:
SQL cannot be reviewed/changed by DBA
SQL is likely to become DB-specific
SQL can become hard to maintain
Given the fact we are going to keep authentication tokens in this DB table, I have the impression that these SQL statements should reside in the Java class so that they cannot be changed/manipulated/removed easily.
At my previous workplaces, where pure JDBC was used, no ORM (Hibernate, EclipseLink, etc) frameworks, we followed this approach because of the above-listed pros.
There was an exception where lots of business logic was written in PL/SQL but - to be honest - I really hated that part.
smolnar82
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @moresandeep !
I'm going to submit a new patch soon with the getTokenIds optimization and the removal locking the rest should be ok IMO.
...-server/src/main/java/org/apache/knox/gateway/services/token/impl/JDBCTokenStateService.java
Outdated
Show resolved
Hide resolved
| public class TokenStateDatabase { | ||
| private static final String TOKENS_TABLE_NAME = "KNOX_TOKENS"; | ||
| private static final String ADD_TOKEN_SQL = "INSERT INTO " + TOKENS_TABLE_NAME + "(token_id, issue_time, expiration, max_lifetime) VALUES(?, ?, ?, ?)"; | ||
| private static final String REMOVE_TOKENS_SQL_PREFIX = "DELETE FROM " + TOKENS_TABLE_NAME + " WHERE token_id IN ("; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if I follow. Do you think that having a .sql file is better than having all token-related SQL statements in one place (in this DAO class)?
...way-server/src/main/java/org/apache/knox/gateway/services/token/impl/TokenStateDatabase.java
Outdated
Show resolved
Hide resolved
...way-server/src/main/java/org/apache/knox/gateway/services/token/impl/TokenStateDatabase.java
Outdated
Show resolved
Hide resolved
|
@moresandeep - thanks again for your review. In fact, I made it even more clean and effective by overriding the |
…es are executed from the public API
gateway-server/src/main/java/org/apache/knox/gateway/config/impl/GatewayConfigImpl.java
Show resolved
Hide resolved
lmccay
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, added one review comment.
...-server/src/main/java/org/apache/knox/gateway/services/token/impl/JDBCTokenStateService.java
Show resolved
Hide resolved
|
Merging based on @lmccay 's comment: this change looks good except for the suggested refactoring which I created a JIRA for. |
This commit does not contain secrets Change-Id: I12152e2ce24d46bd6f8254127fc9e3634044b081
* changes: CDPD-25489 - Added missing pieces from previous Apache commits CDPD-25489 KNOX-2596 - Changed gateway-site config value to support PostgreSQL as token state backend (apache#439) CDPD-25489 KNOX-2595 - KNOX_TOKENS table is created automatically if not exists (apache#438) CDPD-25489 KNOX-2554 - Implemented JDBC Token State Service (apache#433)
What changes were proposed in this pull request?
This change introduces a new
TokenStateServiceimplementation that operates using pure JDBC connections to relational databases. In the first version, onlyPostgresandDerbydatabase types are supported.How was this patch tested?
Added new JUnit test classes and updated existing test cases as needed.
I also executed manual testing:
tokengenapplication to fetch a tokenWEBHDFSstatus. This time the configuredWEBHDFSbackend pointed to a non-existing cluster, but the point is that the suppliedPasscodetoken could be validated. I also covered this case by restarting Knox and repeated the same step, so that a DB lookup was necessary as the token was not available in the in-memory collections:I also let the Knox Gateway running for the long weekend and confirmed that expired tokens got removed by the reaper thread.