I'm trying to create a custom Token authenticator for my Symfony 6.2 and API Platform project
class TokenAuthenticator extends JWTTokenAuthenticator
{
/**
* #param PreAuthenticationJWTUserToken $preAuthToken
* #param UserProviderInterface $userProvider
* #return UserInterface
*/
public function getUser($preAuthToken, UserProviderInterface $userProvider): UserInterface
{
$user = parent::getUser($preAuthToken, $userProvider);
var_dump($preAuthToken->getPayload());exit;
}
}
But I always get this error:
Attempted to load interface "AuthenticatorInterface" from namespace "Symfony\Component\Security\Guard".
Did you forget a "use" statement for "Symfony\Component\Security\Http\Authenticator\AuthenticatorInterface"?
that means, there's no AuthenticatorInterface on Security\Guard and Http\Authenticator replaces it, so the LexikJWTAuthenticationBundle must be updated to include the new change.
This new class contains new functions so is there any documentation regarding them? Also, the purpose of establishing this class TokenAuthenticator is to make the old token invalid when changing the password, so is there a better way to do this?
Related
I want to check the entity variable and check if it is allowed to delete the entity. For example if the owner entity of the association is linked to another entity, I want to make the deletion impossible.
I've looked in the documentation of api-platform bu I could not find any help regarding my problems. Either you give the right to delete or not. I could not find how to control it (equivalent to validation for POST, PUT and PATCH).
You can use the access control feature of Api-Platform and Symfony Expression Language to achieve what you want. This way you can write pretty complex expressions.
I hope this example makes it clear.
user is the currently logged in user.
object is the resource user is trying to delete.
/**
* #ApiResource(
* itemOperations={
* "delete"={
* "access_control"="is_granted('ROLE_USER') and object.getUsers().contains(user),
* }
* }
* )
*/
class Entity
{
/**
* #var ArrayCollection
*
* #ORM\OneToMany(targetEntity="User", inversedBy="entities")
* #ORM\JoinTable(name="entity_users")
*/
private $users;
/**
* #return ArrayCollection
*/
public function getUsers(): ArrayCollection
{
return $this->users;
}
}
In this case only users who are stored in users Array of Entity can delete this resource.
In my Laravel REST API project I mainly consume 3rd party APIs. For that, I have a 'Services' folder grouped by APIs (Accommodation, Planning, Discount etc) to send correct parameters to APIs and get the raw data.
I feel that I need to use adapter pattern here, because this 3rd party outputs need to be formatted.
Let me try to give an example.
I have an EventDao interface (Data access object) and one or multiple concrete EventDao classes like EventbriteDao.
I also have an adapter for each concrete DAO. e.g: EvenbriteAdapter
I will have some business logic somewhere so I need to have an Event entity class. To pass the adapter's data to the entity, I need an EventDTO class (data transfer object)
Finally I can call the eventDao (via interface thanks to Laravel's service providers)
I pass its raw output to the adapter, then adapter's output to the entity. Then I can call one of methods of the entity class. (After that I need to convert it to a proper json data, but it is the easy part.)
I don't get where to put other CRUD logic like updateEvent, deleteEvent, getAll etc. Should I call them directly in controller or create repositories (the repository pattern)? I am confused about it.
Would it be a good approach or over-engineering? Because I have 5-6 classes/interfaces other than controller.
Another problem is calling EventbriteAdapter directly in the controller. Should I have an interface for it? In this case I will need to bind both service and adapter interfaces to its implementations in AppServiceProvider.
My another concern is having collections for entity chunks. If I call getAll() method I can loop through the data and create an array of objects, but I am not comfortable with it. Laravel's collections would be useful, but I want to separate application layer from domain. What would be a good solution for it?
Here example codes for some of the files I mentioned are:
interface EventAdapter
{
public function getId();
public function getName();
public function getStartDate();
public function getLocationName();
}
class EventbriteAdapter implements EventInterface
{
private $raw;
public function __construct(array $raw)
{
$this->raw = $raw;
}
public function getName()
{
return $this->raw['name'];
}
public function getStartDate()
{
return $this->raw['start'];
}
public function getLocation()
{
return $this->raw['venue']['name'].' '.$this->raw['venue']['address'];
}
}
// Fetch event from Eventbrite (or other third-party)
$result = fetchEventFromEventbrite();
// Wrap event in adapter
$adapter = new EventbriteAdapter($result);
I don't get where to put other CRUD logic like updateEvent,
deleteEvent, getAll etc. Should I call them directly in controller or
create repositories (the repository pattern)? I am confused about it.
You can use the Gateway pattern to encapsulate all logic of interaction with 3rd party API. The gateway can contain methods to get data and save data. For example:
interface EventGatewayInterface
{
/**
* Get an event by id
*
* #param mixed $id unique identifier of an event
* #return Event the event
*/
public function getById($id);
/**
* Get all events
*
* #return Event[] list of events
*/
public function getAll();
/**
* Add an event
*
* #param Event $event the event which will be added
*/
public function add(Event $event);
/**
* Update an event
*
* #param Event $event the event which will be updated
*/
public function update(Event $event);
/**
* Delete an event
*
* #param Event $event the event which will be removed
*/
public function delete();
}
Would it be a good approach or over-engineering? Because I have 5-6
classes/interfaces other than controller.
In fact, you use the Adapter pattern to translate one representation (raw representation) to another (object representation). But the Adapter pattern is used to translate one program interface into a compatible program interface. To convert representations used the Mapper pattern. You can implement simple mapper for example:
class RawEventMapper
{
/**
* Map raw data to an event object
*
* #param array $data raw data
* #return Event the event object
*/
public function map(array $data)
{
$event = new Event();
$event->name = $data['name'];
$event->startDate = $data['start'];
$event->location = $data['venue']['name'].' '.$data['venue']['address'];
return $event;
}
}
and use it in Gateway to convert raw data to an object.
class ConcreteEventGateway implement EventGatewayInterface
{
/** #var RawEventMapper data mapper */
protected $mapper;
/**
* Constructor
*
* #param RawEventMapper $mapper data mapper
*/
public function __construct(RawEventMapper $mapper)
{
$this->mapper = $mapper;
}
/** #inheritdoc */
public function getById($id)
{
// get raw data from 3rd party API
return $this->mapper->map($raw);
}
}
Laravel's collections would be useful, but I want to separate
application layer from domain. What would be a good solution for it?
If you aim to create a domain layer independent on the framework you shouldn't use Laravel collection.
I'm using Laravel 5.5. The nature of the website is a 'multisite' architecture where multiple websites/domains are run from the same codebase.
I've come across an issue when sending email. I need to change the from name and address as well as the transport (SMTP, etc) options depending on which website is being viewed. I have these details stored in a config file.
The easiest way is to just pull those details in the Controller before I call Mail::send/Mail::queue and to update them. However, this brings back 2 issues:
There is a heavy reliance on remembering to actually do that every time I send any email in the code. In short, it's not abiding by DRY.
I'd be forced to use Mail::send instead of Mail::queue, because the queue wouldn't have any idea of the config update from the time it was queued only from when it is processed .
How can I achieve what I am looking to do here in a clean way?
I thought about extending all of my 'Mailable' classes with a custom class that updates the SMTP details, but it doesn't look like you can update the SMTP/Transport information after the class is initiated; you can only update the from name and address.
I managed to find a way to do this.
I had my mailable class (ContactFormMailable) extend a custom class, as follows:
<?php
namespace CustomGlobal\Mail;
use CustomGlobal\Mail\CustomMailable;
use CustomGlobal\ContactForm;
class ContactFormMailable extends CustomMailable
{
public $contact_form;
/**
* Create a new message instance.
*
* #return void
*/
public function __construct(ContactForm $contact_form)
{
$this->contact_form = $contact_form;
}
/**
* Build the message.
*
* #return $this
*/
public function build()
{
$view = $this->get_custom_mail_view('contact_form', $this->contact_form);
return $this->subject('Contact Form Enquiry')
->view($view);
}
}
You'll notice I'm calling get_custom_mail_view. This is in my extended class and used to calculate the view and template I need to use for my mail, depending on the website being viewed. In here I also set the location of my config folder.
<?php
namespace CustomGlobal\Mail;
use Illuminate\Bus\Queueable;
use Illuminate\Mail\Mailable;
use Illuminate\Contracts\Mail\Mailer;
use Illuminate\Queue\SerializesModels;
use Illuminate\Contracts\Queue\ShouldQueue;
use Swift_Mailer;
use Swift_SmtpTransport;
use CustomGlobal\Website;
use CustomGlobal\Territory;
class CustomMailable extends Mailable
{
use Queueable, SerializesModels;
public $layout_view_to_serve;
public $host_folder;
/**
* Override Mailable functionality to support per-user mail settings
*
* #param \Illuminate\Contracts\Mail\Mailer $mailer
* #return void
*/
public function send(Mailer $mailer)
{
app()->call([$this, 'build']);
$config = config($this->host_folder .'.mail');
// Set SMTP details for this host
$host = $config['host'];
$port = $config['port'];
$encryption = $config['encryption'];
$transport = new Swift_SmtpTransport( $host, $port, $encryption );
$transport->setUsername($config['username']);
$transport->setPassword($config['password']);
$mailer->setSwiftMailer(new Swift_Mailer($transport));
$mailer->send($this->buildView(), $this->buildViewData(), function ($message) use($config) {
$message->from([$config['from']['address'] => $config['from']['name']]);
$this->buildFrom($message)
->buildRecipients($message)
->buildSubject($message)
->buildAttachments($message)
->runCallbacks($message);
});
}
/**
* Calculate the template we need to serve.
* $entity can be any object but it must contain a
* $website_id and $territory_id, as that is used
* to calculate the path.
*/
public function get_custom_mail_view($view_filename, $entity)
{
if(empty($view_filename)) {
throw new Exception('The get_custom_mail_view method requires a view to be passed as parameter 1.');
}
if(empty($entity->website_id) || empty($entity->territory_id)) {
throw new Exception('The get_custom_mail_view method must be passed an object containing a website_id and territory_id value.');
}
// Get the website and territory
$website = Website::findOrFail($entity->website_id);
$territory = Territory::findOrFail($entity->territory_id);
$view_to_serve = false;
$layout_view_to_serve = false;
// Be sure to replace . with _, as Laravel doesn't play nice with dots in folder names
$host_folder = str_replace('.', '_', $website->website_domain);
$this->host_folder = $host_folder; // Used for mail config later
/***
Truncated for readability. What's in this area isn't really important to this answer.
***/
$this->layout_view_to_serve = $layout_view_to_serve;
return $view_to_serve;
}
}
It's important to remember that mail can be queued. If you do this is another way, such as setting a config at runtime, then you'll find that the process that runs the queue has no visibility/scope of your runtime config changes, and you'll end up firing out email from your default values.
I found a few answers similar to this one, which helped me out, but none of them worked completely, and some are out-dated (Swift_SmtpTransport is changed considerably since those answers).
Hopefully this helps someone else out.
I want to implement some extra features to Illuminate\Translate\Translator.
So, i create my folder in ~/vendor directory, place there My/Traslator class, that will implement Symfony\Component\Translation\TranslatorInterface. Right?
Is it OK to extend laravel translator class (a lot of functionality will be duplicated otherwise) in my package?
If it is ok - it will be necessary to tie to current laravel version to keep code stable. But what will happen in case enduser laravel version will differ from one required in my package?
What should i do then to make laravel use my translator class in application (facades,etc)?
Make a Translator class and make it extend Illuminate\Translation\Translator
<?php
namespace App\Helpers;
use Illuminate\Translation\Translator as LaravelTranslator;
class Translator extends LaravelTranslator
{
// here you can overwrite any functions you want/need
}
Create your own TranslationServiceProvider inside app/providers (just copy the laravel translation service provider and change the line where it uses Translator with your own Translator class where you have overwritten what you needed)
<?php
namespace App\Providers;
use App\Helpers\Translator; // <= Your own class
use Illuminate\Translation\FileLoader;
use Illuminate\Support\ServiceProvider;
class TranslationServiceProvider extends ServiceProvider
{
/**
* Register the service provider.
*
* #return void
*/
public function register()
{
$this->registerLoader();
$this->app->singleton('translator', function ($app) {
$loader = $app['translation.loader'];
// When registering the translator component, we'll need to set the default
// locale as well as the fallback locale. So, we'll grab the application
// configuration so we can easily get both of these values from there.
$locale = $app['config']['app.locale'];
$trans = new Translator($loader, $locale);
$trans->setFallback($app['config']['app.fallback_locale']);
return $trans;
});
}
/**
* Register the translation line loader.
*
* #return void
*/
protected function registerLoader()
{
$this->app->singleton('translation.loader', function ($app) {
return new FileLoader($app['files'], $app['path.lang']);
});
}
/**
* Get the services provided by the provider.
*
* #return array
*/
public function provides()
{
return ['translator', 'translation.loader'];
}
}
Comment out or delete the Laravels translator service line inside config/app.php:
//Illuminate\Translation\TranslationServiceProvider::class,
Add your own Provider in that same array
App\Providers\TranslationServiceProvider::class,
This page has more information: http://laravel.com/docs/5.0/extending#container-based-extension
So what you need to do is:
Extend the built-in class from the vendor directory
Create a new service provider that add your translation class to the service container
Replace Laravel’s translation service provider in your config/app.php file with the namespace of your translation service provider
Now when you ask for the translation service provider out of the service container—either directly (app('translator')) or with the Lang façade, it will return your translation class rather than Laravel’s.
I'm trying to setup a view plugin to expose the route matches in Zend Framework 2.
The plugin is something like this:
class GetRouteMatch extends AbstractHelper
{
/**
* Route match returned by the router.
*
* #var RouteMatch.
*/
protected $routeMatch;
/**
* Set route match returned by the router.
*
* #param RouteMatch $routeMatch
* #return self
*/
public function setRouteMatch(RouteMatch $RouteMatch)
{
$this->routeMatch = $RouteMatch;
return $this;
}
public function __invoke($param)
{
return $this->routeMatch->getParam($param, false);
}
}
What is the best way to setup the RouteMatch object?
I have to do it in the module bootstrap or in the controller?
For the moment I've resolved this way inside the controller action
$renderer = $this->getLocator()->get('Zend\View\Renderer\PhpRenderer');
$routeMatch = $renderer->plugin('routeMatch');
$routeMatch->setRouteMatch($this->getEvent()->getRouteMatch());
The RouteMatch object is injected manually.. but I'm sure there's a better way
The best is to initialize such code in your module class. You can attach an event there to inject dependencies like the routematch. However, the routematch will be available to inject soon. There is work in progress to set the routematch in a service locator. This means you can configure DI it will pull the routematch from the service locator. Then you don't need to write these things yourself anymore.