I'm looking for advice on how to tackle a design problem I've came up with. I'm currently using Symfony framework so I'll be using the names of Symfony classes.
When a user becomes "authenticated" or their "credentials" change in the Symfony user class, a regenerate() gets called on the currently used storage class. The store class extends sfStorage.
Now, when this regenerate() command is ran, we need to do some business logic. The following are options I've came up with so far:
Modify the three functions that addCredential, removeCredential, setAuthenticated and tell them to dispatch an event (setAuthenticated already does) so we know to do our business logic.
Second option would be to extend the sfSessionStorage class and tell it to throw an event on each regenerate. The problem I have with this is that sfUser asks for the interface sfStorage. Unless we modify sfStorage then if someone passed any kind of class that extends sfStorage that didn't know to add the event, it wouldn't work.
The third option would be the second option, but we would still extend the user object to say that we require the interface of a custom sfStorage abstract class that sends out a notification on regenerate. Then we would know for sure that any class that passes through would follow this notification method.
Anyone have any suggestions?
I would go with the second option and extend the sfSessionStorage class, and then use the class by inserting it into the factories.yml.
This shouldn't cause any issues with the sfUser though as your custom storage class will extend from sfStorage by proxy.
Related
I am using a service which offers a complete set of RESTful endpoints to manage all my data (GET, UPDATE, etc.. are all supported).
The service also created a ready-to-use PHP class to easily interact with the API.
I autoload this Class using composer (and it's stored in vendor/my-class) so I can use it globally in my application.
Now the question is: Should I create a Model to wrap the Class methods? Or can I just put all the logic in the Controller and use the Class method directly in there?
What's the best practices here?
I would create a model class that extends from yii\base\Model and create save, create and update methods, maybe even try to follow parts of the ActiveRecord pattern or another pattern that fits your needs.
Using yii\base\Model is essential IMHO if just to add the needed rules for validation, default values, etc.
I'm trying to do my own custom user provider,In Symfony tutorial From
"http://symfony.com/doc/current/security/custom_provider.html#create-a-user-class" This Site Tutorial But Couldn't Understand how to implement This site code in my localhost.Pleace help me some step by step process or a video process.
You have to create a class that implements this interface
Symfony\Component\Security\Core\User\UserProviderInterface
For that, you must create a public function called loadUserByUserName that receives as a parameter a string (the user name) then you have to implement the logic to get the user entity (you may need to call Doctrine and find it on the database or make some calls to an API...) whatever service you need must be injected.
You also have to implement the method refreshUSer() that I'm not sure when is used.
and finally, the suportsClass method that checks if a given classname is supported (usually you have to check it against your user class classname)
Once done, you have to setup this class as a service in tour services.yml file. Remember to inject here the dependencies (with setters or using the constructor, this is up to you)
I am just about three days old in laravel, yesterday I tried creating an authentications system using eloquent, so without looking I deleted the default User model, and then I tried creating my own from what I had read from the documentation. After setting up every thing as I had studied and understood, I tried running my app, but whenever I enter the correct username and password I get this error
Argument 1 passed to Illuminate\Auth\EloquentUserProvider::validateCredentials()
must be an instance of Illuminate\Auth\UserInterface, instance of User given, called in dir
I did not know what the EloquentUserProvider was or where it was even coming from. My original model looked like this
class User extends Eloquent {}
I battled with this error for the whole day (no exaggeration), But today I found out from this SO Can't authenticate user in laravel that it was because I had not implemented some interface, so they linked me to https://github.com/laravel/laravel/blob/master/app/models/User.php where I copied the default model I initially deleted.
I used the documentation almost through out my learning process, and no where in the documention for authentication and for eloquent did they mention that we are suppose to implement these interface for us to be able to use Auth::attempt() method, my question now is how then do we (newbies) know what to implement and what not to implement, or what any of these interfaces even do.
This is simple. It's a laravel's requirement. The User model is generated by default for you. If you do not need to implement the interface's methods, just add them empty in your User class.
And of course, in your case, what to extend or implement will be shown as errors on startup. Reading them carefully can give you all the asnwers.
Also, if you want to use different User Authentication features, or extend the existing ones, you can look some info here in the docs
You know, in Symfony you get auto generated base class for database tables. I got an "user" table which stores users, passwords, and got already a pre-made template class for it. Its got login() logout() etc. routines (it just writes the session).
So, in different applications I would just write something like that:
class myUserClass extends UserClassTemplate
so I dont need to write login, logout again and again. But this time, I inherit a Symfony's base class - how can I inherit my template?
If you use Doctrine, you could write a custom behavior (or template) to achieve this thanks to the delegation of method calls (and not with multiple-inheritance, which is not available in php). See this example with... guess what? UserTemplate!
Suppose you are building a web application that is going to be a packaged product one day, one that users will want to be able to extend and customize.
It comes with a core library consisting of PHP files containing classes:
/library/
/library/frontend.class.php
/library/filesystem.class.php
/library/backend.class.php
Now, suppose you want to keep a clean core that users can't patch. Still, you want the user to be able to customize every nut and bolt if need be.
My current idea is to create an autoloading mechanism that, when a class is instantiated, first loads the core include:
/library/frontend.class.php
then, it switches to the user directory and looks whether there is an include of the same name:
/user/library/frontend.class.php
if one exists, it includes that as well.
Obviously, the user include must contain a class definition that extends the definition in the core include.
Now my question is, how would I instantiate such a class? After all, I can always be sure there is a definition of:
class frontend_core
but I can not be sure there is a
class frontend_user extends frontend_core
However, I would like to be able to rely on, and instantiate, one class name, regardless of whether there was a custom extension to the class or not.
Is there a clever way, idea, or pattern how to achieve this?
Of course, I could write a simple factory helper function that looks for the user class first and then for the core class and returns an initialized object, but I would really like to keep this as clean and simple as possible, because as I said, it is going to be a packaged product.
I am looking for a smart trick or pattern that uses as little code, and introduces as little new functionality, as possible.
Why don't you follow the approach as used by Propel? You generate your base classes and already provide an empty User class (extending the base class) where your users can put their overrides/specific implementation details, and in your code you always refer to the User classes. So basically you just use the inverse of the logic you described.
If the explanation above isn't clear, check out http://propel.phpdb.org/trac/wiki/Users/Documentation/1.4/QuickStart#a6.UsingtheGeneratedSQLandOMFiles and generate code for a small database. The base classes are in the om folder, the (by default empty) user classes are in the root folder.
I would implement hooks in the core, so users dont have to hack the core, but are still able to extend the core using hooks
I'd go with using the constructor of the core class to determine the user class to load, and then implement a factory method in the core class to generate instances of the user class. By making the constructor of the user class protected, and having the user class extend the core class you can be sure that code elsewhere cannot instantiate the user class.
C.
I think it's more complicated with a single filename when you want to use inheritance as well. Basically class user_frontend extends core_frontend has to know where to find both classes. Both must be included.
If you just want to do new Frontend you could use PHP5.3's class_alias to point Frontend to the main class to use. Below 5.3. you could use a ServiceFinder, that knows how to map Service Names to Classes and then get the Frontend with $service->get('frontend') or use a Dependency Injection framework.
Edit I removed the Loader code given before, because it was suffering from exactly this problem.
You could have a loader class that will decide which class to instance:
Loader::instance()->load('Frontend')