I have a couple of user document related questions regarding storing the password .
Since all my sync gateway user sessions will be fetched using the admin API and I’ll be authenticating with my own custom provider, what is the point of storing password in the user document?
Does the databases.foo_db.allow_empty_password option make is so you can only authenticate through sync gateways admin API? or does it make it so users can authenticate through the public API without password?
What is the best practice if I never have a need to authenticate users through the sync gateway public API? Should I store their password from my custom authentication provider in the user document? Should I/ Can I disable the public _session endpoint? What do others do?
There’s no point in the password if the user won’t authenticate with it. You can store something random there if you want to prevent normal login. (I’m not sure if setting the disabled property would work, or if it would also prevent custom auth.)
I believe this allows authentication without a password, for situations where clients may want to select a user ID for filtering purposes but not authentication.
A random password should suffice. You could use middleware to block the _session endpoint and also any requests using HTTP auth.
Disclaimer: I haven’t worked on SG in a few years, so my understanding may be wrong or out of date.
Thanks. I will create the users with a strong random password and will will not store that password anywhere (except the hash SG keeps in the user document). I’ll put a load balancer in front of SG and have the load balancer return 404 on any traffic to the _session endpoint.