heroku button?

[pvh]

This is super cool. Would you like a Heroku button so that it can be easily deployed? I did one for pgweb recently.

[begriffs]

The Heroku button is complicated by the fact that the usual Postgres Heroku addon does not provide a user account capable of running SET ROLE. This is the command needed to enforce user permissions. If you'll be running an API where everybody gets the same access (whether it's read-only or read-write) then the Heroku button can deploy just fine, but it won't work for an app that has differing permissions.

For a more capable db I spin up an Amazon RDS instance and set the Postgrest params to point at the remote server. Maybe the Heroku button could be combined with an html form to accept parameters somehow and you could specify where your db lives. Do you think that's possible?

[max]

@begriffs You can prompt the user for environment variables.

[mietek]

@begriffs: I packaged PostgREST so that it is possible to install it in one command, using Halcyon.

This makes it easy to add a Heroku button: https://heroku.com/deploy?template=https://github.com/mietek/postgrest

Here is a prototype DigitalOcean button: https://halcyon.sh/deploy/?url=https://github.com/mietek/postgrest

I have not tested this with a DB yet, as I do not have experience setting up RDS. Can you give me access to a test instance?

[begriffs]

@mietek, amazing work (as usual)!

I'll try it with a new RDS instance. If all is well I'll add the deployment buttons to the readme and a note saying how deployment is powered by haskell-on-heroku. This is going to be way more convenient than pre-building the binary all the time.

One detail: on the form below DB_AUTH_ROLE it says "Database role for authenticated requests" but in reality this is the role that will be used to verify credentials and switch to the user's actual role.

[mietek]

@begriffs: Thanks! There is a Halcyon-specific README in my fork: https://github.com/mietek/postgrest#postgrest

Please note Haskell on Heroku is just a thin wrapper around Halcyon. This means you can easily install PostgREST in the same way not just on Heroku, but also on regular machines, such as DigitalOcean droplets, and, potentially, EC2 instances

Sorry about DB_AUTH_ROLE — I was guessing. Can you suggest a better description?

[begriffs]

The heroku button should be good to go now.

[srid]

Is an app deployed via the "heroku button" supposed to seamlessly work with Heroku postgres? All I'm seeing is:

$ http --auth ${AUTH_ROLE}:${AUTH_PASS} get https://mypostgrest.herokuapp.com/
HTTP/1.1 401 Unauthorized
Connection: keep-alive
Date: Mon, 11 May 2015 04:07:46 GMT
Server: postgrest/0.2.8.0
Transfer-Encoding: chunked
Via: 1.1 vegur

Invalid username or password

Does it not support Heroku postgres's auth user/pass?

[alibitek]

@srid According to https://github.com/begriffs/postgrest/wiki/Heroku the answer is no. Postgrest doesn't seem to work with Heroku Postgres.

Note that the Heroku PostgreSQL addon will not work because it does not support having multiple database roles. Instead, it is recommended to create an instance of Postgres using Amazon RDS.

[pvh]

Look, obviously I'm biased as a super-long-time Heroku Postgres employee, but I really think using roles for this is a not awesome solution. The reason we haven't shipped roles isn't because it's hard, it's because they're often a foot-gun that results in problems. They're complicated, unintuitive, and if you try and secure things via roles you often end up getting into trouble unless you do one of a very small number of useful things (like, say, a no DDL role).

I'm sure at some point we'll get around to shipping something here, but I wanted to at least put out the idea that maybe it should be possible to use postgREST without requiring multiple role support.

[srid]

FWIW, having custom auth in postgrest would definitely be nice, as it allows me to deploy it to Heroku instead of managing my own servers! For this reason, spas uses postgrest but with basic auth. Ideally though I want to use something like OAuth.

[begriffs]

@pvh that's interesting to hear. Do you think that with the right documentation/checklist it is possible to avoid the pitfalls with db roles? The central idea behind the PostgREST experiment is to embrace the database and rely on it rather than creating duplicate app logic.

I'm happy to keep an open mind and explore possibly more convenient approaches to auth, but I'd like to understand how the built-in roles cause problems.