[_3u10]

For external users of the API this can be quite helpful when you’re looking for the password column on the users table.

For some reason I don’t think graphql actually works this way. Can’t quite put my finger on why allowing access to any column on a table might be a really bad idea.

[HelloNurse]

Putting passwords in a database, and that database behind some kind of service that allows queries, is a stupid mistake that can be implemented with SOAP, CORBA, a remote shell, or any other protocol or API style.

I don't think GraphQL makes the problem worse except by encouraging experimentation by putting an unusually powerful query language in the hands of the users

[jonhohle]

Ancestors of your post are suggesting exposing entire DB schemas (I would assume mechanically). While that could also be the case in other protocols, typical an IDL is used to separately define the API layer. Of course it’s completely possible to generate a WSDL, etc. from a DB schema, in practice I’ve never seen it done.

[HelloNurse]

My point is that passwords shouldn't be stored in the "normal" database where some clever architect might expose entire DB schemas to external access.

If clever architects manage to expose the carefully segregated database of the small and secure authentication module, they cannot claim it was an accident or someone else's fault,

[charcircuit]

>Can’t quite put my finger on why allowing access to any column on a table might be a really bad idea.

Privacy