FOSUserBundle FTW!

We are glad to hear you are liking our tutorials :)

Cheers!

Hey julien_bonnier!

I'd totally keep FOSUB. You have enough things to worry about while upgrading all the projects :). FOSU is supported in Symfony 4-4. The real question is if you'll need to upgrade FOSUB to a newer version and what changes that version might have. I wouldn't use FOSU in a new app, but it's still totally fine - and, if you want, you can worry about removing it some day in the future. We still use it on our site, because... it works and we have other things to worry about ;)

Cheers!

Alrighty, thanks for the advice!

Hey Lavin,

Sure, you can use this bundle with Symfony 2.8. From the latest release, I see it still supports Symfony 2.8, see: https://github.com/FriendsO...

Cheers!

thank for the reply ive done sucessfully implemented that but can i ask another question? can fosuserbundle make separate login like 3 login for admin,customer and seller?

Hey Lavin,

Out of the box, FOSUserBundle does not have a simple solution for that. FOSUserBundle works with your User object in general. But I think you can implement it yourself by overriding some parts of this bundle. It depends on your needs.

Cheers!

Hi Abelardo L.!

Great question! Actually, we likely will NOT move this to Symfony 4. FOSUserBundle has always give you a lot for free - a login form, registration and reset password. However, it came at a high cost - it was difficult to customize your registration form, or processing or anything else - you needed to hook into events and config to do pretty basic things.

For this reason, my hope is that we can begin to move on from FOSUserBundle. We're not *quite* ready for this yet, but we're close. Here are the important things that FOSUserBundle gives you:

1) A login route, controller, template -> You can now generate this via the make:auth command
2) Login processing -> actually, FOSUserBundle uses the Symfony security system for this. And this can also be generated via the make:auth command
3) Registration route, controller & template -> I think we need a make:registration-form command, but it doesn't exist yet. I'd recommend building this by hand - registration (fortunately) is not too difficult
4) Reset password -> This is an important one, and I hope we can have an open source bundle soon that *just* provides this functionality.

I hope that makes sense! Using FOSUserBundle is not bad - it's a very high quality bundle. However, soon, I think it will be faster and more flexible to avoid it.

Cheers!

Hi Ryan weaverryan - For a new symfony 5 project (migrating non-framework'd project into symfony) would you recommend make:registration-form and make:auth rather than FOSUserBundle? I've read Fabien's book (both, actually) and am re-working my way through your Symfony 4 Basics screencasts using symfony 5. I only have a few months' experience with Symfony 2, and some recent experience with Symfony 3. The screencasts are invaluable training.

Hey Ed,

Yes, I'm sure Ryan will suggest you to use Maker commands :) FOSUserBundle is great, but when things go complex - it's hard to extend it. And on practice, you always want to extend FOSUserBundle because you need your custom templates, etc. So, better use maker commands instead ;)

Cheers!

Exactly what I needed to know. Thanks Victor!

Hey Ed,

You're welcome!

P.S. And now MakerBundle is able to generate "forgotten password" feature! All you need to have for this like Controllers, templates, etc. are auto-generated and ready to use and customize for devs! See related merged PR: https://github.com/symfony/...

Cheers!

Thanks for your explanation.

Brs.

Nothing like free stuff :D

I see you could fix your problem, is that right?

Cheers!

Yes, cheers!

Hey Shaun,

Yes, you can upload your screenshot to a cloud like Imgur and then paste a link to it in your comment ;)

Cheers!

Hey @disqus_wefmccz0Ip!

Ah, interesting! So..... I can give you a short answer :). If you're building a web app (even one with a SPA), you should just use session cookies - simpler than JWT. If you *do* need API authentication, then create a JWT authenticator with Guard (https://knpuniversity.com/s.... There's really nothing special with FOSUserBundle for this: you won't really use any of its features for the authenticator. You'll just query the database for the user like normal :).

Cheers!

I've got that added to our list! I think it's quite time that we talked about OAuth and Symfony :). But, it won't be too soon (sorry! Lots to do).

Hey Egor,

Not yet, see Ryan's opened PR about Symfony 4 support: https://github.com/FriendsO... . So you'll be able to use it only after it's merged.

Cheers!

Thanks, Victor!

Hey @napester_shine!

The best way to handle this.... depends on your app! The big question for me isn't whether or not users have a different or the same login form, but whether or not those different users will access the same areas of the site? For example, suppose you have "admin" users and "normal" users. And suppose that "admin" users can ONLY visit URLs starting with /admin/ (i.e. they CANNOT access the rest of the site, like /products). And the "normal" users can ONLY visit the URLs that don't start with /admin/. AND, admin users and normal users have a lot of different information in the database. If - and only if - you have all of these, then you might consider creating 2 user entities and 2 firewalls. In this situation, I would not use FOSUserBundle.

But for the vast majority of setups, I would only have *one* User entity and *one* firewall. Having multiple registration forms is fine - you can create as many as you want. Having multiple login forms is also fine - I would create a Guard authenticator to process each. You could assign different roles (or set some boolean property on each user) for the different user types. Then add security checks so that different users can only access different parts of the site.

tl;dr; Even if you only have one User entity and one firewall... there's nothing stopping you from creating as many login and registration forms as you want. But, you might not want to use FOSUserBundle - it will just start to get in the way. The only real negative with one User entity is that you may have extra fields on it that are used by one user type, but not a different user type. Unless you have a lot of fields... it wouldn't really concern me.

Cheers!