ddev has these default settings:
database: db
dbuser: db
password: db
I thought it should be possible to provide customized values for that (I know it doesn't make too much sense, but still). I was looking for these settings in config.yaml, but no luck.
Is it possible to modify those credentials and add them to git?
You can change database credentials any time if it seems useful to you. You have full root on the mysql database. So ddev mysql -uroot -proot will get you in there where you can GRANT ALL on db.* to 'mynewuser'#'%' IDENTIFIED BY 'mynewpassword'; That will create a new user with full privs on the 'db' database. But you can also create new databases and new users as much as you want. And if you want, you can change the password of the 'db' user. We try to make it as simple as possible for local dev... but if you want to make it more complicated, go for it!
There are a couple of items in the FAQ that may help as well - about multiple databases and database credentials.
If you remove the default credentials, of coures, you have to change your CMS's settings files to credentials that will work.
Related
How to configure a PSQL v11.4 user that is not the superuser and does not own the database.
This user should have full access to create SQL objects and drop them, even
though they do not own the database, so they can not drop the database.
All sql/database objects exist on the PUBLIC schema.
So far I have tried:
CREATE USER app_user WITH ENCRYPTED PASSWORD 'foo_bar';
ALTER USER app_user NOCREATEDB NOCREATEROLE;
ALTER USER app_user VALID UNTIL 'infinity';
GRANT ALL PRIVILEGES ON DATABASE database TO app_user;
When running Rails migrations I get the following error:
remote: PG::InsufficientPrivilege: ERROR: permission denied for table schema_migrations
Seems like the psql best practices is to have a role with privileges
set, then assign the user to be a member of that role. However because everything
is on the public schema all users/roles should have full access right? However
this line in the docs is throwing me off:
"The right to drop an object, or to alter its definition in any way, is not treated as a grantable privilege; it is inherent in the owner, and cannot be granted or revoked. (However, a similar effect can be obtained by granting or revoking membership in the role that owns the object; see below.) The owner implicitly has all grant options for the object, too."
from: https://www.postgresql.org/docs/11/sql-grant.html
Also though because the database is being restored via the sudo user, objects
will be owned by the sudo user, however new objects could belong to the
app_user, is this an issue?
You need the CREATE privilege on the database, and you need to pg_dump (or pg_restore with the -x and -O options, so that the restoring user becomes the object owner and no additional privileges are granted.
Some things, like certain extensions, event triggers or functions in untrusted languages (to name a few examples) require superuser rights to create them. Either avoid such objects or create them ahead of time and ignore the errors.
I'm setting up user authentication on mongoDB and would like my rails app to still be able to communicate to the DB.
I have the configurations set properly as far as I know, but get the error Not authorized on <db> to excecute command { distinct: "<collection>", key: "<field_name>", query: {} }
Currently I am using 'webUser' with readWrite privileges.
What mongoDB privilege do I need to grant the web user to run this query?
Btw, I do have auth_source, username, password, roles declared properly in mongoid.yml
Thanks in advance!
Update - screenshot of db users:
I have a rails 4 app where I am using devise for authentication and it works perfectly. My only problem is that it loses the session of a user after I deploy it on the server and the users have to sign in again.
If I just do a restart of nginx/passenger (which I am using for my app) it doesn't loses it.
When I am deploying my app I am losing it. For deploying I am also wipe out all the database automatically and my deployment script runs the seeds file which it also generates the users.
We are currently developing the app so this kind of behavior is acceptable for now, but in the
future when the app will be ready, we won't do it like this way (of course!).
So is this an issue due to the reseeding or I should check something else? I see that the encrypted password changes everytime I run the wipe out/seed action, does this have to do with the losing of user session?
You should never wipe out a database during deployment. Imagine that your app is running and you have hundreds of users. Now you make some changes in the code and do a deploy. POOF all your data and users are gone! Certainly this is not what you want.
Secondly, users getting logged out when you wipe out the database could be due one of the following reasons:
Are you seeding users with the same ID? If the user ID changes when you re-seed, it will cause users to be logged out
Are you storing sessions in the database using config.session_store :active_record_store instead of using cookies? In this case, wiping out the database will delete the sessions table and log out all users
Rails 4 uses an encrypted cookie store by default. Make you sure you're not changing your application's config.secret_token when re-deploying, in case its getting loaded from the database
Ultimately, wiping out the database is the sole reason why your users are getting logged out, and that is a bad practice. So the most important thing to fix is do not wipe data during deployments.
The reason for this behavior is the following:
Everytime some user changes his password, devise automatically signs_out him.
So, basically by reseeding the data, the password is recalculated (even though the password is the same, the new encrypted password is different from the old one). So the devise will automatically sign_out the user, because it seems like the password is changed (based on the different encrypted_password field).
I managed to bypass this behavior, by specifically setting up the encrypted_password in the seeds.rb file and bypassing the validation.
If I just do a restart of nginx/passenger (which I am using for my
app) it doesn't loses it. When I am deploying my app I am losing it.
For deploying I am also wipe out all the database automatically and my
deployment script runs the seeds file which it also generates the
users.
If you generate new users, the old ones will lose their sessions.
This is because the values of the new users will be different. For example, they might not have a remember token set, or if the session_id uses the values of user.created_at or user.token_generated_at they will be different every time you drop and recreate your database.
I have a number of 'system' passwords in my Rails app, such as database passwords and separate HTTP authentication passwords for an XML feed.
My trouble is knowing exactly how to store these passwords in my directory so they are as safe as they can be. What are your recommendations specifically for Rails 3?
encrypted in a database?
in environment config?
I've used both in the past. The reality is that HTTP passwords are more like an API key. The provider of the service has the responsibility that you can't do anything 'evil' with access. In general, recommend against putting anything in source control you don't want to be public. In the past, I've had to deploy separate key files outside of my app. If you're doing really secure stuff (a la credit cards), then you can do that. And just create a user on the server that has access to the keyfiles. Then you're actually using access to the Unix box as your security model, not the password to your keyfiles.
Just make sure to store your config-files in the config-folder (or at least outside the public-folder ;). Besides this you should secure the access to your rails-app-user-account from outside (force ssh-pubkey authentication).
Another security-flaw is checked-in config-files with sensible password information (e.g. database-access). I alway add config/database.yml to .gitignore and check-in a default config/database.sample.yml as a template for other developers. The "real" config/database.yml is created and configured manually with environment-specific configuration-values.
I use the SpringSecurity-framework for authentication, and it works as long as there is a user with the same name in my local DB.
However, I want an admin-account that is only stored in the local DB and has no equivalent in LDAP.
So, how can I configure SpringSecurity so that it uses LDAP and if this fails looks for a user and password in the local DB?
After hours of digging through google search results, source-code and documentation, I finally got it!
Just set the providers you want in your SecurityConfig.groovy
providerNames = ['daoAuthenticationProvider',
'ldapAuthProvider']
Please note, that the names are not consistent. That took me quite a bit, hope someone else can find it useful.