Skip to content
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

DBZ-713 Only getting collections for databases matching filters #566

Merged
merged 4 commits into from Jul 3, 2018

Conversation

gunnarmorling
Copy link
Member

https://issues.jboss.org/browse/DBZ-713
https://issues.jboss.org/browse/DBZ-782

@jpechane This fixes two issues, I noticed DBZ-782 while working on DBZ-713. It's best reviewed commit by commit, as they are largely independent and I did some clean-up not strictly related to the original issue. Also disable whitelist differences to further ease the diff. Thanks!

In terms of testing, it seems all the MongoDB ITs we have don't deal with authentication/authorization at all. It seems worth to have some tests for that, but let's handle it separately. I tested the original issue manually successfully, i.e. collections from a DB the connector user isn't authorized for won't cause any harm if that other DB is not part of the filter config. I've added some basic tests which make sure that the methods of MongoPrimary only return the databases/collections matching the given filter config.

This protects against authorization failures when listing collections
from DBs the connector user isn't authorized for. It also simplifies
usage of MongoPrimary#databaseNames() and collections() as consumers
don't need to apply filtering themselves.
This simplifies interaction with execute(), as we don't need to alter collections, references as a side effect but instead can work with the return value.
@gunnarmorling gunnarmorling mentioned this pull request Jul 3, 2018
replicaSet,
(desc, error) -> {
// propagate authorization failures
if (error.getMessage() != null && error.getMessage().startsWith("Command failed with error 13")) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be extracted as a constant

*/
public <T> T execute(String desc, Function<MongoClient, T> operation) {
final Metronome errorMetronome = Metronome.sleeper(PAUSE_AFTER_ERROR, Clock.SYSTEM);
while (true) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will this loop terminate when the connector is stopped?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point; indeed it seems they'd keep running if the connector is shut down and they don't complete normally. I'll log an issue.

@jpechane
Copy link
Contributor

jpechane commented Jul 3, 2018

@gunnarmorling Good for me, just two questions were raised

@gunnarmorling
Copy link
Member Author

@jpechane Pushed one more commit to extract the constant and filed DBZ-784 for the loop abortion issue.

@jpechane jpechane merged commit e1cf34d into debezium:master Jul 3, 2018
@jpechane
Copy link
Contributor

jpechane commented Jul 3, 2018

@gunnarmorling Applied, thanks.

@gunnarmorling gunnarmorling deleted the DBZ-713 branch July 10, 2018 11:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants