Glad to hear you got this working, do you want to file a doc fix JIRA with your proposed changes?
On Fri, Jan 29, 2016 at 3:20 PM, Spoutable <[email protected]> wrote: > Yes this worked. Thank You! > > We opted to use a custom authenticator using the java class template > instructions here: > https://drill.apache.org/docs/configuring-user-authentication/ < > https://drill.apache.org/docs/configuring-user-authentication/> > > The following is an FYI for anybody else that tries this path on the 1.5 > release. > > The template didn’t ‘just work’. > You will need to correct the imports first. > import org.apache.drill.common.config.DrillConfig; > import org.apache.drill.exec.exception.DrillbitStartupException; > import org.apache.drill.exec.rpc.user.security.UserAuthenticator; > import org.apache.drill.exec.rpc.user.security.UserAuthenticatorTemplate; > import org.apache.drill.exec.rpc.user.security.UserAuthenticationException; > import java.io.IOException; > > Also you cant just package the class into a jar file and pop the jar into > the jars directory. There is a custom classpath scanner that looks for > the eligible classes. > > In order to tell the custom classpath scanner that our new class is > eligible to be found we had to put the following config code in a file > named drill-module.conf at the root of the jar file with our class. > > drill { > classpath.scanning { > packages += "com.spoutable.drill" > } > } > > We put our SimpleAuth class in the com.spoutable.drill package. We > still placed our jar file in the jars directory. > > The config in drill-overrides.conf that worked for us is slightly > different too. > > drill.exec: { > http: { > ssl_enabled: true > } > > security.user.auth: { > enabled: true, > impl: “SimpleAuth" > } > } > > We have the following line annotating our class which matches the ‘impl’ > property above. Our class is also called SimpleAuth but its really the > type parameter in > @UserAuthenticatorTemplate(type="SimpleAuth") > > > > On Jan 28, 2016, at 1:09 PM, Jason Altekruse <[email protected]> > wrote: > > > > A few weeks ago a fix for this issue was merged, it requires using the > new > > web UI security feature, which will hold onto a session while you are > > logged in. [1] > > > > You can try to build the tip of master yourself or wait for the upcoming > > 1.5.0 release to try it out. > > > > [1] - https://issues.apache.org/jira/browse/DRILL-3624 > > > > On Thu, Jan 28, 2016 at 1:02 PM, Spoutable <[email protected]> wrote: > > > >> We are using the REST API from nodejs and need to issue some create > table > >> statements that are a different format from the default for the system > >> (currently Parquet). We cant issue an alter system command to change > the > >> store.format globally. > >> > >> I tried to issue multiple requests with a alter session set > >> `store.format`='json'; > >> and i tried to have multiple statements in the the same request > separated > >> by semi colon. Neither of those worked. > >> > >> As a last resort i looked at the code in QueryWrapper.java and it looks > >> like its just 1 query per request and no session persistence or anything > >> like that going on between requests to the REST api. I tried to follow > the > >> code down through the DrillUserPrincipal and DrillClient and UserClient > but > >> ran out of patience. It doesnt look like there is any notion of > ‘session’ > >> in the sense of ‘alter session’ statments. > >> > >> Does anybody have a workaround for this? > >> If not, does anybody have a suggestion on what change I could make for > >> supporting this in a way that would be acceptable to the project? > >> > >> Thanks in advance. > >
