GEODE-3974: Improve permissions for geode-modules functions #1258
Conversation
| } | ||
|
|
||
| @Test | ||
| public void testInvalidPermissionsForBootstrappingFunction() throws Exception { |
There was a problem hiding this comment.
Another way to have the test auto connect with a specific user/password is to do this:
@rule // instead of a classrule so that it connect/disconnect around each test
public GfshCommandRule gfsh = new GfshCommandRule(server::getJmxPort, PortType.JmxManager);
@test
@ConnectionConfiguration(user = "dataWrite", password = "dataWrite")
public void test(){
gfsh.executeAndAssertThat("execute function --id=test");
}
| @@ -87,6 +91,11 @@ private Cache verifyCacheExists() { | |||
| return cache; | |||
There was a problem hiding this comment.
I think this would be a good opportunity to eliminate the CacheFactory.getAnyInstance() call above. The cache should be available through the FunctionConext.
There was a problem hiding this comment.
I'm going to open a separate Jira for that - it seems a bit orthogonal to what's in this PR. (GEODE-4262).
| import org.apache.geode.test.junit.rules.ServerStarterRule; | ||
|
|
||
| @Category(IntegrationTest.class) | ||
| public class ModuleFunctionsSecurityTest { |
There was a problem hiding this comment.
Should there not be any positive testing for these commands? That'll make the interaction a lot more complicated, true, but it seems strange that we'd only test some selective negatives here and assume positive security coverage elsewhere.
There was a problem hiding this comment.
Discussed with @jinmeiliao which is why I removed them. The tests are targeted to ensure that these functions require specific permissions and not that the security framework is working.
| import org.apache.geode.test.junit.rules.GfshCommandRule; | ||
| import org.apache.geode.test.junit.rules.ServerStarterRule; | ||
|
|
||
| @Category(IntegrationTest.class) |
There was a problem hiding this comment.
I know we don't really just them for anything, but this deserves the SecurityTest.class category, too.
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:
Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?
Has your PR been rebased against the latest commit within the target branch (typically
develop)?Is your initial contribution a single, squashed commit?
Does
gradlew buildrun cleanly?Have you written or updated unit tests to verify your changes?
If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and
submit an update to your PR as soon as possible. If you need help, please send an
email to dev@geode.apache.org.