net.liftweb.util.Props and tree-like access

[Nathaniel Ford]

I'd like to have a properties file that handles a prefix-dot notation:

  db.user=MyUsername

  db.password=HardToPredict

  db.url=jdbc:mysql://localhost/

  api.endpoint=/doFunThings  

etc.

The `net.liftweb.util.Props` class allows easy access through, say, `Props.get("db.user")`, but I'm finding that what I often need are all of the db-related properties in one Map from their last property name (i.e. 'user', 'password', 'url') to the corresponding values, rather than the entire properties file at once or each of them piecemeal. Obviously, I could write something to do this myself, but I was wondering if it already exists, and if so where? There is nothing obvious in the Props API, or the rest of the net.liftweb.util package, but I wanted to make sure I wasn't either missing something, or if there was another best-practice to handle this situation.

Thanks so much!

Nathaniel Ford

[Diego Medina]

Hi Nathaniel,

Like you found out, Props doesn't have what you are looking for. There is nothing wrong with you implementing something that groups all values with a prefix and puts them in a specific Map. I personally like having individual vals for each entry and I do prefix our entries in the props file, similar to what you describe, db.*, mail.* (for smtp host, port, etc), etc

As for best practices, something we have done for some time now on our team is to store information like credentials, db host, port, message queue host and other sensitive information on vault https://www.vaultproject.io/ for our production, staging and pilot servers. But we still use good old props files for test mode.

I'll be happy to expand on the usage of vault if you want me to.

Hope it helps.

Diego

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Diego Medina
Lift/Scala Consultant
di...@fmpwizard.com
http://blog.fmpwizard.com/

[Nathaniel Ford]

Thanks for the prompt reply! It makes me less nervous rolling my own code to do this if I'm more certain it's not going to cause awkward friction with something else already in place.

Do you mind expanding on Vault and how you integrate with it? That actually looks like precisely the sort of thing we'd want to use!

Thanks!

Nathaniel

[Diego Medina]

Sorry for the delay (team meeting on another state)

Thanks for the prompt reply! It makes me less nervous rolling my own code to do this if I'm more certain it's not going to cause awkward friction with something else already in place.

great

 

Do you mind expanding on Vault and how you integrate with it? That actually looks like precisely the sort of thing we'd want to use!

Vault has an http api (rest) that you use from your app to "get" info stored in it. This makes it really easy to interact with it from any language, just pick your favorite http client and off you go.

So we (Tim Nelson) created an object that basically talks to the http endpoint of vault to get mongodb credentials, credentials for rabbitMQ and smtp info from Boot.scala, and then use that information to start connections to each of the services we use. The "get" methods in this scala object have a fall back to lookup the information on props files. This is used when we run the app in dev mode locally or when we run tests.

The fact that it's a REST api makes the integration really simple.

The other side is the ops, as an ops person, you store "secrets" using their command line, their docs are actually pretty good and give you several examples of how to store data.

P.S. we currently have our web app running Lift but we also have some batch processes that are written in Go https://golang.org/ , and having the credentials stored in vault makes it very easy to have both apps read them from the same place.

Hope this helps.

Diego

[Antonio Salazar Cardozo]

Notably, in Lift 3, you'll be able to plug Vault or a similar credentials

provider into the Props system rather than the other way around by

plugging in a `PropProvider`. `PropProvider` is currently a `Map[String,String]`,

but this brings up an idea that we could make it a `(String)=>Option[String]`

to allow for lazily fetching stuff like this. Not sure how good of an idea

it is to introduce a lazy-load delay in something that could happen at

an arbitrary point during app execution.

Thanks,

Antonio

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.