2015-07-20 12 views
6

Sto usando Symfony per un progetto e ho cercato di ottenere il login per funzionare sul server di produzione senza successo negli ultimi 2 giorni. Continuo a ricevere l'erroreAccesso utente fallito sul server di produzione utilizzando il framework Symfony (Impossibile elaborare la richiesta di autenticazione a causa di ...)

Authentication request could not be processed due to a system problem.

ho seguito la guida qui (http://symfony.com/doc/current/cookbook/security/entity_provider.html) agli utenti l'installazione di carico dal database.

mio security.yml di file:

security: 
encoders: 
    Symfony\Component\Security\Core\User\User: plaintext 
    Acceptme\UserBundle\Entity\User: plaintext 
role_hierarchy: 
    ROLE_SUPER_ADMIN: [ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH] 

providers: 
    in_memory: 
     memory: 
      users: 
       patricia: 
        password: patricia 
        roles: 'ROLE_ADMIN' 
    users: 
     name: user_provider 
     entity: { class: AcceptmeUserBundle:User, property: username } 

firewalls: 
    user_area: 
     pattern: ^/ 
     anonymous: ~ 
     provider: user_provider 
     form_login: 
      login_path: login_route 
      check_path: _login_check 
      default_target_path: homepage 
    dev: 
     pattern: ^/(_(profiler|wdt|error)|css|images|js)/ 
     security: false 

    default: 
       anonymous: ~ 
       http_basic: ~ 

access_control: 
     - { path: ^/admin, roles: ROLE_ADMIN } 

mio SecurityController.php:

namespace AppBundle\Controller; 

use Symfony\Component\HttpFoundation\Request; 
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route; 
use Symfony\Bundle\FrameworkBundle\Controller\Controller; 
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Template; 
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Security; 
use Symfony\Component\Security\Core\SecurityContext; 

class SecurityController extends Controller 
{ 
/** 
* @Route("/login", name="login_route") 
* @Template("security/login.html.twig") 
*/ 
public function loginAction(Request $request) 
{ 
    if ($request->attributes->has(SecurityContext::AUTHENTICATION_ERROR)) { 
     $error = $request->attributes->get(SecurityContext::AUTHENTICATION_ERROR); 
    } else { 
     $error = $request->getSession()->get(SecurityContext::AUTHENTICATION_ERROR); 
    } 

    return array(
     'last_username' => $request->getSession()->get(SecurityContext::LAST_USERNAME), 
     'error'   => $error, 
    ); 
} 

/** 
* @Route("/login_check", name="_login_check") 
*/ 
public function securityCheckAction() 
{ 
    // this controller will not be executed, 
    // as the route is handled by the Security system 
} 
} 

ho cercato di caricare il progetto su 2 diversi web host (FatCow & GoDaddy) e il problema rimane. Localmente sto usando PHP 5.4.19 (FatCow usa 5.3.2 e GoDaddy usa 5.4.37). Tieni presente che quando lavori su localhost con XAMPP tutto funziona correttamente!

Ho confermato che PDO è abilitato in entrambi i casi. Ho confermato che il nome utente, la password e l'host del database sono corretti nel file parameters.yml. I log degli errori su server locali e remoti non mostrano nulla.

Ho seguito tutte le indicazioni da questo post precedente Deploying Symfony2 app getting fosuserbundle errors e ancora non ha avuto successo.

Apprezzo tutto l'aiuto in anticipo.

+2

Qualsiasi cosa nei registri ('app/logs/prod.log')? –

+0

http: // stackoverflow. it/questions/28135572/deploying-symfony2-app-getting-fosuserbundle-errors le soluzioni elencate qui aiutano? – Matiss

+0

@ ClémentBERTILLON Wow grazie mille. Il posto più ovvio da guardare e ho continuato a mancarlo, la frustrazione prende il sopravvento. Il problema era che un sql coundt trovava una tabella perché era stata nominata erroneamente nell'entità (con la lettera maiuscola) mentre la tabella del database era minuscola.Aggiornando la risposta per questo. Grazie mille –

risposta

6

AGGIORNAMENTO: problema risolto. Il problema era che una tabella nel file php dell'entità era chiamata con lettere maiuscole mentre la tabella del database era nominata con lettere minuscole. +1 per ClémentBERTILLON per puntare nella giusta direzione, ossia prod.log comando di marcia

+0

Tu dovrebbe contrassegnare questa risposta come accettata – AntoineWDG

+0

prod.log mi ha salvato, ha ottenuto un problema diverso da quello nella domanda anche se. Il mio era legato alla dimensione di 'max_allowed_packet'. Spero che questo aiuti qualcuno. – marijnz0r

-1

Questo problema può essere risolto: php bin/console cache:clear --env=prod --no-debug

+0

Puoi spiegare perché questo comando ti sarà d'aiuto? – ndsmyter

9

Sembra che l'errore:

Authentication request could not be processed due to a system problem.

è troppo generico e non dice nulla su dove si trova il problema (c'è un problema aperto su questo argomento here).

Ho risolto il problema controllando i registri e visto cosa è successo (in var/logs/dev.log), sperando che questo aiuti qualcuno.

Nel mio caso specifico, c'era un parametro errato in parameters.yml sulla connessione al database. Ma, ancora, l'errore è troppo generico e non implica necessariamente che il problema sia legato alla connessione al database.

0

AS @ShinDarth lo menziona. È troppo generico e l'ispezione del registro aiuterà le persone nel nostro caso a ottenere questo risultato.

se può aiutare nella mia situazione era:

Dopo un'installazione SonataUserBundle in SF3, ho dovuto

bin/console doctrine:schema:update --force 

mio contesto è particolare, ho avevo già installato e utilizzato FOSUserBundle prima di installa SonataUserBundle. (A causa della compatibilità SF3 con FOSUser/SonataUSer ... Il database è stato preso dopo 16 query. Funzionante ottimo

Problemi correlati