Hi John,
Thanks for your note. Comments inline below: ________________________________ From: John Blum <[email protected]> Sent: Friday, October 9, 2015 2:12 PM To: Nitin Lamba Cc: [email protected] Subject: Re: Is REST APIs test coverage missing in geode codebase? Answers and comments in-line below... On Fri, Oct 9, 2015 at 1:07 PM, Nitin Lamba <[email protected]<mailto:[email protected]>> wrote: Hi, Trying to revive this thread after a few months - does the Developer REST APIs have any tests, like those included in Management REST APIs? Yes. In the original, "closed" codebase, the tests for the Developer REST API would most have been in tests/com/gemstone/gemfire/rest/internal/web/. I suspect there are a few others lurking elsewhere as related to the JSONFormatter and other classes in GemFire that the Developer REST API directly relies on. Will these tests be contributed or are new ones required to be built for Geode? Having Apache code without tests may be undesirable in the long-run... Also, management REST APIs should ideally be secured for release as it creates a vulnerability on the locator node - starts the REST APIs giving full access to the Geode cluster. Perhaps, GEODE-17 (Integrated Security) addresses that concern. If integrated security is not in scope for the first release, we should consider turning-off Management REST APIs by default. The Management REST API is secured from a transport perspective (HTTPS). This was introduced in GemFire 8.1 by the M&M team in Pune. Of course, authorization is a whole other story and currently the Management REST API is no more secure than Gfsh. I.e. none of the Gfsh commands executed on a remote cluster (through the Manager) are secured either. If I understand the docs correctly, enabling remote access still requires some additional settings/ command line arguments. Guess my question is more about the default setup (out-of-the-box) behavior than a conscious (insecure?!) setup that an admin may choose to do behind firewalls. Once you authenticate, you have free reign on the GemFire cluster to execute any Gfsh command you wish (there is no distinction between read-only or admin with write level privileges Gfsh when it comes to the commands, e.g. 'list regions' vs. 'create|alter region'). So, until role-based security is implemented and enforced in the Manager for JMX clients (like Gfsh executing various commands), then the Management REST API will also be insecure as result. My understanding was that "security" (and in particular, "authorization") was going to be implemented in the Managerso that any tool accessing the Management system (Gfsh, and by extension the Management REST API) using JMX, HTTP or any mangement-level protocol would have security enforced. Agree. Accessing Gfsh may still require ssh to locator/ manager node but management REST is even more dangerous in that regard - just an IP address to the node can grant access and full control to manipulate the cluster. So, if you throw out, or disable the Management REST API, you might as well disable Gfsh, or rather disable the whole Management (JMX) interface. The GemFire MBeans can also be manipulated through JConsole/JVisualVM or programmatically with a Java-based JMX client as well. FYI. Yes, I'm aware of using JMX to modify the cluster. Again, as a default behavior, we can consider either disabling it or at least putting in some basic authentication (jmx-manager-access-file, jmx-manager-password-file) so that it forces users to set this up at startup time. Just trying to build good/ secure practice to start a cluster. Both of these (Mgmt REST, JMX) are more important for production installations; frankly, app developers shouldn't be bogged-down by this config initially, which is why turning-off these services by default may be worth considering until GEODE-17 is in place. My $0.02 Thoughts? -Nitin ________________________________________ From: Nilkanth Patel <[email protected]<mailto:[email protected]>> Sent: Monday, August 3, 2015 5:57 AM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: Is REST APIs test coverage missing in geode codebase? Hello, With the Geode code base, i can see REST APIs code base but do not find any test coverage for it (Junit/Dunits). Have we missed to move REST APIs test coverage to geode open source or am i missing something here. I prefer to add this test coverage so one can make sure their change are as expected. Thank you. Nilkanth Patel. -- -John 503-504-8657 john.blum10101 (skype)
