\BackendAuth::getUser() returns null, even in \App::before(){}


I have an error with few users.

This: $user = \BackendAuth::getUser(); is returning null inside the boot() function in my Plugin.php.

Searching for a solution, i’ve come across to put the function in \App:before(){}.

It works for some people and for other, it doesn’t (create an 500 error).

The same account on my computer will work but on another computer, it doesn’t.

Here is my code:

public function boot() {

 \App::before(function() { 
public function extendContactController() {

        ContactController::extend(function($controller) {

            if (!$controller instanceof \Author\Plugin\Controllers\Contacts) {

            $user = \BackendAuth::getUser();

            if ($user->role) {
                $code = $user->role->code;
                if ($code == 'er_regular') {
                    $controller->listConfig = '$/author/plugin/controllers/contacts/config_list_er.yaml';
            } else {
                $controller->listConfig = '$/author/plugin/controllers/contacts/config_list_general.yaml';

How can I make sure \BackendAuth::getUser() returns the logged user in the backend.


This may need to be

if ($user && $user->role) {

I agree but this is not the problem here.

The user is logged (he was in the backend, I’ve saw it) - so \BackendAuth::getUser(); shouldn’t return null.

@daft look this thread:

You wrote;

I think the Session is generally considered to be unavailable inside Service Provider/Plugin register and boot methods. This is because it fires very early in the life cycle.

Maybe consider using App::before(function() { /* ... */ }); to wrap the logic, the session should be available inside this event.

This is what I did but it doesn’t seems to work. Any ideas ? I have some code that I can’t move inside the controller directly because it’s not my plugins.

The code itself is fine. The advice in that ticket still applies today, using App::before will indeed defer until after the session has been activated.

The session requires cooperation from the browser and the server. If it works for some users and not others, we can reasonably determine it is some browsers not playing ball.

Check to make sure that the session cookie is accepted by the browser. Without this cookie, the getUser method will return null, even if they have signed in successfully.

I hope this helps.

1 Like

Thanks, I’ll start to dig deeper into that direction and do more tests.

Update: clearing both, the cache + cookies, did the job. So… if BackendAuth::getUser() returns null, you might want to do this…

1 Like

Above was not actually a permanent solution.

The issue was :

Using this link without “www”, BackendAuth::getUser() will return the user :


Using this link with “www”, BackendAuth::getUser() will return null :


The reason and how to solve it ? (copy paste of chatGPT but it did work in my application) :

The issue you’re experiencing with the difference in behavior between the links “https://mywebsite/intranet/author/plugin/controller/update/3752” and “https://www.mywebsite/intranet/author/plugin/controller/update/3752” could be related to session management or cookie settings.

When a user visits a website, their browser stores session information and cookies related to that particular domain. The “www” prefix is considered a subdomain, and cookies set on the main domain (without the “www” prefix) may not be accessible or recognized by the subdomain.

In your case, it’s possible that the session data or authentication cookies required for retrieving the logged-in user are not accessible when accessing the application with the “www” prefix. As a result, the \BackendAuth::getUser() method returns null.

To resolve this issue, you should ensure that your session configuration and cookie settings are consistent across the main domain and its subdomains. Specifically, check the SESSION_DOMAIN setting in your Laravel configuration (config/session.php) and make sure it is set to the appropriate value. For example, you may need to set it to .mywebsite.com (note the leading dot) to allow cookies and session data to be shared across subdomains.

Additionally, double-check your web server configuration to ensure that requests to both the “www” and non-www versions of your domain are correctly handled and routed to the same application instance.

By aligning the session configuration and ensuring consistent cookie accessibility, you should be able to retrieve the logged-in user regardless of whether the “www” prefix is present in the URL.

Hopefully this help! @daft let me know if you have any comments

UPDATE #322 lol

Some users still experience the issue, even after cleaning the cookies on their browser, it’s weird…

Hey @apinard

Likely your sessions are different between hostnames. The best bet is to redirect to a single hostname so everyone shares the same session domain.

1 Like