web-dev-qa-db-fra.com

Échec de la connexion de l'utilisateur sur le serveur de production à l'aide du framework Symfony (la demande d'authentification n'a pas pu être traitée en raison de ...)

J'utilise Symfony pour un projet et j'ai essayé d'obtenir le login pour travailler sur le serveur de production sans succès depuis 2 jours. Je reçois toujours l'erreur

La demande d'authentification n'a pas pu être traitée en raison d'un problème système.

J'ai suivi le guide ici ( http://symfony.com/doc/current/cookbook/security/entity_provider.html ) pour configurer le chargement des utilisateurs à partir de la base de données.

Mon fichier security.yml :

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 }

Mon 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
}
}

J'ai essayé de télécharger le projet sur 2 hôtes Web différents (FatCow & GoDaddy) et le problème persiste. Localement, j'utilise PHP 5.4.19 (FatCow utilise 5.3.2 et GoDaddy utilise 5.4.37). Gardez à l'esprit que lorsque vous travaillez sur localhost avec XAMPP, tout fonctionne bien!

J'ai confirmé que PDO est activé dans les deux cas. J'ai confirmé que le nom d'utilisateur, le mot de passe et l'hôte de la base de données sont corrects dans le fichier parameters.yml . Les journaux d'erreurs sur les serveurs locaux et distants ne montrent rien.

J'ai suivi toutes les directions de ce post précédent Déploiement de l'application Symfony2 obtenant des erreurs fosuserbundle et toujours pas de succès.

J'apprécie toute l'aide à l'avance.

16

MISE À JOUR: Problème résolu. Le problème était qu'une table dans le fichier php d'entité était nommée en lettres majuscules tandis que la table de base de données était nommée en minuscules. +1 à ClémentBERTILLON pour avoir pointé dans la bonne direction, à savoir prod.log

On dirait que l'erreur:

La demande d'authentification n'a pas pu être traitée en raison d'un problème système.

est trop générique et ne dit rien de l'endroit où se trouve le problème (il y a un problème ouvert à ce sujet ici ).

J'ai résolu mon problème en vérifiant les journaux et voir ce qui s'est passé (dans var/logs/dev.log), en espérant que cela aide quelqu'un.

Dans mon cas spécifique, il y avait un mauvais paramètre dans parameters.yml à propos de la connexion à la base de données. Mais, encore une fois, l'erreur est trop générique et n'implique pas nécessairement que le problème est lié à la connexion à la base de données.

14
Francesco Borzi

Ce problème peut être corrigé en exécutant la commande: php bin/console cache:clear --env=prod --no-debug

7
Luis Jimenez

Dans mon cas, j'ai changé d'entité utilisateur, puis j'ai oublié de mettre à jour la table.

pour la mise à jour du tableau:

php bin/console doctrine:schema:update --force
2
pdchaudhary

COMME @ShinDarth le mentionne. C'est trop générique et l'inspection des journaux aidera les gens dans notre cas à passer au travers.

Si cela peut aider dans ma situation, c'était:

Après une installation de SonataUserBundle dans SF3, j'ai dû

bin/console doctrine:schema:update --force

Mon contexte est particulier, j'avais déjà installé et utilisé FOSUserBundle avant d'installer SonataUserBundle. (En raison de la compatibilité de SF3 avec FOSUser/SonataUSer ... la base de données a été prise 16 requêtes par la suite. Fonctionne très bien.

2
Paul Leclerc

Cette solution est correcte pour moi: https://stackoverflow.com/a/39782535/240037

Mais si vous n'avez pas accès au terminal, vous pouvez entrer dans le serveur et supprimer les dossiers qui se trouvent à l'intérieur var/cache.

Une autre solution si vous avez accès à la console consiste à taper

#rm -rf var/cache/*

ou

$Sudo rm -rf var/cache/*

cette solution fonctionne sur symfony 3

1
juanitourquiza

Je suis sûr que cette erreur est trop générique. Dans mon cas, ce qui suit est incorrect:

class: App/Entity/User;

Correction:

class: App\Entity\User;
1
Yuchen BAI

Actuellement, il y a un bogue dans Symfony et sur la production IF pendant une erreur du système d'authentification (table manquante, colonne manquante ou toute autre exception) - il est enregistré en tant qu'INFO au lieu d'ERREUR et avec les options de journalisation des erreurs par défaut, il n'est pas du tout enregistré.

https://github.com/symfony/symfony/pull/28462

Je pense qu'il y a deux options en ce moment - tout enregistrer temporairement (y compris INFO) sur la production jusqu'à ce que vous trouviez la vraie erreur.

Deuxième option: utiliser ce patch ou déboguer directement en production.

1
CappY

Dans mon cas, le problème a été résolu en corrigeant une faute de frappe dans les détails de connexion dans le .env fichier.

0
Sanjok Gurung

Une autre cause possible pourrait être MySQL Server. Dans mon cas, j'ai oublié de démarrer MAMP/MySQL Server et Symfony a généré ce message.

0
Dino

Vous avez probablement utilisé le modèle fourni par les documents Symfony ici :

{% if error %}
    <div class="alert alert-danger">{{ error.messageKey|trans(error.messageData, 'security') }}</div>
{% endif %}

Ce qui vous donne en fait ce message d'erreur. Le moyen le plus simple et le plus fiable de résoudre ce problème consiste à remplacer cette ligne par ce qui suit:

<div class="alert alert-danger">{{ error }}</div>

Ce qui vous donnera la trace complète de la pile de votre erreur et (espérons-le) vous aidera à déboguer votre application. N'oubliez pas de revenir sur cela avant de passer à la production!

0
gogaz