[5.5] Set current user before firing authenticated event

[imbrish]

When SessionGuard retrieves currently authenticated user it stores the instance only after handling the Authenticated event. This leads to an infinite loop if any event handler happens to call Auth::user().

This PR fixes the described problem. It also makes the behavior of SessionGuard::user() method consistent with SessionGuard::setUser(), in which user instance is stored before firing the event.

[themsaid]

This looks ok to me

[sisve]

One behavior change is that you could previously throw exception in the authenticated/login events, and the user wouldn't be logged in. This new logic means the user is logged in ($this->user is set) even if an authenticated/login event threw an exception. The workaround would be to encapsulate the logic in a try/catch and set $this->user = $oldValue; if an exception is thrown. Note that it has to be the old value of $this->user, before the try/catch, not null. The old behavior of the user() method would leave $this->user unchanged until everything has succeeded.

[themsaid]

@sisve I thought of that but couldn't think of it as breaking since the user is already logged in, the event is just declaring this fact so it's expected that a user is authenticated when the authenticated event is fired.

[imbrish]

@sisve, I don't see why someone would choose this method of verifying session/cookies. It is also beyond me in what circumstances you would juggle between multiple authenticated users during a single request.

If you throw an exception then request is over anyway. If you catch it... that's a pretty weird if for me.