Since the new component Guard from Symfony I've started playing a little with it to learn it better and see what things it changes.
I've read the documentation from sf website to see what it brings and changes and i was wondering based on this example:
Let's say we create a login attempt counter that at some point will disable the user until password reset. Of course for this we would use the login failure handler.
But since guard should make everything easier i was wondering if we still need that handler or we just put a bit of logic in the onAuthenticationFailure / onAuthenticationSuccess / checkCredentials to do certain tasks like saving some info into database about the failed login etc and how much code should go in there.
The new Guard is aimed to ease the implementation of custom authentication patterns such as yours.
It is likely to be enough for most of the case even complex ones.
However, try to extract your custom processing, logging, etc. from your Guard and inject them to improve the maintainability of it.
Take a close look to GuardAuthenticatorInterface.php to find where and when in the process you have to set up your requirements.
Related
I´m working on a small Web-Application which will be having a private messaging system. While a user is signed in his received or written messages will be displayed in a toolbar area inside a dropdown menu. Nothing new :-)
The toolbar will be displayed most of the time while a user is travelling through the page. So instead of injecting the inbox implementation into each controller which might be called through routes.php I´m thinking about using the new blade function #inject.
This would look like this (abstracted)
Toolbar view calls ControllerMethod via #inject
ControllerMethod calls injected InterfaceMethod (constructor based Injection)
Service Container serves Implementation
ImplementationMethod returns inbox
But I´m not sure if this is a nice design pattern because I´m relatively new to dependency injection in general. I´d appreciate some thaughts.
There are 2 things here that are wrong to me.
1) Laravel's #Inject view directive does not actually do any sort of "Dependency Injection", despite it's name suggesting so. It is in fact using service location, a pattern which is widely considered anti-pattern.
Basically, via #Inject, the view has access to anything in the container. It can get anything it wants. It doesn't get told what it should have. That's the principle difference between dependency injection and service location.
2) Injecting services into the view directly will undoubtedly mean that you are adding more complexity to your application because you're added more places where services can be injected into your templates. While it may make things quicker and simpler looking short-term, long-term it will make things more difficult to work with.
3) How will you test how you fetch and control data if that's happening in your view? You'd likely have to use functional testing, which, while not a bad thing to be doing, is still not going to be as useful as unit testing for something like this.
I'd recommend sticking to how things are usually done in regards to DI, and actually use DI.
the problem (in a nutshell) is:
Our current solution way too slow.
The Symfony Security component reloads the user on every pageview.
Users are loaded from our own UserProvider that accesses a slow external API.
The first idea coming to our minds is:
We could cache information coming from the external API in a local database or memcache.
My questions:
Are there any bundles out there that could help us achieve this?
Should we deal with all of the caching in our own UserProvider?
Is it maybe a better idea to put users that need to be cached into a doctrine entity and use a chain provider to load them from doctrine first? In this case, how do we handle a limited lifetime of user objects?
How about not caching anything but just writing our providers refresh function so that it only reloads users if the last reloads happend too long back?
Any other ideas on how to do this efficiently?
Cheers,
Timon
Neither cache nor chained providers are a "perfect" solution as you have to implement logic which invalidates the user when changes in the external provider occur (e.g. changed password). Which, if I understand right, would require you to check against the API frequently. Seems like you have to compromise between performance and checking for updates frequently one way or the other.
That being said, I assume you already have a custom user provider which reads users via API and I don't see anything wrong with adding a cache as a dependency to that or maybe create a second CacheApiUserProvider next to your UserProvider, so you can switch between them when you are having troubles with your cache backend. I don't think there's an additonial bundle necessary for that, but you might want to look for caching-bundles.
I don't see how a chained provider as you propose in (3) would help you, as you would just have the same limitations, i.e. frequently check for changes in your external provider, just as with the cache. If I had to choose, I would use the CachedProvider as it is pretty much what you are trying to do, a more complicated chain provider would just conceal what problem you wanted to solve in the first place and confuse future maintainers (in short: keep it simple).
Depending on what the API provides you might be able to run a worker in the background which automatically fetches new users and changes to existing users from the API and moves them to a (local) database, but in that case I wouldn't bother setting up a chained provider and just rely on the database to be up to date.
I am new to programming and I am making a login/pass authentication system for a project in Code Igniter. I can simply secure pages by setting session and then giving access based on whether the session is set or not ... Before I jump into it ... I see many auth libraries around .. like tank auth, ion auth and so on.
My question is, why would anyone use Auth libraries? If my app is simple which means there will be just one kind of user with same permissions, do I still need Auth lib like Ion Auth?
Existing Auth libraries usually are tested by users and their bugs and security flaws are, often corrected and the code is mantained.
An own implementation of it, disregarding its simplicity, is allways a test on what you know and what you can do about handling security.
There are good CI Auth libraries, but if you're going towards your own be sure to make it as safe as possible, assuming every user input is malicious... and also, go on and take a look at this article
I am familiarizing myself with Symfony 2, after using Symfony 1.x for a few years.
I need to create a membership website that has a custom registration process. Additionally, the website dynamically generates user roles (formerly credentials in SF v1.x) to use to restrict access to portions of the site.
I have had a look at the FOSUserBundle and I can't see what it is offering over and above the code that is available on the 'How to load users from a database' link in the cookbook. I have a lot of custom logic involved in my user registration and user management, as I mentioned earlier, and I don't want to undergo a learning curve of using FOSUserBundle only to have to override a lot of the methods etc, with my own custom methods.
I don't know enough about Symfony2 to make the decision as to whether to learn from the cookbook code and extend it in my own UserBundle, or invest time learning how to use the FOSUserBundle and customize it with my custom logic.
In summary this is what I want to do with users:
Provide a custom registration workflow
Dynamically update a users role/group membership (initially during login, and subsequently, during the session).
My question then is - which course requires the minimum learning curve and effort for me (I have less than a week to get a barebones site up and running - and I'm only doing web development in my spare time).
Do I:
Write my own UserBundle, using the code in the cookbook as a starting point
Learn how to use FOSUserBundle and customize it with my custom logic? (see above)
It's an old subject but still very interesting nowadays. I disagree with Florent's answer, because i think it doesn't provide an objective view.
FOSUserBundle provides User and Group implementations, just as Symfony already provide, that you just need to configure. The cookbook and the official doc will allow you to get that working in less than a day.
The "full of features" controllers are interesting... as long as you stay in the way defined by this bundle. Don't be too original or you'll spend days overriding code and config of the bundle. Honestly, registration and lost password are easy to implements, and SF2 form's mechanism already make it easy to handle errors.
Views are minimalistic and uninteresting out of the box in FOSUserBundle, make your own ones.
If i had to compare both learning curves i would just sum it up like this : both take the same time to achieve a complex user management system, but you'll be much more in control of your code when writing your own provider.
Would be interesting, 2 years later, to know what choice you made and how it went, Homunculus Reticulli.
FOSUserBundle provides:
User and Group implementations
controllers with useful features (registration, lost password)
views
If you need these features, use this bundle, it will save your time!
I don't know how complex is your authentication logic but I'm pretty sure that it can fit with FOSUserBundle's one.
My web application only has one level of authorization. It's either you're logged in or not. Would ACL be overkill for this? Would the Auth component be sufficient/secure enough to handle this situation?
Does CakePHP session anonymous users? If so, is there a way to turn that off? I don't think I need sessions to be passed around if the user is anonymous.
The ACL component is only needed if you need to provide access to certain parts of the site to certain groups of users and not others. If you only need to know if someone is a user or not, Auth will have you covered.
By default, sessions are created for everyone. If you're not using them for anonymous users, it's okay to leave them turned on all the time because a) it's easier that way and b) the overhead of doing so is extremely minimal. If you decide to go ahead and turn them off when not used, you can set Session.start to false in app/config/core.php.
However, you will have to add code to start the session when a user is logged in. You may also experience issues with the Auth component. It makes use of the Session component and I believe it expects sessions to be started on every page load.
Short answer: Maybe.
Long answer: seems that, for the case you explain, Auth should be enough (provided you also use Sanitize, but that's something you should also do if using ACL anyway).
As for the use of sessions, I don't think you have to worry about Cake using them for anonymous users, but I really haven't read the code. Anyway, I don't think that it will be easy to turn them off for non logged in users but leaving them on for logged in people.
Using the Auth component is fine
Using the Sanitize library has nothing to do with this at all. Knowing Cake, if something needed sanitized in conjunction with the AuthComponent then that component will make use of Sanitize internally. You don't need to do anything with it yourself.
If you set up a User Model with id, username, password fields and simply include the Auth component in your AppController and set the component to allow the 'display' action ( for the homepage IE PagesController::display( 'home' ); ) that should get you started.
Googling or searching bakery.cakephp.org should turn you up some good Auth tutorials.