In a Symfony 5.0 Application I want to add custom logic for cleanup reasons when the user loggs out.
What I have currenty is what is described in the docs:
https://symfony.com/doc/current/security.html#logging-out
As the logout() function in the SecurityController is intercepted by Symfony it won't work to add logic there.
So - where CAN I add logic which is allways executed when a user loggs out?
Couldn't find anything in the docs so far...
IMHO the best option is to implement the LogoutHandlerInterface referenced slightly indirectly on the symfony docs you mentioned (it mentions the LogoutSuccessHandlerInterface, which has a comment regarding the LogoutHandlerInterface: "If you want to only perform some logout related clean-up task, use the LogoutHandlerInterface instead.")
To me, it feels like an event handler, but it doesn't use the event system, so ... whatever.
Nevertheless, the arguments provided to your LogoutHandler will receive a TokenInterface which has TokenInterface::getUser() which returns the current user. (dependency injection on the constructor should provide you with additional services and stuff)
The alternative would be to implement an EventListener for the kernel request event - which the LogoutListener of the symfony/security package uses to manage logouts. You would have to add the same logic as the LogoutListener and probably have to make it trigger before the LogoutListener, this is however a slightly more convoluted way and I would really use the LogoutHandler.
Related
I am building a web application in .NET Core following the Clean Architecture. I have an use case class for creating an user. Each user has a role which is passed in as an id. The use case will call to the User Repository for creating the user.
Currently, I am using FluentValidation for validating the request object. It is just pure checking such as length, not empty, etc..
My problem is that I don't know where to put the validation logic for validating the existence of the provided role. The validator is currently in the Application layer. I am going with putting the validation logic in the User repository but that doesn't sound right to me.
Do you have any ideas?
Thank you in advance.
You should add it in the validator using Fluent Validation. There are options to make custom validator and to make them async with Fluent Validation.
Creating a method in the repository for checking for the role is not necessarily wrong. But it should defently be called in validation layer along with other checks like not empty etc. etc.
For performance sake make sure that you call the check once all the other validations have passed.
I have started to go through Symfony2 code, studied a little bit small classes like Pimple and after few hours of examination have come to strange idea. The best start for this is to explain how I understand few terms, so:
Dependency
Something which is needed for another thing to work, like "engine" in "car"
Container
Object or class which is able to store a lot of another objects, like "engine","gearbox" or even "car"
Dependency Injection
Process in which every dependency is injected to object, so if I need "car" I know that I have to inject "engine","gearbox" and a lot of another stuff. Important is, that "car" don't create "engine", but "engine" is put inside "car"
Service Locator
Process in which object asks for another object, for example into the car there is inserted our container, and when car need to start it require from container "engine", so container return him "engine"
When i studied Symphony code, they start with dependency injection, but after some time I realize that when Controller is created, there is injected whole container and then you can use $this->get('serviceName') to get it, so it more looks like service locator, which according to few articles is anti-pattern.
Sow how is it? Is that line between DI and SL so small that it is sometimes broken? Or did I misunderstood something? If I use DI, do I need to insert every service into controller, so I know from outside what I use? Or can controller become in some cases container?
Your understanding of DI is pretty good. And yes, Symfony Controller does implement ContainerAwareInterface, and as you said, has a service locator role. But service locator isn't an anti-pattern. Each pattern has it's proper and improper uses.
Furthermore, Symfony doesn't enforce you in any way to use it's Controller. Your Controller can be a service. Hell, it can even be a function!
Here is one of the reasons why Controllers are implemented as service locators: Performance.
Let's drop car analogy and focus on real case that you'll encounter in 99% of projects: you need CRUD for a resource. Let's say you're building a Todo app and you need a RESTfulish controller to handle CRUD operations for Task Resource.
The least you need to have is a way to read all tasks and a way to add a new task, for that you need two actions: index (commonly named list too), and store (commonly named create too).
Common flow in Symfony would be this, in pseudo code:
indexAction -> getDoctrine -> getTaskRepository -> getAllTasks
storeAction -> getFormFactory -> createForm -> bindRequestDataToForm -> getDoctrine -> saveData
If Controller was a service locator
Index Action
When index action is executed, only service that will be resolved from the container will be ManagerRegistry (in this case Doctrine service). We will then ask it to give us task repository, and we'll do our operation with it.
Store Action
When store action is executed, we will do a bit more work: ask container to give us FormFactory, do some operations with it, and then ask it to give us Doctrine and do some operations with it too.
So summary: when index action is executed, only one service has to be constructed by service container, when update is executed, two will have to be constructed.
If Controller was a regular service
Let's see what our Controller needs. From the section above, we see that it needs FormFactory and Doctrine.
Now, when you just want to call index action to read all tasks from data storage, your controller will have to get instantiated by container. Before it can be instantiated, container needs to instantiate it's dependencies: FormFactory and Doctrine. Then instantiate controller while injecting those two into it.
So, you are calling index action which doesn't need FormFactory at all, but you still have overhead of creating it because it is needed for an action that will not be called at all in that request.
Lazy Services
To reduce this overhead, there is a thing called lazy service. It works by actually injecting a Proxy of your service into the controller. So, as far as controller is concerned, it got FormFactory. What it doesn't know is that isn't real FormFactory but instead a fake object which will delegate calls to real FormFactory code when you call some method on it.
Wrapping it up
Controller doesn't have to be a service locator, but can be. Making it a service locator can be a bit more performant and easier to bootstrap, but hides dependencies. Furthermore, it's a bit harder to test, since you'll need to mock dependency container. Whether you want to make your controllers services, functions or service locators is your choice and Symfony won't enforce you to use any of those ways.
In my experience, extending default Symfony Controller and having controllers be service locators is just fine as long as you don't write your business logic in them, but instead delegate all that work to services, which you get from container. That way, it's really unlikely that you'll have bugs in controller code (as methods will usually consist of 2-3 lines of code) and can get away without testing it.
I am using Atmosphere Framework 2.0.8.
I have implemented an AtmosphereHandler in my application and have two way communication occurring correctly over WebSockets and Long Polling.
I am trying to add some handling code for when the client disconnects to clean up some resources specific to that client (ie. I have an entry in a table I want to remove).
I have read the following wiki entries:
OnDisconnect Tricks: https://github.com/Atmosphere/atmosphere/wiki/onDisconnect-tricks
Configuring Atmosphere Listener: https://github.com/Atmosphere/atmosphere/wiki/Configuring-Atmosphere-Listener
The thing I am not clear on is where I should add the call to
atmosphereResource.addEventListener( new AtmosphereResourceEventListenerAdapter() {} );
I eventually found some example code in the JavaDoc for the AtmosphereHandler that registers the EventListener in the onRequest() method. http://atmosphere.github.io/atmosphere/apidocs/org/atmosphere/cpr/AtmosphereHandler.html
What I would like to know is if this is the correct way to go about it?
It is my understanding that the AtmosphereResource represents the connection between a client and the server for the life of that connection. The uuid stays consistent for the object on multiple calls through the onRequest() method from the same client. As such, the same AtmosphereResource object will get the EventListener added every time the onRequest method is called.
This seems wrong. Wouldn't this lead to thousands of EventListeners being registered for each AtmosphereResource?
It seems that the EventLister should only be registered once for each AtmosphereResource.
I feel like I am missing something fundamental here. Could someone please explain?
Here's an example using MeteorServlet, so it won't look exactly like what you'll have to do, but it should get you started. I add the listener to a Meteor instance, and you'll add yours to an AtmosphereResource. Each resource gets just one listener.
The overridden onDisconnect() method calls this Grails service method that handles the event. Of course, you'll want to call something that cleans up your database resource.
Note that the servlet is configured using these options. I think you might need the org.atmosphere.interceptor.HeartbeatInterceptor, but it's been so long since I initially set it up, I can't remember if it's necessary.
In one of the projects I'm working a custom 404 page needs to be implemented for each bundle.
Inside the documentation there is nothing mentioned for such functionality.
I was discussing the issue with some colleagues and was told that it has to use the kernel.exception event, alas this one lacks the information which bundle is calling it.
IMHO this should be fixed by applying a patch to symfony router component which would allow the developer to specify catch-all route which could handle the case further.
Another option would be to change the behavior of the RouterInterface::match method to return consistent output containing the matched path and the bundle which matched it. Currently this is not possible, because it throws an exception if match fails and does not give you any information at all, while it could.
For example, I have an ApiBundle which is defined to handle urls starting with "/api". Currently the only way to handle this one and set custom 404 page is to get the request at the time of the kernel.exception and preg_match() the url. This, however, is hardcoding that should be avoided as the bundle should not have such knowledge - it is defined under the app/config/routing file.
What's your opinion?
I would appreciate any other workarounds as well.
I've ended up implementing my custom ExceptionController which dispatches an event I called 'ourCompany.exception_response'.
The default bundle has a listener set with priority -1024.
If custom bundle processes the exception and sets its response, the event has to be marked and the propagation to be stopped.
The custom bundle can use the service container to get whatever it wants in order to determine whether to process the exception or no.
Ok, so the problem is:
I've got some 'order' entity, and it has 'status' property. On changing status, i wanted some other objects to be informed of this event, so i've decided to use Observer pattern. One of the observers notifies clients via email. Now i want to render Email text's from some of the twig templates. As i get from the Book, rendering templates in controllers are done with 'templating' service.
So the question as it follows: How can i access 'templating' service in my Observer class?
Specification:
I was advised, to implement my Observer as a service, but i'm not sure 'bout that. I've tried to solve this problem, and here is my options:
Use Registry. Solution that is straight and hard as rail. I guess it misses the whole point of DI and Service Container. Huge plus of this solution, is that i can access all common services from any point of my application.
To pass needed services from the context via constructor, or via setters. This is more like in Sf2 spirit. There comes another list of problems, which are not related to this question field.
Use observers as a service. I'm not really sure 'bout this option 'cos, in the book it is written, that service is a common functionality, and i don't think that observing entity with number of discrete properties is a common task.
I'm looking for a Sf2 spirit solution, which will be spread over whole project, so all answers with an explanation are appreciated.
As with any other service in a Symfony2 project, you can access it from within other classes through the dependency injector container. Basically what you would do is register your observer class as a service, and then inject the templating service into your observer service. See the docs for injecting services.
If you're not familiar with how Symfony handles dependency injection, I'd suggest reading that entire chapter of the documentation - it's very helpful. Also, if you want to find all the services that are registered for application, you can use the console command container:debug. You can also append a service name after that to see detailed info about the service.
Edit
I read your changes to the question, but still recommend going down the DI route. That is the Symfony2 spirit :) You're worried that your observer isn't common enough to be used as a service, but there's no hard rule saying "You must use this piece of code in X locations in order for it to be 'common'".
Using the DIC comes with another huge benefit - it handles other dependencies for you. Let's say the templating service has 3 services injected into itself. When using the DIC, you don't need to worry about the templating service's dependencies - they are handled for you. All you care about is telling it "inject the templating service into this other service" and Symfony takes care of all the heavy lifting.
If you're really opposed to defining your observer as a service, you can use constructor or setter injection as long as you're within a container-aware context.