Laravel 5 Route Strange Behaviour - laravel-5

I have a Laravel site set up on a Homestead box, so I'm accessing it on sitename.app:8000. I have a route called "news" but when I try to go to sitename.app:8000/news I get oddly bounced out to sitename.app/news/.
If I change the routename to "news2" I can access the desired controller action as per normal at sitename.app:8000/news2. So somehow it's "news" itself that has become uncooperative - and I'm pretty sure that we aren't even getting as far as the NewsController, when I try to access that url.
Can anyone work out from these symptoms what might be going wrong? One "news"-related change I made at some point was to add $router->model('news', "App\News"); in the boot method of the RouteServiceProvider, but removing this doesn't seem to make the difference.
ETA: People keep asking for the routes.php file. I can literally remove everything from the file except
Route::get('news', function() {
return "hello world";
});
Route::get('news2', function() {
return "hello world";
});
and /news2 will work but /news will bounce me out. So I remain pretty convinced that the problem is somewhere deeper than routes.php...

I finally worked out what boneheaded action of mine had been causing this behaviour!
I had created a folder in /public named "news"... i.e. with the same name as an important route. Not sure exactly what havoc this was wreaking behind the scenes for Laravel every time a request for /news was being made, but one can assume it was nothing good.
Advice for anyone tearing their hair out over a route that "mysteriously doesn't work" - check your public folder for possible collisions!

This is a known issue Larvel missing port
The easiest way to solve this problem is to go to public/index.php and set the SERVER_PORT value.
$_SERVER['SERVER_PORT'] = 8000;
Don't forget to set the base url in the config if you are using links on website, the url generator uses the base-url defined in the config.
Last option is to change the vm portfoward in VagrantFile to point to port 80 and use port 80 for your app.

Related

User authenticating but not staying logged in Laravel 8.x

When testing my application and trying to create a new user then on form submission I am getting error 419.
If I use a helper to log in using Auth::loginUsingId(x) for an existing user then dd(auth()->user()) is successful but when I redirect to another page the user is no longer logged in. eg running the following code, you end up getting redirected to /login:
Route::get('/logInAs/{id}', function ($id) {
Auth::loginUsingId((int) $id);
dd(\auth()->user());
return redirect()->route('dashboard');
});
I would share more code but I'm not sure what would be useful at this point?
I've probably spent about seven hours trying to fix this so far. It's driving me up the wall!
The app works fine on other environments, such as staging. I've even gone so far as to re-download it from github as a fresh install (in case I was messing about in vendor directory and changed something), but that hasn't fixed it.
I get the same issue on Chrome, using different signed in users on Chrome, using incognito mode on Chrome, using Firefox, and using valet share and accessing my local version on another device, like a phone, so I don't think it is to do with browser caching.
When other devs working on the project run it locally on their machines I haven't had reports of this issue, so it seems to just me my local environment.
I've variously tried changing CACHE_DRIVER and SESSION_DRIVER in .env to no joy, but I'm beginning to lose the will to live so don't really know if I'm doing the right thing there - please help if you can!!
Edit to add more detail:
Middleware on the dashboard route:
Route::middleware(['auth:sanctum', 'verified'])->group(function(){
Route::get('/dashboard', DashboardController::class)->name('dashboard');
});
If I remove the middleware then I just get an error that user is null on dashboard.blade.php, ie the user is still not staying logged in.
A custom middleware:
class VerifyUserIsMerchant
{
public function handle(Request $request, Closure $next)
{
if ($request->user()->isMerchant()) {
return $next($request);
}
throw new AccessDeniedHttpException('You must be a merchant to access this page');
}
}
If I dd($request->user()) in this middleware it returns null.
The issue got fixed with the help of Laracasts. The full answer is here.
In short, I needed to remove the http:// protocol from SESSION_DOMAIN in .env and set it to match APP_URL.
This was the correct answer for this issue. It was deleted by a moderator. Moderator, before you delete this answer as well please can you explain why?
It provides the full answer to the issue raised in the question. I did not find this answer to this issue anywhere else (hence why it took me several days of debug to fix).
If I can know why it was deleted, I can then understand how to avoid making answers in the future that also would be deleted. Thank you.

Laravel forcing Http for asssets

this is a little bit strange because most of the questions here wanted to force https.
While learning AWS elastic beanstalk. I am hosting a laravel site there. Everything is fine, except that none of my javascripts and css files are being loaded.
If have referenced them in the blade view as :
<script src="{{asset('assets/backend/plugins/jquery/jquery.min.js')}}"></script>
First thing I tried was looking into the file/folder permissions in the root of my project by SSHing into EC2 instance. Didn't work even when I set the permission to public folder to 777.
Later I found out that, the site's main page url was http while all the assets url were 'https'.
I dont want to get into the SSL certificates things just yet, if it is possible.
Is there anyway I can have my assets url be forced to Http only?
Please forgive my naiveity. Any help would be appreciated.
This usually happens if your site is for example behind an reverse proxy, As the URL helper facade, trusts on your local instance that is beyond the proxy, and might not use SSL. Which can be misleading/wrong.
Which is probaly the case on a EC2 instance... as the SSL termination is beyond load balancers/HA Proxies.
i usually add the following to my AppServiceProvider.php
public function boot()
{
if (Str::startsWith(config('app.url'), 'https')) {
\URL::forceScheme('https');
} else {
\URL::forceScheme('http');
}
}
Of course this needs to ensure you've set app.url / APP_URL, if you are not using that, you can just get rid of the if statement. But is a little less elegant, and disallows you to develop on non https

Sentry on Laravel 4 with MAMP

I'm using Laravel on MAMP PRO (PHP 5.4). Both are vanilla install and I got Laravel working okay.
Next, Installed Sentry.
Inside of a login function on controller:
$user = Sentry::authenticate($credentials, false); // this works. I can see the $user
But then upon an immediate redirect I use a filter:
Route::filter('auth.admin', function()
{
var_dump(Sentry::check()); // ** this gives me a bool(false);
die();
if ( ! Sentry::check())
{
return Redirect::route('admin.login');
}
});
So, I'm assuming that maybe there is a cookie that is not being set?
Solved...
For anyone else with this issue, this is a summary of the most common solutions on the Internet as well as how I solved my issue. I'm on MAMP/OSX, but this apparently made zero difference as I literally put up a vagrant/virtualbox and still had the same issue.
** Set 'domain' => 'yourdomain.com' in your config/session.php. EVEN IF YOU ARE ON A SUB DOMAIN like a.b.c.yourdomain.com, use ONLY the root domain (yourdomain.com) in your 'domain' variable as I just wrote it. ** This was my issue.
Make sure your session storage folder has write permissions.
Make sure you have a >0 lifetime in your session.php
Make sure you don't have whitespaces after any closing PHP which could cause the application not to shut down properly.
Try Switching between database sessions and file sessions.
As a last resort, try upgrade to 4.2, if possible. 4.1 had a known issue (as referenced in google).
Your issue is may no be with Laravel OR Sentry. It's probably a file or configuration issue as illustrated above. I pulled my hair out tracking this from Sentry to Laravel to Cookies to Session to Blah... Only to realize that it was finally a cookie issue which was caused by me not setting my ROOT domain (I was using the full

CodeIgniter redirect not working on a real Server

I'm having a problem with CI 2.1.3 redirect function.
Everytime I call redirect, it shows a white-blank page. In fact, it works well on my localhost, the problem just occurs on my real server (with CentOS 5 installed).
This is how I call the redirects :
redirect('frontend/article/index');
or
redirect(base_url('articles.html'));
I did add a route in config/routes.php
$route['articles.html'] = 'frontend/article/index';
with : frontend is module, article is controller, and index is action (I'm using wiredesignz's HMVC module extension)
How could I fix it? And what is the problem here?
Thanks in advance!
UPDATE
I replaced CI redirect function by calling :
header("Location: http://example.com");
but it didn't work too.
So I created a file named info.php and uploaded it to my server. Here's the content:
<?php
phpinfo();
?>
When I type in the address bar : http://example.com/info.php, it shows like in the image.
Why was there a ">" character? Was it the problem causing redirect not working?
Firstly, make sure error reporting is enabled, or try placing the following at the top of your index.php.
error_reporting(E_ALL | E_WARNING | E_NOTICE);
ini_set('display_errors', TRUE);
If this doesn't point you in the right direction make sure you don't have any output echo, print_r, print, dump, etc before your call to redirect() method.
Another common cause or problems when moving to a new environment is white space. Check that your files don't have any whitespace at the bottom of them.
if you are defining .html in the config.php as the file ext. you do not need to postfix the route with it.
$route['articles'] //instead of $route['articles.html']
Also you need to remove the base_url() from the redirect cos that is not needed.
redirect('articles'); //should sort it
Hope this sorts ur problems.
EDIT
If this is still not working after attempting these changes, it will most likely be a problem in the controllers. If this is the case you may need to turn on error reporting in your index.php file to find out exactly where the problem is occurring.

Routing issue with 404_override

I'm having an issue with 404_override in CI 2.02. Here is my default controller and override:
$route['default_controller'] = "home/index_controller";
$route['404_override'] = "misc/site_map";
This line uncommented gives me this error:
Unable to load your default controller. Please make sure the
controller specified in your Routes.php file is valid.
But commented, I get a 404 error. So something in the override is causing the problem. I just don't know what. I've tried various MY_Router files and they don't help. Anyone have any suggestions about how I can fix this?
I've eliminated my .htaccess file as the problem by deleting it from the server and then trying to access a controller that doesn't exist like this: http://domain.com/index.php/doesnotexist. I still get the error.
For anyone else coming here with this issue, this is/was a bug in CodeIgniter itself to do with 404 pages not being able to be included in subfolders.
Bug Discussion Including Fix on GitHub
You have forgotten to add the default controller that will be used when you first load your website, in your routes.php you need to add this, it is required which is why you're seeing the errors being thrown.
$route['default_controller'] = 'index'; // this will need to be changed to your default controller
$route['404_override'] = 'misc/site_map';
EDIT:
Okay, you must make sure you enter the correct controller name you wish to load as the default, for example you have home.php in your controllers folder, you must enter home as the default. Optionally, you can define segments that are functions in your home.php class file, e.g. home/function_name.

Resources