Include Tenant ID in URL of sendMessage

#1

What seems to be the problem:
This application I want to build in Livewire has a multitenant setup. It relies on the URL (first segment of the URL is always the tenant ID) and some middleware to do the scoping. The problem is the callback for LiveWire actions looks like this /livewire/message/{payload} eg /livewire/message/timer in this testcase. Since the first segment is in this case not the tenant ID, the application does not know what tenant the action is for. Is there a way to force this, so that the callback url looks like /123/livewire/message/timer instead?

Are you using the latest version of Livewire:
yes

1 Like
#2

I’ve been doing some more research for this issue. Good thing => I was able to solve this particular situation.

  • if your application is multitenant
  • and uses a segment of the url (eg. tenant slug or tenant id to determine the actual tenant like https://great.app/123/dashboard)

then you need to change 2 things

  1. You need to manually register the route to the callback of LiveWire actions, to make sure the route to the tenant specific function actually exists (eg. /123/livewire/message/do-something)
Route::group([
    'prefix' => '{tenant}', 
                'middleware' => 'multitenant', 
                'namespace' => 'Admin'], 
function() {

 // OTHER ROUTES

Route::post('livewire/message/{name}', '\Livewire\Connection\HttpConnectionHandler');

});
  1. Change the callback url or the LiveWire actions to whatever needs to be added, in my case it is the instance_id stored in the session variable.
<script>
     window.livewire_app_url = "/{{ Session::get('instance_id')}}"; 
</script>

If you use the config file of LiveWire it is possible to set the

'asset_url'  => null,

to something else, like setting it to the URL the holds the tenant specific information. BUT … this did not work for me as the actual assets (the javascripts) are not tenant-specific of course and need to be served from the main url.

Unfortunately there is no

'app_url' => '',

available to my knowledge. If that was the case I would have been possible to set this config variable to something else in our multitenant middleware and I would prefer it that way I believe.

If anyone has any remarks on this solution or has something better in mind, let me know!

1 Like