I'm building a website with symfony and for the user management I choose FOSUserBundle. Now.. I've build my form where I need an username, email and password (nothing more for now), which are the fields in my User table. But with FOSUserBundle it expects a lot more fields in my table like username_canonical, token, login_confirmation....
Is there a way to still use FOSUserBundle, but only with the 3 fields that I want to use? I was searching to maybe override it, but I couldn't find a solution.
In order to use FOS\UserBundle your user class needs to implement FOS\UserBundle\Model\UserInterface. It will provide the mandatory information. If you really want to have a simpler user interface (although FOS\UserBundle\Model\UserInterface is pretty simple) you will need to create your own logic (e.g. fork FOS\UserBundle).
I'm looking at implementing two-factor authentication for one of my projects. I've seen: https://github.com/bitbeans/Yubikey
https://github.com/antonioribeiro/google2fa
https://github.com/lahaxearnaud/laravel-u2f
And I want to leave the choice up to my users, on which and how many methods of authentication will be required. As such I know I'm looking at coding something special to achieve this but I'm not sure where to start.
My goal is to enable users to not use any additional authentication methods or allow them to use all additional authentication methods available. Ideally the login form would only require username/password; upon entering correct credentials the user would be directed to a new page for every authentication method the user has chosen to use.
laravel-u2f uses middleware; which I'm not against doing, but seems like too much extra logic to process for every request instead of just when logging the user in.
I've thought about replacing the default Auth driver but I'm not sure that's the best thing to do.
My final thought; and what I'm leaning towards is listening for the "auth.attempt" event and using that to check what additional authentication needs to be done. But I'm not sure how the best way to process getting additional authentication information from that.
So the reason I'm posting is looking for input on the best way to achieve what I'm looking for.
You could place a value e.g. full_authenticated
Session::put('full_authenticated', 'false');
and use it in the existing authentication middleware.
This way you cut the logic in the middleware section to one comparison.
If you want to add later more methods for authentication you should implement an interface/contract for a general authentication method.
Then you write a authentication manager class which sets full_authenticated in the session and handles the different methods for the different users.
The Title may not be as clear but Il explain what's my problem.
Im building PHP MVC framework for my project. I know there are awsome PHP frameworks, but I like to code and Im doing this to learn more about PHP and MVC and other OOP patterns.
It works great, at least components I built so far.
I use PHP 5.3 and namespaces, so I can require/load classes based on their namespaces/names.
I built SPR-0 class loader class and it enables me to use other libraries that use SPR-0 "standard"/convention like Doctrine or Symfony2 components inside my framework. And all functionality of the framework itself, i call it Core, is writen as a component. So i have \Core\Controller\Controller() class or \Core\Router\Dispatcher() class or \Filesystem\FileManager() class. So I use them where I need them. And Core components enables me to add routes, detect them, call aproppriate controller/action etc... to build an MVC basicly.
And now I need Authentication modul to check if user is loged in on protected pages.
How do I setup that? The bigest problem is how do I tell Authentication Module what tables to use? Where to find usernames and where to find passwords? How do I configure Authentication module, so it knows where to look for username and password?
I could setup users table in database and never change it, and then instruct Authentication where to find stuff he needs. But what if on next project I would like to use different database design, and i would like to use email row instead of username?
Hope you understand whats bothering me...
The short question is how to setup Authentication class/module so you can configure it later to use other rows to fetch data from, and how flexible can that class can be, as far as configuration goes? Should I map some where in configuration that variable username maps to table users row username, so i can change it latter to email? How do you build flexible and configurable Auth library?
The question is long, so thanks for reading...
If I understand you correctly, you want to be able to choose different DB tables for Auth depending upon what project you're working in...
Well why don't you create a config file that gets 'read' by the framework first thing?
That's what other frameworks do I think. You provide host,dbname,user and so on... In your case you'd, in addition to that, write in the config what tables and fields to use for authentication/auhorization?
I'm hoping to use Ion Auth for a Codeigniter application, but I'm unsure of exactly how to structure the tables appropriately. Basically, I have a few different types of users each with different attributes. How would one build this out with just a single meta table?
Some ideas were offered here ( Create user roles and profiles in Codeigniter using Ion Auth ) but none seem particularly elegant or ideal. Is there a a better way? Can I easily work with multiple meta tables (e.g. meta_type1, meta_type2, etc.) somehow?
A related issue pertains to the "identity" config parameter for login etc. How could I have the identity be email for one user type, and username for another?
Thanks in advance for any tips/advice/ideas
Ion Auth code is really clean and organized.
You can easily hack the login process to accept both username or email. Even better, you can fork the repo on GitHub and make the $config['identity'] variable accept both string or array, and act according to that. And send a pull request! :-)
Regarding meta data for users: I would definitely use a single table to handle users metadata. You can put several columns and set to null in case some user type doesn't need them.
Hope my ideas help! Good luck and happy coding.
I also meet the same problem as you. And i found codeigniter authentication library alternative that could solve the problem. Flexi Auth seems can handle "multiple extra meta table" for different user groups.
This question is mainly geared towards Zend in PHP, although it certainly applies to other languages and frameworks, so I welcome everyone's opinion.
I've only recently been using the Zend framework, and while it's not perfect, I have had a pretty good time with it. One thing that drives me crazy, however, is that most of the examples I see of people using Zend do the validation in special form objects, rather than in the model. I think this is bad practice because data can enter into the system in other ways beyond form input, which means that either validators have to be bent and twisted to validate other input, or validation must be done in a second place, and logic duplicated.
I've found some other posts and blogs out there with people who feel the same way I do, but the developers of Zend made this choice for a reason, and other people seem to use it without issue, so I wanted to get some feedback from the community here.
As I said, this mainly applies to Zend, although I think it's important to look at the issue as a whole, rather than working within the confines of the Zend framework, since Zend was designed so that you could use as much, or as little, as you wished.
This is a non-zend specfic answer, however I believe that the model should be responsible for the validity of its own data. If this is the case then the validation belongs in the model, however this may not always be achievable and it may be necessary to perform validation in the view, however I think this should be in addition to the validation performed in the model not a replacement for it.
The problem with only having validation in the view is that at some point you will probably want another view on your data. Your site may become popular and customers are asking for XML based APIs to generate their own views. Do you then rely on the customer to validate the data?
Even if you do not have to provide APIs some customers may want customized views that are sufficiently different to warrant a completely different version of the page, again you now have validation in the views duplicated.
I think the ideal scenario is to have your model do the validation but to make the results of the validation available for the view to read and render the page again with the validation results displayed.
I think it is perfectly reasonable to have the view doing validation if you want to instantly display validation data back to the user etc but the final decision on data validity should rest with the model.
It's important to remember that data validation which is relevant to an application isn't always the same thing as data validation that's relevant to a database schema.
Consider a simple registration form where a user creates an account with a username and password. You perform validation on the password because you want it to be X number of characters in length and contain a good mix of character types (or whatever).
But none of this is relevant to validate the data for database insertion, because you aren't going to store plain-text passwords - you're going to store a hash of them in some way (md5, md5 + salt, whatever). Instead you might make sure that you have a 32 character hexadecimal string so that it is very likely to be a properly created MD5 hash.
This password example isn't the only scenario, just a good one for explanation here in this topic.
So what's the answer? I don't think there's any one-solution-fits-all. Sometimes you will want (need?) to validate the data twice. Sometimes you'll do it once an only in the Model. Just match it as best as possible to your application's needs.
Perhaps you should have a look at Using Zend_Form in Your Models by Matthew Weier O'Phinney - one of the lead-developers of the Zend Framework - for his view on exactly this question.
Well, the validation can be done at many different levels and usually none of them is "the best". Of course, the model can be populated with invalid data that do not come from the form, but we can also create forms whose data do not go to any model.
Moreover, the direct validation in models is unsually not integrated with our form rendering system, which causes problems if we want to show the error messages and re-populate the form with the user-entered data then.
Both of the solutions have their own pros and cons. It would be perfect to have a system that ensures us that the validation finally must be done at some level. If the form does not validate some data, then the model does and vice versa. Unfortunately, I haven't heard of such library, but I must note that the validators in the frameworks unsually are source-independent. You can pass the POST data to them, but the same can be done with the information retreived from a properly parsed CSV, MYSQL databases, etc.
I am not aware of Zend. But.
Your model have to receive valid data. Model and it's methods shouldn't check data again and again. Of course there are should be functions that do actual validation and they should be called from the gui validation or from the other data input place.
The best you can do on your model side is call "Assertions" on all the data to be sure on the development time that validation have been taken its place.
The lower level of the code (UI, model, utils) the less validation and check code should be there. As then there is a big chance that the same validation will be called more then one.
How about putting esthetical validation in the form, and business rules validation in the model.
Take a registration form for example.
The form would assure that the email field is trimmed and contains a valid email, that the password/confirm password field are identical and that the user checked the I Agree to terms checkbox.
The registration model would make sure that the email hasn't been taken yet in the table, would salt and hash the password.
It's how I split the two usually.
User input should be validated when it is being inputted because it is specific to the form of entry (ie, do some form validation - make sure text boxes that should have numbers are numbers).
Business logic should probably be validated on the model because it is model specific (ie. make sure they have't already reserved that same room or something like that).
The problem with validating it at the model level is that the model might be used in different ways. Correct input for one scenario may not be correct input for another.
The other issue is that you usually want some context sensitive validation, such as displaying a red box around the form control that has the bad input.
The model or database might do some extra validation to make sure the user code isn't doing something completely wrong (constraints, etc).
Peter Bailey's password example is excellent. A user model can only validate, if a password was set (because it's not stored as plain text but as a hash) while input validation can ensure, that the original plain text password corresponds to the security requirements (number of characters,...). Therefore you need both: Model validation and form/input validation, ideally as separate, reusable component and not directly in bloated controller actions.
Think of input validation as whitelist validation (“accept known good”) and model validation as blacklist validation (“reject known bad”). Whitelist validation is more secure while blacklist validation prevents your model layer from being overly constrained to very specific use cases.
Invalid model data should always cause an exception to be thrown (otherwise the application can continue running without noticing the mistake) while invalid input values coming from external sources are not unexpected, but rather common (unless you got users that never make mistakes).
See also: https://lastzero.net/2015/11/form-validation-vs-model-validation/