Closed JTD420 closed 5 years ago
Given that you say it works fine in dev but not in production, the first place I'd look is your caching config. Next would be to make sure your migrations/seeders are actually fully correct such that all your permission/role dependencies have been created correctly with the expected guards.
The other place I'd look if it wasn't just a mismatch between dev vs prod, would be in your code if you're using multiple guards and it's legitimately not finding a match because your non-primary guard isn't being declared in your code. But it would be failing in dev too if that were it.
In summary, I suspect it's related to either a server-config thing or it's a provisioning/deployment thing.
Where would the caching config be and what would I be looking for?
I haven't created/used any seeders besides from the default ones that come with laravel and/or any dependencies of my project such as this one...
I used Forge to provision and deploy the server automatically for me and then I used mysql workbench to import all of the SQL data from my development server to the production server (so should skip the need for any migrations and should be identical to my development machine, or so I thought?)
Thanks for your advice so far! :) It's not the most important thing in the world as I've now removed it from my code and I'm just not using permissions and can rely on roles if necessary but I am curious as to what's at fault here tbh... 🤷♂️
Cache is configured in your .env
file, and greater granular control in your /config/cache.php
file.
If your dev environment is configured for a different caching strategy than your server then that might explain the anomaly.
Granted, I would have expected roles to be broken too.
I don't think I'd ever just import the SQL without running migrations. The whole purpose of migrations is to keep schemas in sync, and to allow code-driven updates so that deployments can apply updates to the db structure/data as needed. ie: while your initial load might be conveniently deployable by just exporting/importing your dev db content, once your app is live you won't be able to control the db that way anymore. Anyway, that's a devops issue.
Steps I'd take if it was my server would be to compare the complete config between both environments, starting with .env
and progressing from there. Forge may have chosen some defaults that your dev environment does differently.
I'd be inclined to create app tests that run before/during deployment, so that you know before deploy that everything's working consistently in multiple environments. If your tests fail then you can fix things before it goes to production. Again this gets into DevOps, but it sounds like your workflow might benefit from the peace of mind of knowing whatever environmental issue is causing this malfunction.
Hi,
I've deployed my project to AWS using Forge but it is telling me that my user doesn't have X permission when I go to view restricted pages.
I've imported my database exactly as it is on development but it doesn't seem to be working 1:1 on the production server.
What's weird is it was able to work with 1 of my permissions just not the other.
I am checking the user has the required permission through a construct in my controller
It seems like the issue is specifically with the Permissions. What I mean is that the Roles table seems to be working as expected but the permissions tables are where the problem is.
What could possibly be going wrong here? I can remove the permission requirement from the code for now but ideally would like it in there...