-
Notifications
You must be signed in to change notification settings - Fork 692
GEODE-5074 REST dev client should not access or modify internal regions #2853
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -15,6 +15,7 @@ | |
| package org.apache.geode.rest.internal.web.controllers; | ||
|
|
||
| import java.util.ArrayList; | ||
| import java.util.HashSet; | ||
| import java.util.List; | ||
| import java.util.Set; | ||
|
|
||
|
|
@@ -38,6 +39,7 @@ | |
| import org.apache.geode.cache.execute.FunctionException; | ||
| import org.apache.geode.cache.execute.FunctionService; | ||
| import org.apache.geode.cache.execute.ResultCollector; | ||
| import org.apache.geode.internal.cache.InternalRegion; | ||
| import org.apache.geode.internal.cache.execute.util.FindRestEnabledServersFunction; | ||
| import org.apache.geode.internal.logging.LogService; | ||
| import org.apache.geode.rest.internal.web.controllers.support.RestServersResultCollector; | ||
|
|
@@ -73,7 +75,12 @@ public ResponseEntity<?> regions() { | |
| logger.debug("Listing all resources (Regions) in Geode..."); | ||
| final HttpHeaders headers = new HttpHeaders(); | ||
| headers.setLocation(toUri()); | ||
| final Set<Region<?, ?>> regions = getCache().rootRegions(); | ||
| final Set<Region<?, ?>> regions = new HashSet<>(); | ||
| for (InternalRegion region : getCache().getApplicationRegions()) { | ||
| if (region instanceof Region) { | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. InternalRegion extends Region, do we need instance check.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The java compiler would not let me add the InternalRegions to the "regions" HashSet without casting to Region first. Since that was required I felt obliged to perform an instanceof check. |
||
| regions.add(region); | ||
| } | ||
| } ; | ||
| String listRegionsAsJson = JSONUtils.formulateJsonForListRegions(regions, "regions"); | ||
| return new ResponseEntity<>(listRegionsAsJson, headers, HttpStatus.OK); | ||
| } | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -18,5 +18,5 @@ | |
|
|
||
| public interface CacheProvider { | ||
|
|
||
| InternalCache getInternalCache(); | ||
| InternalCache getCache(); | ||
| } | ||
Uh oh!
There was an error while loading. Please reload this page.
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 don't think we need to add this interface here. Just add it as a method in CacheForClientAccess object. The CacheProvider is an internal interface and is only used in the geode-web-api module, we can have it return CacheForClientAccess object instead of InternalCache object. This method doesn't belong to the regular cache, in my opinion.
Also, the getQueryStore method doesn't need a region path passed to it, right? It's always going to be the " "ParameterizedQueries" static string. You can't pass other string to it to get the query store at all. So we can just do this:
public <K, V> Region<K, V> getQueryStore() {
Region<K, V> result = delegate.getRegion(PARAMETERIZED_QUERIES_REGION);
return result;
}
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 disagree. InternalCacheForClientAccess implements InternalCache and should be indistinguishable from other InternalCache implementations. I liked your first idea because it removed knowledge of server vs client cache access from the REST code.
Having getQueryStore take an argument is more flexible and leaves it open to allowing there to be multiple query stores. Since that's the way the REST code was written I think it should stay like that.
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 would consider changing the method name from getQueryStore to getInternalRegion though. I think that would make the JMX code that I'm now working on cleaner because I could install an InternalCacheForClientAccess into it and then use getInternalRegion in specific places where it needs to get its "monitoring regions"
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.
but then wouldn't the client just pass in any internal region name to that method and get access to any internal region? I believe in the REST code, any caller to that method is passing in the same string... (but I may have missed something).
In my thought, CacheForClientAccess is a child of InternalCache which has restricted access to the regions, but aside from that, it needs to access some "internal regions" for legacy reasons. InternalCache already has that capability in the "getRegion" method, so it doesn't need anymore method to get a special internal region. But for CacheClientAccess access, some special internal region will be allowed access by adding some additional method. My 2 cents.
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.
This isn't code that's accessible from a client. This is server-side code and it's okay for that code to intentionally get an internal region. What we don't want is someone using the REST API to be able to send a request that modifies an internal region or returns privileged information from an internal region.
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.
Ah, I think if I have the REST code assume it has an InternalCacheForClientAccess instead of an InternalCache I can remove the getQueryStore method from InternalCache and GemFireCacheImpl. Yeah, that will work. Thanks Jinmei
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.
Yes, that's what I meant as well. The rest code should be working with InternalCacheForClientAccess alone because that is what it needs. I like the renaming that method to getInterRegion for a more general purpose.