可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试):

问题:

I am developing web application using Laravel 5 and angularJs with RESTFUL apis.

Using middleware to authentication purpose. My problem is after sending few request simultaneously,system automatically logged out and sending 401 exception from laravel side.

API base controller:

class ApiController extends BaseController {

    use DispatchesCommands, ValidatesRequests;

    function __construct() {
        $this->middleware('api.auth');
    }

}

Middleware:

class APIMiddleware {

    /**
     * Handle an incoming request.
     *
     * @param  Request  $request
     * @param  Closure  $next
     * @return mixed
     */
    public function handle($request, Closure $next) {
        if (!Auth::check()) {
            abort(401, "Unauthorized");
        }
        return $next($request);
    }

}

public function login(LoginRequest $request) {
    if (Auth::check()) {
        Auth::logout();
    }

    if (Auth::attempt(['email' => $request->input('email'), 'password' => $request->input('password')], $request->input('is_remember'))) {
        return array(true);
    } else {
        abort(401, "Invalid email & password");
    }
}

After few request gone, Server log out and sends 401 exception. I am stuck with this issue.

回答1:

Now I'm not 100% sure (and depending on your set-up I can't even say I'm 90% sure) But after changing my session_driver from file to database I seem to have fixed this issue - that is if it's the same issue.

I think do the samething as you with my app - that is on a start up of a page, I'm making 6 request (this is development and I will be changing it to one so please don't cry). If I load this page, it works with about 3 or 4 request, then the other 2-3 come back with a unauthorised response. It also only happens on request that require middleware => auth.

So here's my theory to why this is happening: Because, by default, sessions are saved in a file - making multiple requests at once means that file is being opened 6 times at once - probably messing it up (depending on your machine). Therefore changing the session to a database, which is designed to have thousands of requests at once, works!

SOLUTION:

Go to your .env file and change SESSION_DRIVER=file to SESSION_DRIVER=database.
Next you will need to create a session migration: php artisan session:table.
Now composer dump-autoload for good practice.
Finally migrate (php artisan migrate).

NOTE: I'm not 100% sure though if this is the case, but for me this solution worked. I am also aware that this question is really old, but both the developers I work with and myself have had this issue and there doesn't seem to be a solution, so Just though I'd post this.

回答2:

It may be a problem that you are accessing the user variable illegally. Please use Auth::check() before accessing Auth::user() This seems to work for my project. Optionally you can try for changing the session driver from .env file.

回答3:

Managed to figure it out.. Since i use laravel for pretty much all my projects, I forgot to change the session name, as a result, one session was overwriting the other, causing the auto-loggout.. So if you have multiple laravel projects running, make sure they all have different session names. Hope this helps someone in future ! Here is a Laracast thread on this issue.

For me this was the process to solve the problem:

Cleared my browser's cookies for localhost.
Changed value of cookie key in app/session.php.
Ran php artisan config:clear.

回答4:

Might be useful for someone: Had the very same problem. I've changed the cookie name in session settings. By default it is laravel_session, so try setting it to something else

回答5:

I solved the same issue by clearing cache using php artisan cache:clear and also running composer dump-autoload. Hope this works for you.

回答6:

I had a similar problem this week. I have a server with multiple Laravel applications. One application was logging the other out.

The problem had to do with session management. The session name was the same for all the applications. Changing it would be enough to avoid different applications conflict. However, I can have different instances of the same application in the server (for testing purposes, for example). So, changing only the session name would not be enough.

To solve my problem properly, I used the session path to make the configuration unique per instance. In the config/session.php, I defined something like this:

'cookie' => 'systemx_session',
'path' => parse_url(env('APP_URL', 'http://localhost'), PHP_URL_PATH),

I use the parse_url function with the environment variable APP_URL because my server has the instances deployed under something like http://example.com/systemx.

I hope this helps someone who might end up having the same kind of problem.