<table role="table">
<thead>
<tr>
<th>Q</th>
<th>A</th>
</tr>
</thead>
<tbody>
<tr>
<td>Bug report?</td>
<td>yes</td>
</tr>
<tr>
<td>Feature request?</td>
<td>no</td>
</tr>
<tr>
<td>BC Break report?</td>
<td>no</td>
</tr>
<tr>
<td>RFC?</td>
<td>yes</td>
</tr>
<tr>
<td>Symfony version</td>
<td>3.1</td>
</tr>
</tbody>
</table>
<p dir="auto">While testing disabling a user, I decided to try to impersonate the disabled user and found that you are able to impersonate the user as normal (as if they were never disabled). I expected the user should be disabled. Is this expected behavior?</p>
<p dir="auto">When I log out, then try to log in as the disabled user, I am properly alerted that the account is disabled and am not logged in.</p>
<table role="table">
<thead>
<tr>
<th>Q</th>
<th>A</th>
</tr>
</thead>
<tbody>
<tr>
<td>Bug report?</td>
<td>no</td>
</tr>
<tr>
<td>Feature request?</td>
<td>yes</td>
</tr>
<tr>
<td>BC Break report?</td>
<td>no</td>
</tr>
<tr>
<td>RFC?</td>
<td>yes</td>
</tr>
<tr>
<td>Symfony version</td>
<td>4.1</td>
</tr>
</tbody>
</table>
<p dir="auto">Currently, we have 2 separate annotation loaders for the routing: one in SensioFrameworkExtraBundle (SFEB) and one in FrameworkBundle (FB) which was added more recently. The component only has an abstract class (used by both).</p>
<p dir="auto">The FB loader was added more recently (in 3.4), as we encouraged using annotation more and more and people wanting to have support in core. But it is missing a few features:</p>
<ul dir="auto">
<li>generated controller name is not as clean as the SFEB one when using <code class="notranslate">__invoke</code> (probably added in SFEB after the port to core, and not backported)</li>
<li>missing support for service id AFAIK (the core annotation does not have the <code class="notranslate">service</code> property)</li>
<li>SFEB supports extra <code class="notranslate">@Method</code> annotations (and its subclasses for <code class="notranslate">@GET</code> and <code class="notranslate">@POST</code>). I'm not sure how common they are. An option could be to deprecate them.</li>
</ul>
<p dir="auto">Having 2 diverging implementations makes maintenance harder (and enabling SFEB changes the loader being used, so adding a new feature in the FB loader is dangerous as installing SFEB would replace it, and the <code class="notranslate">annotation</code> Flex alias installs SFEB).</p>
<p dir="auto">Here are my suggestions:</p>
<ul dir="auto">
<li>fix the support for <code class="notranslate">__invoke</code> in FB so that both loaders are in sync in 3.4 (I would consider it a bug that the implementation is different here)</li>
<li>evaluate the possibility for SFEB to extend the FB implementation so that it does not have to duplicate the logic (especially for future core features). Requires bumping min version to Symfony 3.4 in SFEB.</li>
<li>consider moving the AnnotatedRouteControllerLoader to the component rather than FB (there is nothing really specific to the bundle in it)</li>
<li>consider deprecating the SFEB routing layer (depends on the usage of <code class="notranslate">@Route(service="...")</code> and <code class="notranslate">@Method()</code></li>
</ul>