Georg- I hear you regarding the symfony1 docs. There are a few things that will make Symfony2 different:
* We have a dedicated person for the docs (me) * Github - the entire community is actively helping us make changes * Requiring doc updates for pull requests - Fabien is going to start doing this - if you have a change to the core, you'll also need to update the documentation appropriately. Since I'll be merging in the doc changes - this also makes sure that I don't fall behind when things change * The stability of the core. The book is meant to be written so that it will need very little maintenance throughout Symfony2. The more advanced things or things that may undergo more change will be in the cookbook. When there's a new Symfony2 release (e.g. Symfony 2.1), we can focus on the changeset and how it affects the cookbook articles (do any need to be deprecated, etc). So, I'm looking forward to a much smooth future with respect to the docs, in large part due to good planning and an active community. Per the problem of older versions of docs coming up in google before the newer versions, I'm not sure how we can fix that. Perhaps the problem is that the links to the docs have always had the version in the URL ( http://www.symfony-project.org/gentle-introduction/1_4/en/17-Extending-Symfony). Going forward, if we used "current" in the URL to point to the latest version (PHPUnit does this), it should solve that problem, at least in large part. Thanks! Ryan Weaver US Office Head & Trainer - KnpLabs - Nashville, TN http://www.knplabs.com <http://www.knplabs.com/en> http://www.thatsquality.com Twitter: @weaverryan On Wed, Apr 20, 2011 at 7:24 AM, Johannes Schmitt <[email protected]>wrote: > > - "loadByUsername()": Is this really intended to load a user by username? >> Or can username also be the ID ? Loading users by username will make the >> system instable if users have the possibility to change their usernames. >> >> > Yes, this can be anything. > > > >> - putting the username into the rememberMe cookie has the same issues and >> even worse you put private/personal data into a cookie, a cookie should >> never contain any personal data. The username could also be a customer id or >> an email address and I don't want any cookie to contain such data. It should >> only contain a signed random id and all sensible data should be stored >> anywhere on the server. >> > > We have two flavors for remember-me. One which is simple to set-up and > which stores in a readable format the username, the user's class, and the > expire time in the cookie. The other implementation requires you to set-up a > token provider and only stores two random hashes in the cookie. The former > is mainly intended for private websites, the latter is for anything more > serious. > > > >> - performance: has anyone tested the performance of all the nice security >> features? I'm afraid it will slow down my application if I have to deal with >> 200 roles or so.. why do we need so much classes/objects? >> > > Can you give better examples? 200 roles seems always inefficient no matter > what the actual implementation is. > > > >> - what I miss is a way to prevent brute force attacks: block IPs or >> usernames on too many login attempts, hundrets of files.. but the most >> important feature the framework could provide to make applications much more >> secure is missing.. :-( >> > > It's possible. A typical use case is to return false from isAccountLocked() > if there were too many failed login attempts. > > > >> - also there is no way to define roles/rights in a bundle, I don't >> understand how you want to handle this when a user needs some roles or ACL >> rights to use a bundle >> > > I think you can have a look at the CommentBundle for how to do this. > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
