2012-09-15 13 views
5

La mia testa è sanguinante per quanto sia stato duro a sbattere contro questo muro da parecchie ore. :(Perché PHP PDO ottiene "SQLSTATE [42000] [1044] Accesso negato per utente" quando la riga di comando mysql funziona?

Come suggerisce il titolo, ho creato un utente MySQL in grado di accedere al database multa dal prompt dei comandi mysql sul server di database. Tuttavia, quando provo a un'istanza di un nuovo oggetto PDO per accedere al database con lo stesso utente, ottengo:

SQLSTATE[42000] [1044] Access denied for user 'bob'@'localhost' to database 'my_database' 

Ecco come ho creato l'utente:!

GRANT SELECT, DELETE, EXECUTE, INSERT, UPDATE ON my_database.* TO 'bob'@'localhost' IDENTIFIED BY 'some_password'; 

Quale potrebbe essere il problema qui ?! per favore qualcuno mi passi un osso (FYI, il problema succede quando provo a creare un nuovo oggetto PDO ... Prendo un PDOException e questo è il messaggio).

ho fatto FLUSH PRIVILEGES dopo la concessione, ed ecco l'output di SHOW GRANTS:

mysql> SHOW GRANTS FOR 'bob'@'localhost'; 
+------------------------------------------------------------------------------------------------------------+ 
| Grants for [email protected]                     | 
+------------------------------------------------------------------------------------------------------------+ 
| GRANT USAGE ON *.* TO 'bob'@'localhost' IDENTIFIED BY PASSWORD '.........................................' | 
| GRANT SELECT, INSERT, UPDATE, DELETE, EXECUTE ON `my_database`.* TO 'bob'@'localhost'      | 
+------------------------------------------------------------------------------------------------------------+ 

Ed ecco cosa mysql.db assomiglia per questo utente:

mysql> SELECT * FROM db WHERE User = 'bob'\G; 
*************************** 1. row *************************** 
       Host: localhost 
        Db: my_database 
       User: bob 
      Select_priv: Y 
      Insert_priv: Y 
      Update_priv: Y 
      Delete_priv: Y 
      Create_priv: N 
      Drop_priv: N 
      Grant_priv: N 
     References_priv: N 
      Index_priv: N 
      Alter_priv: N 
Create_tmp_table_priv: N 
    Lock_tables_priv: N 
    Create_view_priv: N 
     Show_view_priv: N 
    Create_routine_priv: N 
    Alter_routine_priv: N 
     Execute_priv: Y 
      Event_priv: N 
     Trigger_priv: N 

Nel caso in cui conta , questo è un cluster MySQL a quattro nodi in esecuzione su Ubuntu 12.04 LTS.

MODIFICA: ho scoperto che il problema si verifica solo quando provo ad accedere al server utilizzando Zend AMF. Qualche idea sul perché PDO non funzionerebbe con Zend AMF? Ho forse perso qualcosa nel mio setup Zend AMF?

+4

L'hai fatto eseguire 'FLUSH PRIVILEGES' dopo aver eseguito quella' GRANT'? –

+0

Modifica la tua domanda per aggiungere ulteriori informazioni. Il codice nei commenti è illeggibile. –

+0

Presumibilmente, 'GRANT' aggiorna direttamente la cache dei privilegi del server, quindi' FLUSH PRIVILEGES' non dovrebbe essere richiesto. Ne hai bisogno solo se modifichi direttamente le tabelle 'mysql. *' – lanzz

risposta

5

Prova "bob'@'127.0.0.1". Se php vi accede tramite 127.0.0.1, non verrà mai chiamato "localhost" poiché la risoluzione DNS locale non si verifica e MySQL negherà l'accesso ad esso.

3

Per i futuri googler, ho avuto lo stesso problema proprio ora ed ero abbastanza sicuro che la password fosse corretta. Sì, la password era corretta, ma il problema è come genero la password e come mantengo la password nel file di configurazione.

Se si utilizza un generatore di password casuale come me, assicurarsi di non avere il codice $ con la propria password.

Se hai $ in voi la password quindi assicuratevi di mantenere la password nel file di configurazione utilizzando apostrofi come questo

$pass = 'randomchars$morerandom'; 

ma non con doppi apici come questo

$pass = "randomchars$morerandom";