Insecure?

[omh]

Hi,

Thanks for putting this example together! I was wondering if you've been able to hide the super_secret inside the function? From what I understand Postgres doesn't really allow you to hide the source of functions from users. So in the face of a SQL injection any embedded secret would be available to the user from the source of the function. The only way to hide it that I've seen would be to put the secret inside a table which the user doesn't have access to. This adds a bit of overhead though.

I do think this approach is very useful. It does raise the level of effort involved in exploiting SQL injections. Maybe add a note about the caveat it in the README?

[mbuhot]

Hi @omh, thanks for raising this, I wasn't aware of the ability to dump the source code from SQL.

I'm thinking of rewriting this example app to demonstrate using RLS as an alternative to the ecto prefix: for cases where db-per-tenant or schema-per-tenant aren't desirable, with less emphasis on mitigating SQL injections.

[omh]

Sounds great, looking forward to reading it! 😄 👍