> 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?
> 
> Maxim Khutornenko wrote:
>     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 Khutornenko wrote:
>     AFAICT, there are only two ways to connect to the H2 DB: AUTO_SERVER and 
> TCP server. I explored the AUTO_SERVER earlier but unfortunately it does not 
> work for in-memory DBs 
> (http://h2database.com/html/features.html#auto_mixed_mode):
>     > Multiple processes can access the same database without having to start 
> the server manually. To do that, append ;AUTO_SERVER=TRUE to the database 
> URL. You can use the same database URL independent of whether the database is 
> already open or not. This feature doesn't work with in-memory databases.
>     
>     So, all we left with is a H2 dedicated server instance.

Actually, looking at their sources it appears that WebServlet creates its own 
WebServer instance, which in turn may serve the WebApp. This is promising. Will 
give it a try and report back.


- 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