IRCLogs20101209 (diff)

You must first sign up to be able to contribute.

Changes between Version 1 and Version 2 of IRCLogs20101209

lsmith (IP:
12/12/10 11:56:14 (7 years ago)



  • IRCLogs20101209

    v1 v2  
     5== Refresh user after unserializing == 
     6This topic was discussed "accidentally". This topic is about giving the provider a chance to refresh the user data after it was unserialized in a new request. Fabien said that he likes the patch Johannes wrote but still needs a bit of time to review all the changes in a branch he created for this 
     8== Addition of Remember Me capabilities == 
     9Currently the security firewall does not offer any hooks to do RememberMe cookie handling. Again Johannes has written a patch for this, but its again a large merge and depends on the 252 pull. Due to the size Fabien again asked for more time to review the patch, but said it looks good in principle. Bulat asked "how would remember me work with rest apis" but it was agreed that its not relevant for REST API's 
     11== Service Container wrapper == 
     12Lukas proposed this as an alternative approach to adding wrappers around extensive services, which can be problematic for those injecting services explicitly when the service being injected is optional. The idea would be that most people that inject services explicitly do so because they want to have control over the exact services being injected. The wrapper would add a possibility to get tighter control over the dependencies while injecting the container and thereby no longer suffering from performance penalties for optional dependencies. However an overwhelming majority did not find this proposal feasible. 
     14== More flexible password encoding == 
     15Another Johannes patch Right now the security firewall offers a very tight interface that providers can implement (getPassword() and getSalt()) with the algorithm hardcoded. However this means that one authentication source may only use a single hashing algorithm. Furthermore the user account object needs to implement hashing for user creation on its own, requiring duplicate configuration and code. This patch explores various ways for either the user account object or the security firewall to rely on the other side for hashing to enable more flexibility. Jeremy disagree's favoring to keep things separated and simply rely on ext/hash on both sides. The topic did not conclude with a final decision. 
     17== Eager Response Creation Options == 
     18Another Johannes topic: "idea for the eager response is that you always have a response available for each request which you can modify at every point during the processing of each request". This is particularly relevant for listeners that act before the controller is created where usually the response is instantiated. However for example setting a RememberMe cookie currently requires storing that cookie somewhere in the security context and then applying the changes in the "core.response" listener. Jeremy mentioned that he is currently discussing with Kris the "idea of kernel being the request/response container" aka using factory methods in the Kernel rather than the DIC to make instances of these services. Fabien interjected that he "really like the possibility to just "return new Response();"". And there was agreement about the fact that it seems wrong to create the Response before the Controller. The topic did not conclude with a final decision. 
     20== Removal of the generic field block in form.twig == 
     21During the last refactoring of form.twig the generic "field" block was removed in favor of just a "field_group" which handles the rendering of the errors/labels/widget and specialized field blocks for every widget type. This means adding some formatting to just fields isn't possible anymore and using the "field_group" is often not feasible when using lists or tables for example, since there is no sensible way to injecting submit buttons or table headers in that case. Since Bernhard wasn't at the meeting Lukas said he would raise the issue with him once more to get a resolution. 
    523= IRC logs =