natcave

I set up 2 simple pusher channel apps, 1 for dev and 1 for production.

.env

PUSHER_APP_ID=pusher_app_id
PUSHER_APP_KEY=pusher_app_key
PUSHER_APP_SECRET=pusher_app_secret
PUSHER_APP_CLUSTER=pusher_app_cluster

MIX_PUSHER_APP_KEY="${PUSHER_APP_KEY}"
MIX_PUSHER_APP_CLUSTER="${PUSHER_APP_CLUSTER}"

bootstrap.js

import Echo from 'laravel-echo'

window.Pusher = require('pusher-js');

window.Echo = new Echo({
    broadcaster: 'pusher',
    key: process.env.MIX_PUSHER_APP_KEY,
    cluster: process.env.MIX_PUSHER_APP_CLUSTER,
    encrypted: true
});

This worked fine in dev, but when I compile and push up to production it keeps the dev .env file variable values.

Can someone tell me how to get mix to keep using the dev .env file variable values in dev but then use production .env file variable values in production?

I have a hunch the solution lies with npm run production and npm run dev and I may need to add some code to webpack.mix.js , but I'm not sure. I'm hoping someone ran into this issue already and can let me know.

Thanks!

I'm building an email log table. One of the fields will store the name of the mailable class, for example ""App\Mail\Welcome". The idea is I want to be able to track how many times an email was sent so that automating emails will prevent sending the same email type more than once.

The way I did it was to store the mailable class name in the build function like so:

Mail\Welcome.php

class Welcome extends Mailable

public function build()
{
    $mailable = get_class($this);
    return $this->markdown('emails.welcome')->subject("Welcome.")
            ->with(compact('mailable'));
}

Then, in Listeners\LogSendingMessage.php

// Check for Mailable
if (isset($event->data['mailable'])) {
    Log::info("Mailable: " . $event->data['mailable']);
}               

This works, however I would need to add $mailable = get_class($this); to every Mailable. Is there a way of accessing the Mailable class name directly from the event?

Thanks in advance!

Found the solution. I'm not exactly sure why Eloquent was causing the problem but the real problem going on in the background was I was saving a model instance to the web session. The data was taking up a lot of space in the session files. I assume at some point it breaks the session and regenerates a new one with a new csrf_token.

I updated the code to save a data array instead of a model instance. All is well now. Hopefully if someone runs into this problem my notes will help.

So, just one quick update. This problem seems to only be related to the User model. An example would be:

$order->user

Calling the related user for some weird reason resets the authenticated user's csrf_token value. I've been digging all around for clues, still not finding anything. Any help will be appreciated. Thanks.

I used to be able to call model relationships like:

Office.php

    public function client()
    {
        return $this->belongsTo('App\Client');
    }

$office->client

and it would simply return the related model. All of sudden I started getting csrf errors on pages that called relationship this way (it took a lot of troubleshooting to find out model relationships was the source of the problem).

I had to update the code lines handling these relationships to:

$office->client()->first()

and now the csrf_token is fine, remains constant on these pages.

Any clues what might reset the csrf_token? The page is using the out-the-box web middleware. I'm not sure where else to investigate.

Eloquent and csrf feel like such a weird connection but updating the code style definitely fixed the error, temporarily anyways.

Could this be a problem with a recent update? I'm on v5.5.33.

Thanks.

Awesome! I found it.

I think I was thrown off because I was trying to access the data via cache (I'm using redis as my cache driver). It works when I start from redis.

Here's my solution:

$key_prefix = "laravel:shopping_cart:"; 
$shopping_cart = [];

foreach(Redis::keys("{$key_prefix}*") as $shopping_cart){
    $shopping_cart[substr($shopping_cart, strlen($key_prefix))] = unserialize(Redis::get($shopping_cart));
}

Thanks for your help @Cronix

Thanks for your response @Cronix,

I think I passed by that page while hunting for an answer. I'm looking for a way to retrieve the data within the laravel app, not on the command line. Sorry for not being clear.

Do you know of a way to retrieve the data via the Cache or Redis facades perhaps? If you have a quick code example that would help. Thanks.

Maybe I have the wrong idea, but let's say I have these keys in redis:

laravel:shopping_cart:1
laravel:shopping_cart:2
laravel:shopping_cart:3
laravel:shopping_cart:4
laravel:shopping_cart:5

Is there a simple way to iterate over any keys that start with "laravel:shopping_cart:" and return an array? Something like:

$shopping_carts = [
    1 => // laravel:shopping_cart:1 value,
    2 => // laravel:shopping_cart:2 value,
    3 => // laravel:shopping_cart:3 value,
    4 => // laravel:shopping_cart:4 value,
    5 => // laravel:shopping_cart:5 value,
]

I guess I could cheat and do a while loop starting from 0 and test every combination up to a point but that seems sloppy. I can't seem to find any info on retrieving existing values without first knowing the full key. Maybe I'm just missing it or perhaps is this where I get off the Redis train and head over to MYSQL?

Thanks for any insight!

I know this is an old post, I just wanted to leave a comment in case someone was searching for a solution. In my case I had forgotten to add some files to my repository before pushing to production (notably, a new middleware class in the mix). That explained why it worked fine locally because the app worked with the local files whether or not they were added to the repo. After adding, committing and pushing the new files the error went away. Hope this helps someone.

I was hacking away at this problem for a while now and found an odd occurrence that solved my problem. I'm documenting it here because this post came up as a top search result, so it may help someone else and shave off a few troubleshooting hours.

The urls in my queued emails were not matching the APP_URL variable in my .env file or the url value in my config/app.php file. (Quite frustrating)

I had built a new server on Forge which comes along with a "default" site, then added my "new" site on the same server with a similar .env file. Similar except of course for the APP_URL variable (you may see where this is going).

It turns out, the jobs starting on my "new" site were being picked up by a queue worker on the "default" site, thus plugging in the APP_URL variable set on the default site, which I assume for most people would be "http://localhost".

The solution for me was to simply turn off the queue worker on the "default" site.

So, the lesson here is to check if any other sites on the server are hijacking your queues, therefore plugging in the wrong APP_URL.

Hope this helps someone!

Thanks so much for sharing @ashwinmram!

I just wish I found this post 16 hours ago. :-) You pretty much outlined all the steps I stumbled upon but I hit a roadblock trying to get it working with Forge. It's so much simpler when you have the steps outlined like this. For a moment I thought I would have to leave my terminal window open permanently lol.

I'm sure you'll help plenty of other newbs like myself. This topic is definitely worthy of a video for Jeffrey. Especially since a lot of the videos surrounding these topics are now a bit outdated. They're helpful to put you on the right track but they don't quite complete the picture for someone beginning a project today.

It works great so far, will keep an eye on it. Just dropping a line to show my appreciation. Thanks again!

@janise are you on a PC? That was related to my problem. If you're on a PC try laragon. You can read my saga here or just skip to the end. https://laracasts.com/discuss/channels/laravel/laravel-not-reading-session-cookie-on-form-post-in-chrome-when-logged-in-with-remember-me

Hey @jessiesanford

I can definitely relate. This problem was driving me nuts. I had to switch from Wamp to Laragon. Thankfully I haven't had the problem since. Laragon is pretty cool https://laragon.org/

Check this thread I created if you're curious about my saga lol. Scroll to the bottom for the happy ending.

https://laracasts.com/discuss/channels/laravel/laravel-not-reading-session-cookie-on-form-post-in-chrome-when-logged-in-with-remember-me

I built a script in Laravel that renames database table column names.

Schema::connection()->table($table_name, function ($table) use ($value) { $table->renameColumn($value['from'], $value['to']); });

It crashes with an error:

SQLSTATE[42000]: Syntax error or access violation: 1067 Invalid default value for 'created_at' (SQL: ALTER TABLE table CHANGE creation_timestamp created_at DATETIME DEFAULT 'current_timestamp()' NOT NULL)

The sql statement gives a clue, reporting creation_timestamp as a DATETIME field.

I ran this mysql statement at the command line:

SELECT DATA_TYPE FROM INFORMATION_SCHEMA.COLUMNS WHERE table_schema = 'schema' AND table_name = 'table' AND COLUMN_NAME = 'creation_timestamp';

The result I get is: timestamp

I ran this code in Laravel:

echo DB::connection('mysql')->getDoctrineColumn('table', 'created_at')->getType();

The result is: DateTime

Any clue why Laravel is reporting DateTime when mysql clearly reports Timestamp?

Thanks.

pluck() works great. Thanks @Snapey.

@Snapey Really? I didn't know. I'll check out pluck now. Thanks for the heads up.

This did the trick:

$store->subcategories()->lists('subcategories.name', 'subcategories.id')

When I remove "subcategories." before "name" (how I had it) I get the ambiguous field error.

Thanks for your help @Snapey and @bwrice. I appreciate it!

Hey @Snapey

I'm calling $store->subcategories() in a blade template, specifically in a select drop down so I wrote it as $store->subcategories()->lists('name', 'id'). I get the error in my relationship definition.

Thanks @bwrice

Yes, I do. I'm able to use $store->categories, $category->store and $subcategory->category. But I'd like to generate a list of $store->categories->subcategories, giving me a list of all subcategories related to a store. I know how to write it in MySQL but I was trying to follow the Laravel format. It seems it would work fine if I didn't have ambiguous names in both related tables.

Thanks @Snapey

I'm not sure I follow. I'm not using select statements on any of the hasManyThrough relationships. Do you think I need a select statement in this case?

I have 3 tables. Let's call them "stores", "categories" and "subcategories".

categories has 3 columns: id, name and store_id

subcategories has 3 columns: id, name and category_id

So, both categories and subcategories have a "name" column.

I'm trying to get all the subcategories related to a store, so I'm using HasManyThrough in the store model:

subcategories() { return $this->hasManyThrough('App\Store\Subcategory', 'App\Store\Category'); }

This make sense, but I'm getting an error:

"Integrity constraint violation: 1052 Column 'name' in field list is ambiguous"

Is there anyway to tell Eloquent I'm only interested in the subcategory name?

Thanks.

Checkout this thread. I discovered the bug for me was with XAMPP. I switched to Laragon. Problem solved.

https://laracasts.com/discuss/channels/laravel/laravel-not-reading-session-cookie-on-form-post-in-chrome-when-logged-in-with-remember-me

Wow!

So far so good.

So the culprit is wamp all along.

It would be great if they put a warning for the newbies migrating from wamp/xampp

Thanks so much @ramouspeppy!

I'm back to work. :-)

That sounds great @ramouspeppy!

Where would I change the "engine"?

Hey @ramouspeppy

Unfortunately, no. I'm quite surprised more people haven't run into this problem, especially with all the praise Laravel gets.

I ended up disabling the Remember Me option. You can also disable Encrypt Cookies resulting in a smaller cookie size but I believe that will cause a security vulnerability.

If you find an answer, please share it. Thanks.

Hey @poupouxios

That's what I assumed, though I'm not adding any cookies. This happens with Laravel's cookies straight out the box. With Encrypted Cookies it makes the cookie parameters very long. My best guess is Chrome doesn't like it. I only noticed the problem when "Remember Me" is checked because that adds another encrypted cookie to the bunch and Chrome starts trimming in the middle of that cookie request. I went into detail on these posts:

https://laracasts.com/discuss/channels/laravel/laravel-not-reading-session-cookie-on-form-post-in-chrome-when-logged-in-with-remember-me

http://stackoverflow.com/questions/39430796/chrome-post-cookie-string-returns-to-server-incomplete

Oddly, it hasn't caught the attention of anyone with the same problem. The key factors are Chrome + Laravel + Remember Me + Form Post.

Hey @poupouxios

I'm only building one laravel app. I tried changing the session cookie cookie name anyway, the same problem happens. In your case, did the cookie cut off like mine?

Hey @stan

I'm having a similar issue with Chrome cutting off the end of my cookie requests.

https://laracasts.com/discuss/channels/laravel/laravel-not-reading-session-cookie-on-form-post-in-chrome-when-logged-in-with-remember-me

• Firefox works fine.
• Chrome only works when I don't have the remember cookie set.
• Chrome will work if I manually delete the cookie, or if I turn off the Encrypt Cookies middleware (making the cookie values significantly shorter, but in turn disabling the security feature).

It seems to be an issue with the length of the cookie request. I've been racking my brain (and Google Search) at this for a week now, not getting any answers. Chrome is trimming my cookies down to 907 characters, yet every resource I find says I'm allowed 4KB.

Since your post seems similar to my issue, I'm just curious if you ever found a solution. Thanks @stan

Here's the latest big clue yet:

Although Chrome looks like it's sending the entire encrypted session cookie, the end of the cookie value is missing in Laravel.

Here is the session cookie value Chrome sends:

eyJpdiI6Ik1BY1M0XC9Ma3luZjlBdGp6S3BOWWZ3PT0iLCJ2YWx1ZSI6IkU1SEh5dDNLZEFRTmVGTTNZM2NkRVRiUExleWRlbGpcL1M2clR2VWlaTm1pQnhrSnl1djVhc2wzU3l5NHNaMDhhVGphaUVadGlqZEpJMmxxV2VVWUtZQT09IiwibWFjIjoiODBiMTQ3OTc4ZWFjNmVlNDA1YjhlZDA1YmNiYmFiMmJlOTcxMTczMjI3ZjFhZDZmYTQ0NjNmMmYyMTU2NDFkMiJ9

Here is what the server reports:

eyJpdiI6Ik1BY1M0XC9Ma3luZjlBdGp6S3BOWWZ3PT0iLCJ2YWx1ZSI6IkU1SEh5dDNLZEFRTmVGTTNZM2NkRVRiUExleWRlbGpcL1M2clR2VWlaTm1pQnhrSnl1djVhc2wzU3l5NHNaMDhhVGphaUVadGlqZEpJMmxxV2VVWUtZQT09IiwibWFjIjoiODBiMTQ3OTc4ZWFjNmVlNDA1YjhlZDA1YmNiYmFi

Here is the entire cookie string:

remember_web_59ba36addc2b2f9401580f014c7f58ea4e30989d=eyJpdiI6IndDS1lrTkxVeGdMY1N1XC9uVERyVWx3PT0iLCJ2YWx1ZSI6Im5jVUtKdG5FZ01QbkJnTDNJV1RMMnhpd3Nja1wvS1NESVV6Rm83MjdXQmFcLyszSUtvOGVIM2V2MUtWd0VpelJUU3hXRVhhMmdCR1JINEFTUzBMTTd4TGVcL0lSeTZleUMwZXBxb1hsK25SRmtNPSIsIm1hYyI6IjNjNmNhNGE2YWMwNmEwZjI1ODI2ZjU3ODE2M2ZlNDIwZWMzNDM0MTMyMzdmNTFkYmQ0YTY1NzFkZDNhM2RjMGUifQ%3D%3D; _gat=1; XSRF-TOKEN=eyJpdiI6IlQ2aHpnNmN0V2w1bWtKZU03SnlKeFE9PSIsInZhbHVlIjoiVWJhdzVSOXFibDhSRTJRcVQrWXBOVkVzN3NGSnFmb1ZFRlozTzlcL29La0F4dXZmU1U5dGZTOXdHMUl5NSs4Q3NDK1dXTVdacll0c1NBeXNzTXYzTnBRPT0iLCJtYWMiOiI2NGQ4ZTQwOTZjOWIzZTljMTlkYjcxNTEyMjNmY2FjNjhiZGFkYjA4YzRkMmYwZDM1Yzc4ZTVlZGQ3ZmE5YWNkIn0%3D; web_session=eyJpdiI6Ik1BY1M0XC9Ma3luZjlBdGp6S3BOWWZ3PT0iLCJ2YWx1ZSI6IkU1SEh5dDNLZEFRTmVGTTNZM2NkRVRiUExleWRlbGpcL1M2clR2VWlaTm1pQnhrSnl1djVhc2wzU3l5NHNaMDhhVGphaUVadGlqZEpJMmxxV2VVWUtZQT09IiwibWFjIjoiODBiMTQ3OTc4ZWFjNmVlNDA1YjhlZDA1YmNiYmFiMmJlOTcxMTczMjI3ZjFhZDZmYTQ0NjNmMmYyMTU2NDFkMiJ9; _ga=GA#.#.##########.##########

The total length is 988 characters. It cuts off after 907 characters. The final "_ga" cookie (not related to Laravel) doesn't even make it in.

Since Laravel doesn't receive the entire session cookie, the decryption fails and sets the session cookie value to "null", killing the session, CSRF token, and so forth. I still don't know where the breakdown is. If this is a problem with Laravel, why doesn't the same problem happen in other browsers?

My best guess is: with the remember me cookie encrypted, session cookie encrypted, and XSRF-TOKEN cookie encrypted, Chrome hits a limit of what it will send with my form post and decides to trim the cookies, actually only sending part of the value of my session cookie, causing Laravel to fail the decryption and "null" the session. But is this a problem with Chrome sending the cookies or a problem with Laravel receiving the cookies? For the moment I'm stuck. Any ideas?

Here are my thoughts:

• Is there a setting in PHP/Laravel to increase the amount of cookie data receivable with a post form? (I'm not sure if this is exists or for that matter why it would be browser specific, just a thought.)
• Can I limit the size of the encrypted cookie value? (Since disabling the encryption lowered the string length and post submitted fine.)
• Do I need to encrypt all these the cookies, or any of them? (since disabling the encryption did the trick, yet I don't want to leave the front door open).
• Does Chrome's cookie delivery method differ from other browsers? (I'm trusting Chrome is sending all the cookies because that's what I see in the developer tools, but how would I know for sure?)
• Is there a way to utilize local storage for these long strings instead of cookies? (If Laravel insists on sending these long strings that Chrome doesn't like, maybe they should be stored in local storage since there is plenty of space in there, though I'm not familiar with using local storage, maybe the protocol rules are more flexible than with cookies.)

I'm still hoping someone with more experience than I have can chime in and save me some steps. I'd appreciate it. Thanks!

Ok. Here's another clue. In App\Http\Kernel.php I commented out this line in middlewareGroups:

\App\Http\Middleware\EncryptCookies::class

Like magic it's working. I'm guessing the EncryptCookies middleware doesn't like the incoming cookie from Chrome.

Any thoughts how to troubleshoot from here?

I'm sorry for the long title. Although I've seen similar posts, this problem is specific.

I use Chrome for testing my projects. Seemingly out of nowhere I started getting TokenMismatch Exceptions when I submit forms. I knew this is could be because the CSRF token expires after some time. However this happens consistently, even if you submit the form immediately after the page loads. I eventually figured out the Exception only occurs when I checked "Remember Me" at login. Here are my test results:

Chrome + Uncheck Remember Me at login + Form Post = Success

Chrome + Check Remember Me at login + Form Post = TokenMismatch Exception

Chrome + Check Remember Me at login + Delete Remember Me Cookie + Form Post = Success

Firefox/IE + Check/Uncheck Remember Me at login + Form Post = Success

I figured out the reason why I'm getting TokenMismatch Exception. In between the form post I mysteriously lose the session. A new session generates automatically in the background, resulting in a new CSFR token, resulting in the TokenMismatch Exception.

I tried everything I could think of: deleting cookies/browser data restarting Chrome reinstalling Chrome restarting the server changing the Laravel session driver removing middleware reinstalling Laravel deleting the vendor folder starting a fresh Laravel project

Absolutely none of these fix or change the problem. I've been at this for 2 days now, scouring Google for clues. I can't find any answers, only a few posts from people who may have had the same problem but haven't yet reported an answer. Very strange.

Finally, after a night's sleep I found my biggest clue yet. I setup a temporary dd($request) to reveal the request variables. When the TokenMismatch Exception occurs, within the response output I get:

Request {+cookies: ParameterBag { #parameters: array[ larvel_session: null

Note the "null" for larvel_session. When the form posts successfully (on Firefox with Remember Me cookie), the dd($request) outputs:

Request {+cookies: ParameterBag { #parameters: array:[ larvel_session: <>

I checked the post headers in Chrome. Everything looks correct. Chrome is sending the session cookie to the server. However, the dd($request) shows me that there is a break somewhere. This is a great clue but I don't nearly know enough about Laravel to troubleshoot past this point. What might be going on behind the scenes to cause Laravel to "null" the incoming session cookie when receiving a form post from Chrome along with the remember me cookie. It's a mouthful, but a valid description.

If you have experienced this phenomenon, please share the steps you took to repair it. Also, if you have any suggestions on how to solve this problem I would truly appreciate it, as will the next person frantically Googling for clues. I've come so far learning Laravel, I'd hate to have to stop here. Thanks!

I'm having the same issue. Any update?

Hey. I'm having the same issue with Chrome. Very strange (and frustrating).

For me it's only when the "remember" cookie is set. If the remember cookie set and I delete it, the form processes properly.

Firefox works fine, only Chrome is kicking back the Token Mismatch.

Just curious if anyone figured this out.

Thanks @simondavies, I will do exactly that to grow the existing data.

I tried a few other options that didn't pan out. However, I did a little more digging and found this sweet function:

DB::unprepared(File::get($file));

This function imports a database export file. So now I can export my database test table and save it in a folder within the project. Then ad this code to the migration file and it will pull the last export data right back in, instead of having to regenerate new fake data. Pretty cool.

I still would like to find a function that will create random real addresses but this is the next best thing.

Thanks so much for your help guys. If anyone stumbles on a solution, feel free to drop a line on this thread. Since I'm a newbie I won't be far. :-)

Thanks mstnorris. I see now that I don't have to use the faker, I can just replace it with an insert statement. Cool. I thought it would be nice to pull in random real addresses, just wondering if anyone else ran into this scenario and found an answer. In the meantime, I'll set it up manually. Thanks for your quick answer.

Hey there. Laravel newbie here, having lots of fun learning. I'm building a store locator app. I was excited to learn that faker will generate fake street addresses. Awesome! However, when I tried map the results I quickly learned the addresses were not real. The latitude, longitude, postal codes, states, cities, and street addresses do not relate to one another, they are randomly put together. This would work great for a shopping cart app that needs shipping information, but for geocoding I need real street addresses. Any suggestions?

Here is my ModelFactory.php file