FOSUserBundle - SQLSTATE[28000] [1045] Access denied for user 'root'@'localhost' (using password: NO)

2
votes

This is frustrating. My set up worked fine on my dev machine, but gives me a

SQLSTATE[28000] [1045] Access denied for user 'root'@'localhost' (using password: NO)

error when deployed to shared hosting. My parameters.yml:

# This file is auto-generated during the composer install
parameters:
    database_driver: pdo_mysql
    database_host: mysql.server322.com
    database_port: 3306
    database_name: adirule_db
    database_user: adirule
    database_password: Ref1ect0b0l1!
    mailer_transport: smtp
    mailer_host: localhost
    mailer_user: null
    mailer_password: null
    locale: en
    secret: ThisTokenIsNotSoSecretChangeIt

config.yml:

# Doctrine Configuration
doctrine:
    dbal:
        driver:   %database_driver%
        host:     %database_host%
        port:     %database_port%
        dbname:   %database_name%
        user:     %database_user%
        password: %database_password%
        charset:  UTF8
        # if using pdo_sqlite as your database driver, add the path in parameters.yml
        # e.g. database_path: %kernel.root_dir%/data/data.db3
        # path:     %database_path%

    orm:
        auto_generate_proxy_classes: %kernel.debug%
        auto_mapping: true

fos_user:
    db_driver: orm

I don't know where to look/how to fix this issue as I've never seen it before. It looks like it's bypassing my db user/password combo and defaulting to root/no password.

Any suggestions?

1
phpmysqlsymfonypdofosuserbundle
Thats exactly what it is doing. So are you sure everything got copied to the server? – RiggsFolly
Yes, given that it works fine through the command line when I try things like doctrine:schema:create and fos:user:create – Major Productions
So that works on localhost, did you do that on the server? – RiggsFolly
Everything on my dev box works fine. On the shared hosting I'm using, command line database activity, like generating the db schema or creating a new user, works, but in-app activity, like logging on, generates that error. – Major Productions

1 Answers

4
votes

Oddly, clearing the cache via $ app/console cache:clear --env=prod fixed it. No idea why. Hopefully it stays fixed and isn't some sort of lucky coincidence.