Pusher: Error: Invalid key in subscription auth data: - laravel

I want to create a collaborative text editor app and came across this tutorial. I accessed the repository on github and followed all the steps from the README file to install and use the app. Also, in the tutorial, after I created the app on Pusher, I checked the "Enable client events" option on the App Settings tab.
However, when I type anything in the note textfield, the two following errors appear on the browser's console:
1)
Pusher : Error : {"type":"WebSocketError","error":"type":"PusherError","data":
{"code":null,"message":"Invalid key in subscription auth data:
'xxxxxxxxxxxx'"}}}
2)
Pusher : Error : {"type":"WebSocketError","error":
{"type":"PusherError","data":{"code":null,"message":"Cannot broadcast
client event (connection not subscribed to channel presence-note.note-
test-for-pusherqjvQbgt4s9)"}}}
The second error happens when I type something and the first one right when I load the page. I presume the second one is happening because of the first one.
This is my broadcasting.php file:
'connections' => [
'pusher' => [
'driver' => 'pusher',
'key' => env('PUSHER_APP_KEY'),
'secret' => env('PUSHER_APP_SECRET'),
'app_id' => env('PUSHER_APP_ID'),
'options' => [
//
'cluster' => 'us2',
'encrypted' => true
],
],
'redis' => [
'driver' => 'redis',
'connection' => 'default',
],
'log' => [
'driver' => 'log',
],
'null' => [
'driver' => 'null',
],
],
The values set in the env file I get from the app keys on my Pusher account. I've already double checked if the values are set correctly and it seems to be fine.
I appreciate any help. Thanks in advance

The first client side error suggests your auth endpoint isn't sending a valid response to the client, and Pusher can't validate it. Have you specified exactly the same credentials in your server as in your client? Especially the specification of the cluster.
The second client side error you're getting suggests that your client hasn't actually subscribed to the channel, which would mean that client events wouldn't work.
Double check your client side code to make sure it is actually subscribing to the channel in question. Also, double check the app settings in your Pusher dashboard to ensure client events are enabled.
Perhaps it would be helpful to enable logging on your client side Pusher object. See https://github.com/pusher/pusher-js#global-configuration

We've had the same issue and solved it for Laravel + Vue.
The problem was that the front-end developer is using another Pusher account for local development and he is sending compiled front-end files to git repo.
So, when I get the compiled js files, Echo is created with different credentials than mine because in my .env file there are my Pusher channel credentials.
Solution: npm run dev on my machine. (So that it compiles the js files and Echo will be created with my .env Pusher credentials)
P.S. This solution affirms answer of #kn100

Following steps work for me
Check your app keys at server and client side
run php artisan config:cache
run ``php artisan optimize:clear`
run composer dump-autoload
Restart your IDE
Test your app

Related

How to setup SQS to work using AWS Instance Profile instead of `key` and `secret`?

I am trying to setup SQS to use AWS Instance Profile instead of key and secret using Laravel 8.
I have tried the following in queue.php
'sqs' => [
'driver' => 'sqs',
'credentials' => CredentialProvider::memoize(CredentialProvider::instanceProfile()),
'prefix' => env('SQS_PREFIX', 'https://sqs.us-east-1.amazonaws.com/your-account-id'),
'queue' => env('SQS_QUEUE', 'your-queue-name'),
'region' => env('SQS_REGION', 'us-east-1'),
],
however, this gave me an error
Your configuration files are not serializable.
I know that removing the credentials key completely will by default force the sdk to use the default credentials provider, however, I am wondering if there is a way to use CredentialProvider::instanceProfile() instead since default credentials provider will look for keys in other places first then move on to Instance Profile role after the previous attempts failed (which I think is inefficient).
Can anyone help me with this?

Laravel Spark - Notifications stuck & Stripe nagging for publishing key that exists

Just curious if anyone else is facing this issue with Laravel Spark where the notifications are intermittently stuck in loading and if there's a simple fix for it?
Ie:
Also, I'm receiving this Stripe error in my error console whenever I attempt to subscribe on my production environment, I am using the correct test credentials in the environment file:
Uncaught Error: You did not set a valid publishable key. Call Stripe.setPublishableKey() with your publishable key. For more info, see https://stripe.com/docs/stripe.js
at Function.b.validateKey ((index):3)
at Function.b.create ((index):2)
at Function.c.createToken ((index):2)
at o.subscribe (app.js:27)
at click (eval at pa (app.js:67), <anonymous>:3:52019)
at e (app.js:67)
at HTMLButtonElement.t._withTask.t._withTask (app.js:67)
In my .env file I have (I have put x's in for the purpose of this question, the env file has the real keys):
STRIPE_MODEL=App\User
STRIPE_KEY=pk_test_Nq6IKWIFjSaBFngxxxxxxxxx
STRIPE_SECRET=sk_test_T9lwCHZACcty5JUxxxxxxxxx
app/services.php and app/services-stripe.php both have these settings:
'stripe' => [
'model' => App\User::class,
'key' => env('STRIPE_KEY'),
'secret' => env('STRIPE_SECRET'),
],
Any assistance is appreciated, thanks guys.
I had the same situation with the notifications. Apparently there's some kind of conflict with font awesome's spinner. I removed the icon completely and it's working now. Same with invitations, when I send an invitation, the text on the button changes but the spinner never hides.

Laravel mailgun driver ignores verified domain and uses sandbox instead

I'm trying to use mailgun to send notifications to users. I have verified domain, but even though my config\services.php file looks like this:
'mailgun' => [
'domain' => 'mg.mydomain.biz',
'secret' => 'key-3223423423n423j42jklkj23l',
],
all the emails go through sandbox domain.
php artisan config:clear does not help. It is the same with development and production environment. Also I need to point out that emails come from #maydomain.biz when config\mail.php clearly states 'from' => ['address' => 'no-reply#mg.mydomain.biz', 'name' => 'Sender'],. I channged it hours ago and cleared config cache un restarted web server since.
sudo service supervisor restart solved the problem.

Upgrading to Laravel 5.2 invalidates all sessions

Upgrading from Laravel 5.1.17 to 5.2. My config/auth.php originally contained:
'driver' => 'eloquent',
'model' => 'Project\User',
'table' => 'users',
New file is the same as the default, except with the updated namespace.
'defaults' => [
'guard' => 'web',
'passwords' => 'users',
],
'guards' => [
'web' => [
'driver' => 'session',
'provider' => 'users',
],
'api' => [
'driver' => 'token',
'provider' => 'users',
],
],
'providers' => [
'users' => [
'driver' => 'eloquent',
'model' => Project\User::class,
],
],
My env SESSION_DRIVER is redis. I did not clear anything from Redis. (Note, this also happened in my other projects where driver was file, but I didn't care about it as much for them.)
I have two branches, L5.2 and master (which is on 5.1.17). After switching branches, I simply run composer install
If I login on master, then switch to L5.2, I am logged out
If I switch back to master, I am logged back in
If I login on L5.2, then switch to master, I stay logged in
If I switch back to L5.2, I stay logged in
I'm hesitant to upgrade if it's going to invalidate all of my users' sessions and force them to login again. Is there a way to avoid this?
The only other files that were modified were composer.json, composer.lock, app/Exceptions/Handler.php, and config/app.php; nothing that touched Auth.
I figured out what is causing the session to be invalidated. The problem is the session guard's getName() method.
In 5.1.17:
return 'login_'.md5(get_class($this));
In 5.2 ($this->name would be web by default):
return 'login_'.$this->name.'_'.sha1(get_class($this));
Also, the class name itself changes from Guard to SessionGuard
If I replace this method with:
return 'login_'.md5('Illuminate\Auth\Guard');
That keeps my sessions logged in.
This is progress but not a complete solution yet. The real solution is to update all of your existing sessions with the new name. I'll work on a script to complete this and then update my answer.
That you should do is open app/Http/routes.php
and wrap all your existing routes with:
Route::group(['middleware' => ['web']], function () {
// here your previous routes
});
EDIT
After testing I can confirm this behaviour.
In those cases:
5.1.17 -> 5.2
5.1.23 -> 5.2
5.1.28 -> 5.2.*
after upgrade to 5.2 User seems not be logged anymore. When going in versions in 5.1 branch user stays logged. When going back from 5.2 to 5.1 user is logged again.
At the moment you should probably create issue here https://github.com/laravel/framework/issues and wait for response
EDIT2
It seems it's official and expected behaviour because to upgrade guide has been added:
Because of changes to the authentication system, any existing sessions will be invalidated when you upgrade to Laravel 5.2.

Laravel 4.1 session variables getting randomly forgotten

I'm using a Laravel 4.1 app on Apache, and everything is working fine on my local dev machine, but on my staging machine (which is on a shared host) users are randomly getting logged out and prompted to enter their credentials again.
The relevant settings:
app/config/session.php:
<?php
return array(
'driver' => 'file',
'lifetime' => 120,
'expire_on_close' => true,
'files' => storage_path().'/sessions',
'connection' => null,
'table' => 'sessions',
'lottery' => array(2, 100),
'cookie' => 'laravel_session',
'path' => '/',
'domain' => null,
'secure' => false,
);
using Laravel's default authentication driver
php.ini:
gc_maxlifetime=1440
gc_probability=1
gc_divisor=100
This does not seem to be the same as the issue some others have experienced here. The session file is not getting cleared by php. Just a few of the session variables are getting dropped randomly.
I tail -F'd the session file and could see when the variables are getting dropped between one request and the next. It looks like this (formatted for easier reading) before:
a:4:{
s:5:"flash";a:2:{s:3:"old";a:0:{}s:3:"new";a:0:{}}
s:6:"_token";s:40:"hvuw9VWWjssSwUL2C5eVSn0qZ2g1cwVF5YCEsLG7";
s:38:"login_82e5d2c56bdd0811318f0cf078b78bfc";i:2;
s:9:"_sf2_meta";a:3:{s:1:"u";i:1399318721;s:1:"c";i:1399318011;s:1:"l";s:1:"0";}}
and after:
a:3:{
s:6:"_token";s:40:"7o3b6NhiuDKXq4ftvngUefqe6cWybX1tzPEcDaxk";
s:9:"_sf2_meta";a:3:{s:1:"u";i:1399318721;s:1:"c";i:1399318721;s:1:"l";s:1:"0";}
s:5:"flash";a:2:{s:3:"old";a:0:{}s:3:"new";a:0:{}}}
The login_ session is gone, which results in Laravel's Session class assuming the user is not authenticated. I am not sure why this session variable is getting dropped, though. None of Session::forget, ::clear(), ::remove() or ::invalidate() are being called on the login session variable as far as I can tell.
I also noticed that the _token variable is constant between requests until the moment when the issue arises at which point it changes, as you can see above.
Any idea what's going on here?
Switching to the database session manager seems to have solved the problem. I suspect that there was some way on my host server configuration that php was wiping out the session files.

Resources