> On May 21, 2015, 11:34 p.m., Kevin Sweeney wrote:
> > Have you investigated using the [Console 
> > Servlet](http://www.h2database.com/html/tutorial.html) directly? Then we 
> > can use the Shiro filter directly and avoid adding another mechanism to 
> > configure security as well as avoid adding another listening port.
> 
> Maxim Khutornenko wrote:
>     That's what I run locally to connect to H2 TCP server. Embedding H2 
> console directly into the scheduler would not help as it does not support any 
> other security mechanisms besides basic auth (AFAICT). Theoretically, we 
> could put TCP server behind Shiro but then we would face the same problem of 
> client not supporting kerberos.
> 
> Kevin Sweeney wrote:
>     I might be missing something here. You're connecting to a management 
> console via a browser, right? The console servlet doesn't need to know 
> anything about the filters in front of it, so if your browser supports 
> whatever auth mechanism the filter requires you're in business.
>     
>     If you've got the servlet setup somewhere with
>     
>     ```java
>     serve("/h2console/*").with(H2Console.class);
>     ```
>     
>     somewhere you can add something like
>     
>     ```java
>     install(ShiroWebModule.guiceFilter("/h2console/*");
>     addFilterChain("/h2console/**",
>       ShiroWebModule.NO_SESSION_CREATION,
>       ShiroWebModule.AUTHC_BASIC,
>       config(ShiroWebModule.PERMS, "h2:console"));
>     ```
>     
>     to `ApiSecurityModule` and users can login with their existing 
> credentials, and configure ACLs around `h2:console` in the same way as they 
> configure all other ACLs. Why introduce another way to do it?

The servlet is hosted within the browser but it still connects to the TCP 
server that we have to expose for it to connect to. So, the way it works now 
(referring to the boxes in http://www.h2database.com/html/tutorial.html):
a. Web Browser: loads a servlet UI, which has "Connect" button to connect to 
the TCP server;
b. H2 console server: that's the TCP server endpoint (in DBModule) that proxies 
requests from the servlet to the H2;
c. H2: our in-memory DB

I guess we could potentially embed (a) into scheduler (subject to verificaiont) 
and hide it behind Shiro. However, it would still have to connect to a TCP 
endpoint (b), so we would also need to add Shiro there as well. The problem (as 
I see it) is how to relay credentials from (a) to (b) as servlet opens its own 
connection to talk to (b) where kerberos headers will not be available.

> Why introduce another way to do it?

No reason at all. I hate dealing with DB credentials, just don't see a way to 
make it work without hacking into the servlet itself.


- Maxim


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/34566/#review84823
-----------------------------------------------------------


On May 21, 2015, 9:15 p.m., Maxim Khutornenko wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/34566/
> -----------------------------------------------------------
> 
> (Updated May 21, 2015, 9:15 p.m.)
> 
> 
> Review request for Aurora, Joshua Cohen and Kevin Sweeney.
> 
> 
> Bugs: AURORA-1287
>     https://issues.apache.org/jira/browse/AURORA-1287
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> Adding support for connecting to H2 DB via management console: 
> http://www.h2database.com/html/quickstart.html
> 
> The DB turns on basic authentication when a "-db_authentication_file" is 
> provided (similar to "-framework_authentication_file"). The TCP server is 
> then started to proxy H2 management console requests.
> 
> Vagrant example URL: jdbc:h2:tcp://192.168.33.7:9092/mem:aurora
> 
> 
> Diffs
> -----
> 
>   config/legacy_untested_classes.txt f50b812459bd6b59d1a03e6814caa2daae133fe9 
>   examples/vagrant/provision-dev-cluster.sh 
> 853ccac35f2befa31716a9ed686df650cd913c90 
>   examples/vagrant/upstart/aurora-scheduler-kerberos.conf 
> 414539b1917b5d33c577f1539575934c7f7c8167 
>   examples/vagrant/upstart/aurora-scheduler.conf 
> f4b867cbbcdbcc792518c2f90807834e47dce253 
>   src/main/java/org/apache/aurora/SecurityUtils.java PRE-CREATION 
>   
> src/main/java/org/apache/aurora/scheduler/mesos/CommandLineDriverSettingsModule.java
>  54608c8f819b65186ea0d000fc01b9538d5cb4ee 
>   src/main/java/org/apache/aurora/scheduler/storage/db/DbModule.java 
> 436d3841b9361df4db98a2217e61abb95e6e6bab 
>   
> src/test/java/org/apache/aurora/scheduler/mesos/CommandLineDriverSettingsModuleTest.java
>  9e176882246b48ac87bf35c77ac8c449a0a53352 
> 
> Diff: https://reviews.apache.org/r/34566/diff/
> 
> 
> Testing
> -------
> 
> ./gradlew -Pq build
> Connecting to H2 in Vagrant.
> 
> 
> Thanks,
> 
> Maxim Khutornenko
> 
>

Reply via email to