Sto lavorando su un'applicazione Symfony2 in cui vogliamo introdurre Security Voters. L'iniziativa DX (jay!) Ci ha portato the simpler version di questo meccanismo, quindi mi piacerebbe usarlo. L'unica cosa che mi disturba un po 'sull'uso di \Symfony\Component\Security\Core\Authorization\Voter\AbstractVoter
è il fatto che non posso più astenermi dal voto quando si implementa il metodo astratto isGranted
. Mi piacerebbe cambiarlo per la nostra applicazione, ma apprezzerei molto la tua opinione in materia dal punto di vista della sicurezza.Solo controllo: astenersi votare da Symfony AbstractVoter isGranted
Per essere chiari, nella nostra applicazione useremo la strategia direttore decisione unanimous
accesso - in breve: è necessario almeno un ACCESS_GRANTED
e nessun ACCESS_DENIED
- perché potremmo poi vogliono introdurre gli elettori per la messa al bando gli indirizzi IP o altri imbrogli .
Come mostrato nell'elemento di codice rilevante di seguito, non appena un'implementazione di supporta un attributo, il voto verrà impostato su Denied
.
public function vote(TokenInterface $token, $object, array $attributes)
{
if (!$object || !$this->supportsClass(get_class($object))) {
return self::ACCESS_ABSTAIN;
}
// abstain vote by default in case none of the attributes are supported
$vote = self::ACCESS_ABSTAIN;
foreach ($attributes as $attribute) {
if (!$this->supportsAttribute($attribute)) {
continue;
}
// as soon as at least one attribute is supported, default is to deny access
$vote = self::ACCESS_DENIED;
if ($this->isGranted($attribute, $object, $token->getUser())) {
// grant access as soon as at least one voter returns a positive response
return self::ACCESS_GRANTED;
}
}
return $vote;
}
Quello che mi piacerebbe fare è ignorare che con il codice qui sotto
public function vote(TokenInterface $token, $object, array $attributes)
{
if (!$object || !$this->supportsClass(get_class($object))) {
return self::ACCESS_ABSTAIN;
}
$vote = self::ACCESS_ABSTAIN;
foreach ($attributes as $attribute) {
if (!$this->supportsAttribute($attribute)) {
continue;
}
// This is where we differ from SymfonyAbstractVoter. Only if there is an outspoken yes or no, a vote is cast
// When returning null, it will still abstain
$grant = $this->isGranted($attribute, $object, $token->getUser());
if ($grant === true) {
return self::ACCESS_GRANTED;
}
if($grant === false) {
return self::ACCESS_DENIED;
}
}
return $vote;
}
Cosa ne pensi? È sicuro restituire ACCESS_ABSTAIN
quando viene restituito un valore nullo dal isGranted
e trasmettere un numero solo ACCESS_GRANTED
o ACCESS_DENIED
se un votante restituisce vero o falso?
Perché dovrei anche voler fare questo? Per fare ancora uso del AbstractVoter
(perché, sì, sono uno sviluppatore pigro) ma separare le mie preoccupazioni.
Diciamo che faccio un votante per un post, PostVoter
, che mi permetterà di modificare i miei messaggi. Quindi esegue il cast di un ACCESS_GRANTED
. Ma fino a quando non possiedo il post, questo elettore non si preoccupa davvero: dovrebbe solo trasmettere un ACCESS_ABSTAIN
. In seguito potrebbe incorrere in un AdminVoter
che continuerà a trasmettere un ACCESS_GRANTED
. Quando si utilizza la strategia del gestore delle decisioni di accesso unanimous
, tuttavia, se questo PostVoter
è stato già assegnato a ACCESS_DENIED
, non potrà mai accedere a nessun altro elettore.
non posso lanciare quella ACCESS_ABSTAIN
nel AbstractVoter
ora, senza l'override del metodo vote
e il punto centrale di elettori più semplici nella mia mente era, beh, per rendere più semplice :)
Grazie per quel puntatore. – Frank