-
Notifications
You must be signed in to change notification settings - Fork 21
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
Make the proxy single user #16
Comments
Under this paradigm, it still would be possible to support multiple users with a single proxy. However, the way it would be done is much simpler: you simply specify which client properties file the proxy should use to create AccumuloClient objects for the requested operations. |
Does the proxy client need to be on the same server as the Proxy if this is done? There are Java bindings in case you want to limit access from the client to cluster. I am not sure if limiting access is still needed, I just wanted to bring it up. |
No. The client just needs to send a filename for a file that exists local to the proxy server... or, it could send the raw client properties, I suppose. The main point is to standardize client initialization around the client properties, either as raw properties or as a properties file, rather than the custom "logon" session stuff that the proxy has now. Avoiding the custom stuff and using the client properties in the same (familiar) way that the Java API uses them, would be the main goal. The simplest thing to do is just have one set of client properties in the proxy server so it has one Java AccumuloClient for the lifetime of the proxy, to handle all the real client's requests. That implies a single-user scenario, so that's why I thought of that first. The more complicated case would be the multi-user support via multiple sets of client properties. I haven't fully through through all the possible multi-user options and their implications... but just thinking that it could still be done, if we really wanted to have that complexity. Which direction this goes is really up to user demand and how tolerant for complexity those maintaining the proxy are. I'm fine with the single user case (because my tolerance for complexity in Accumulo is low right now)... I just want to see the custom and unfamiliar proxy-specific stuff go away in favor of the friendly and familiar client properties. |
@ctubbsii With the update in Accumulo 2.0.1, most of the ITs are throwing security exceptions. I have been looking where the user "user" gets setup but have not found that yet. I am wondering if this ticket is more important now that the exception bug was fixed in: apache/accumulo#1828 Edit: The ITs can still pass but they are throwing security exceptions. |
I'm not sure how this ticket would relate to that one. The idea here is to just create a single AccumuloClient for that specific proxy instance, built from the client properties, and remove any "login" mechanisms. I'm not sure what's going on with the ITs. It may be entirely unrelated. |
See #31 |
Is the suggestion here to pass the client properties when creating the |
The suggestion is that starting the AccumuloProxy (via it's main method) will either automatically locate the client properties using the class path and/or environment and construct an AccumuloClient from that (just like |
Addressed in #59 |
From code review of #15, Simplify the proxy by dropping this login mechanism entirely, and make the proxy single-user (using the user specified in the proxy/client properties file).
The text was updated successfully, but these errors were encountered: