2016-09-26 1 views
0

J'ai le scénario suivant: Une application peut être installée par les clients eux-mêmes et comme tous les hébergeurs ne fournissent pas d'accès à la console, les clients doivent pouvoir installer et mettre à jour l'application via le navigateur. (Similaire au processus de mise à jour, par exemple Piwik)Symfony: migration de la table utilisateur via le navigateur

Exécution des commandes dans des contrôleurs spécifiques est aucun problème:

// src/CoreBundle/Controller/UpdateController.php 
public function updateAction() 
{ 
    $application = new Application($this->get('kernel')); 
    $application->setAutoExit(false); 

    $input = new ArrayInput(array(
     'command' => 'doctrine:migrations:migrate', 
     '--no-interaction', 
    )); 

    $output = new BufferedOutput(); 
    $application->run($input, $output); 

    return $this->render('system/update.html.twig', [ 
     'dump' => $output->fetch() 
    ]); 
} 

Actuellement, cette voie peut être désactivée via la configuration telle que chaque utilisateur de l'application peut démarrer le mise à jour mais seulement les administrateurs. (À l'avenir, l'accès de la route devrait être limitée aux comptes admin)

Le problème entre en jeu lors de l'ajout des migrations pour la table utilisateur:

// app/Resources/DoctrineMigrations/Version20160926090600.php 
public function up(Schema $schema) 
{ 
    $this->addSql('ALTER TABLE `user` ADD `gender` tinyint(1) unsigned NOT NULL DEFAULT 0'); 
} 

Dès que ce champ est ajouté à l'entité utilisatrice, L'accès Web échoue lorsque la doctrine tente d'extraire des données à partir de user.gender pour renseigner les données de compte pour le contexte de session/sécurité.

Existe-t-il un moyen de contourner ce problème? Est-il possible de désactiver l'extraction de données de la table utilisateur pour une route spécifique? Ou encore mieux, car ce dernier ne fonctionnera pas si l'authentification est nécessaire pour accéder à /route: Est-il possible de dire à la gestion de session de ne récupérer que quelques colonnes?

Ou ai-je besoin de ne jamais rien changer dans la table des utilisateurs si j'ai besoin de gérer les mises à jour via les contrôleurs?

Le security.yml actuel:

security: 
    providers: 
    appuser: 
     entity: 
     class: CoreBundle:User 
    firewalls: 
    default: 
     anonymous: ~ 
     http_basic: ~ 
     provider: appuser 
    dev: 
     pattern: ^/(_(profiler|wdt)|css|images|js)/ 
     security: false 

Répondre

0

Comme il semble que personne n'a une bonne solution pour cela, je dois désactiver le pare-feu complet pour cette voie particulière. Cela ne fonctionne que tant qu'aucune authentification n'est utilisée (par exemple pour les comptes administrateur):

security: 
    firewalls: 
    setup: 
     pattern: ^/(update|install) 
     security: false