I believe that to make intended works you have to previously call Redirect::guest()

check this post: http://www.volkomenjuist.nl/blog/2013/06/18/laravel-4-redirect-to-the-intended-url-after-login/

But shouldn't "intended" or not be irrelevant when Auth is session_based? I would think that when I apply the filter "auth" to a route, what it SHOULD do is check the sesions to see whether the user is logged in or not?

Bumpity bump bump?

Are you being logged in after the attempt? Is your login route using a guest filter? Also, get rid of those raw lines with echo '', they might be messing things up.

1. I think I'm being logged in after the attempt, because the page redirects as if it were sucesfull, only to redirect back to the login page as if it had incorreclty worked.

2. No I'm not using a guest filter on my login route explicitly. (I'm using the default login redirect that comes in laravel)

Let me see if I can't be a little more explanatory, since as of right now I'm loving Laravel and am considering it for my future projects, but something as simple as this needs to work :P. So here goes:

The user tries to access a route that requires auth before completing.

Route::get('/user/{type}/{id?}', array('before' => 'auth', 'UserController@showProfile'));

Since auth is required it redirects to /login via the GET method, and returns a form for them to login to.

Route::get('/login/{appID?}', 'LoginController@loginGET');

--------------------------------------
public function loginGET($appID=null){
		if(!$appID){
			$form = Form::open(array('url' => '/login'));
			$form .= Form::text('email','lotsmorestuffhere');
			$form .= Form::password('password');
			$form .= Form::submit();
    		$form .= Form::close();
			return View::make("login")->with('form', $form);
		
		}
	}

When the form is submitted, it takes them back to the same page via the post method so we can verify the auth credentials are correct.

       Route::post('/login/{appID?}', 'LoginController@loginPOST');
--------------------------------
	public function loginPOST($appID=null){
		if(!$appID){
			$email = Input::get('email');
			$password = Input::get('password');
			if (Auth::attempt(array('email' => $email, 'password' => $password),true)){
			    return Redirect::intended('user/delete/delete'); // but when I use this, it redirects back for authentication again
			}		
		}
	}	

}

If auth::attempt suceeds they hit the original route again

Route::get('/user/{type}/{id?}', array('before' => 'auth', 'UserController@showProfile'));

But for some reason instead of displaying the page, it thinks that the user isn't authorized and redirects them to the login page again.

Put a guest filter on your login routes, like so:

Route::get('/login/{appID?}', array('before' => 'guest', 'LoginController@loginGET'));
Route::post('/login/{appID?}', array('before' => 'guest', 'LoginController@loginPOST'));

While I'm not entirely sure what the guest filter is supposed to changeto change (it appears that it redirects to root if the user is logged in), I tried to use it: but before I can even see if it fixed the issue, I'm getting an error (but even stranger: with ONLY that filter).

ErrorException
call_user_func_array() expects parameter 1 to be a valid callback, no array or string given

Every other filter that is pre-defined doesn't throw a similar error, and I have not modified the "guest" filter.

Route::filter('guest', function()
{
	if (Auth::check()) return Redirect::to('/');
});

Hey there, I got similar issue, I didn't read this thread before, anyway, the issue is similar, it comes after Redirect::to , whenever Redirect::to is called, Auth::check() returns false even though before Redirect::to is called returns true.

Bump, once more. Issue still unresolved.

Are your normal sessions working? Try

Session::put('test', 'test string');

or something, then delete the line, then put

dd(Session::get('test'));

and see what that outputs. There might be a problem with your session config (config/session.php).

Are you on 4.1.*? If you're on dev-master, then it's expected that there are a bunch of bugs like this.

I don't have a solution but if we can get a little more info I might be able to help.

If you install Fiddler, or some other HTTP debugger tool and then go to the page, be redirected to login, then login... what does Fiddler show? Was the a 301 redirect raised? Or a 401?

It might help to know what type of redirection is happening also you can inspect the headers and make sure everything is being submitted correctly in the forms.

AndrewSuzuki, I hadn't known the version of Laravel I was using. As dumb as it sounds, I was just blindly following a tutorial for installing on WAMP. I used

$laravel = app();
$version = $laravel::VERSION; /// 4.1.23

So I'm assuming that, yes I am using a version of Master. Oddly enough though, I had checked to see if sessions were working, even through laravel, and yeah, it seems like it is. I hadn't known that master was committed without testing/with bugs.

Session::put('test', 'test string');

Removing and then

dd(Session::get('test'));'

produces a var_dump of the variable as it Should. So no luck yet on that side. Is there anything more auth-related in terms of storing sessions? Or Should I be looking to revert to a more stable version of Laravel?

IanSirkit, nothing weird on that front, on a successful login:

200	GET	 /laravelApplied/login	http://localhost	127.0.0.1

It immediately sends back the GET HTTP response as it should. Just as well a failed login attempt reacts like it should, the page just stops at the POST method that is routed to.

   200	POST	 /laravelApplied/login	http://localhost	127.0.0.1

Thank you though :/

4.1.23 isn't master, the current master is working on 4.2, so you should be all set as far as huge bugs. Although, this means that this is almost definitely not a default of laravel here.

Wheres this tutorial you're following? Have you set all your config files, site url, etc? Specifically auth.php?

Make sure to check laravel.log to make sure any errors aren't showing up there when you attempt login.

For more random testing, you can try putting something like this in your events file, or just routes.php if you don't have that, and tailing your laravel log:

Event::listen('auth.login', function($user)
{
	Log::info('user with id ' . $user->id .' logged in.');

	if (Auth::check()) {
		Log::('AUTH CHECK SUCCESS');
	}
});

Event::listen('auth.logout', function()
{
	Log::info('user logged out');
});

Obviously, you're looking for exactly two logged lines here: user with id ID logged in && AUTH CHECK SUCCESS.

I have the same issue using Sentry 2. I checked the SessionController and get a successful login and session before the redirect and then check the before filter and controller before it gets to the route and it has lost the session. I have found that it seems to work if I delete my controller routes in the routes.php, run the page again allowing the redirect to fail, adding the routes back and then running again seems to work. I can go for days and not have the issue and them get it all of a sudden. Its impossible to log in with the changes I make to the routes file.

I also have the same problem I wanted to know if I get to solve, I'm working with Laravel 4.2. Thank You

I have same issues also, Laravel 5.1. Please refer to my thread thank you http://laravel.io/forum/11-09-2015-login-as-guest-instead-of-user

I have the same issue also, Laravel 4.2. The strange thing is that it started happening out of the blue, I didn't change anything to any login controller or whatever. I only changed some html and css. For me also, the login attempt is successful, but after redirecting the Auth::user()->check() gives false. After redirecting I have also tried to see if I have a session token, and I do have one.

I already tried:

• self-updating composer and then running composer update
• re-migrating and re-seeding
• going back to a previous commit where I know it has to work, because our online version of the game has that commit as last commit and works fine.
• rebooting my pc
• checking if I had any errors on my wamp php extensions, php error log, apache modules or apache error log. No errors whatsoever.
• I looked at my laptop where the same site is installed, but there for some magical reason it is also broken
• deleted cache (php artisan cache:clear)
• pulling out all of my hair and screaming in agony

lol

I have just figured out what the problem was for me: A while back I changed the cookie session lifetime (app/config/session.php 'lifetime' variable) from this: 'lifetime' => 120,

to this: 'lifetime' => (time() + 60 * 60 * 24 * 365), // one year

I wanted users to login once and then keep their login active for a year, regardless of closing the browser or anything like that. (of course logging out should end it)

I changed it back to 120 and it works fine again. My guess is that the session cookie could not renew itself for some weird reason when I use the time() function to calculate the timestamp of today. It certainly was not a year ago that I made this change, so the calculation is false nevertheless.

Hope this helps someone out there.

Cheers!