After our recent changes to deployment cookie settings, we actually introduced a couple of bugs. So I want to dedicate this chapter to fixing those bugs so that we have a working application on localhost and in production. So they are actually very, very simple fixes, but they improve the app a lot. So currently, if you try to log in on localhost, your app actually doesn't work. That's because of the secure true, which actually breaks the development.
Another problem I noticed is that we cannot log out in production. So we're going to fix both of these things. And I will also tell you how I debugged these issues. So the first one is pretty self-explanatory. Let's go ahead, I'm on my master branch, I'm not in any new branches here, and I will just do bun run dev.
In here you might have noticed some new products here it's because I was actually recording the demo video for this tutorial but anyway I am on my localhost now and I'm going to open my application tab so I can monitor the cookies here and I will delete all cookies for my localhost and now I'm gonna go ahead and attempt to login and you will notice that absolutely nothing happened. So currently on development we cannot log in. The reason we cannot log in is because of our utils inside of modules.alp right here. More precisely, it's because of the combination of same site, domain, and secure. So we need to make sure that these settings are only applied if we are in production, or more specifically, if we are not in development.
So inside of here, what I'm going to do is I'm simply going to spread process.environment, no environment is not equal to development, and then just go ahead and add these options here like this. And in this case, we can improve this by simply setting it to true. So this way, these three settings will not be applied unless we are in production, or in this specific case, when we are not in development. So if you actually save this, it should now start working. But this is very important to understand.
This enables the cookie out on localhost, but it will not work with subdomains turned on. So basically, just make sure that if you are testing this in localhost, you cannot turn on the subdomains. So this will work perfectly with subdomains in production, but in development, it's definitely possible, of course, to make it work, but I haven't found an easy and fast clean way to do it so I think it's just easier you know to work with without that basically work with this set to false in development and in production just change it to true and then this will be applied in production as well. So when you've done these changes, try logging in again on your localhost here. So let me try with AntonioDemo.com.
And there we go, you can see the payload cookie is set, and I can now access the Antonio's dashboard. So that is the first fix that we had to do here. So now I'm going to close localhost because we don't need it anymore, and that is the fix that we wanted. It was basically the combination of secure true, same site and the domain. The other issue I had is the complete opposite.
The logout doesn't work in production. So if you go to funroad.dev, so go to the actual deployed website, not localhost, right? So this is my URL, funroad.dev, right? The domain we have purchased. And I have subdomains turned on here.
So if I go and log in here, the login actually works. But if I go inside of the dashboard and if I try to log out from here, you will notice that it says logging out and then nothing. I can try it again. Logging out, nothing. No matter what I do the cookies are always here inside of my application.
Funroad.dev, the cookie stays here. It will never get deleted unless I manually delete it. So immediately I got to thinking, why is this happening? And I knew it had to do something with this, right? It's something with the same site, this domain here, and secure.
It's got to be it. And then I remembered. Payload has its own auth operation. You remember that we demonstrated using login via the REST API, right? Well, they have the same thing for logout.
And this dashboard right here actually uses dashboard right here actually uses slash admin slash logout, which most certainly uses this API route. So then I was again confused because I assumed that when you log out on Payload, what they do is they delete the cookie, but they don't actually delete the cookie. You see, thankfully, Payload is open source. So I just went into their cookies package and I found out that something they do is they generate the expired payload cookie. So basically what happens is the cookie they expire is not the same as the cookie we create and that's why the logout is not working.
And the fix for this is actually very easy. We just have to use the exact same settings that we use in our custom cookie util inside of the collection, which controls the REST API authentication from payload, which is the users here. So I'm going to open this up, add cookies, and I will do the same thing like this. But we just have to change the same site here to use None with capital letter N. Exactly like this.
And if you're wondering about these fields here, you don't have to worry about that. You can see that it only allows these three options to be changed. So this will now fix both the local and the production instances. And I'm going to try it out now before I mark it as completed. So what I'm going to do is I'm going to shut down the app and I'm just going to do fix resolve invalid cookie settings and let's do git push.
When you git push on master directly, just confirm that it's been pushed, you can now go to your Vercel deployments here And there we go, you can see that I have a new deployment. So I'm going to pause the video and we are going to test out logout feature once more. And there we go, a successful deployment. So I'm going to go to my funroad.dev domain And what I'm going to do is I will purposely clear my cookies here. So for funroad domain, I'm going to clear everything and refresh.
And we are now going to monitor what happens. So Antonio, demo.com and demo. Keep in mind this is deployment, right? Let's first check if this works. I can already see dashboards, so I know that this works.
There we go. I have my cookie. And now, since we have modified our users collection to have the exact same cookie settings as our utils here, the function that payload uses to generate the expired payload cookie will now correctly modify the cookie. So they don't delete the cookie. Instead, they find the cookie that you have and they simply expire the cookie.
So you can go inside of your payload here and try and log out now. And there we go. You can see that now the cookie no longer exists here because it's been properly expired. So maybe they do delete it in some other mechanism, but the problem was the mismatch between the settings in here and in here which is now completely resolved. Amazing, amazing job.
So what I like to do is just one more time confirm that the local host is working simply because we didn't test it after we added this out here. But since we don't even use that directly, I don't think there's gonna be any problems. But I'm just gonna go on localhost and I'm going to try to log in and I'm going to try to log out. So I am already logged in here. I'm going to remove the cookies on localhost here.
Refresh. I'm going to log in as Antonio. Actually, let's try someone else just, you know, test multiple users. Login obviously works. I can now compile the dashboard and let's try logging out on localhost.
That works as well. Great. So we definitely fixed those issues now. We have fixed our localhost and we fixed our production. We pushed to GitHub, which means we automatically deployed this to Vercel.
Amazing, amazing job.