October: Class auth does not exist

[Whyounes]

Inside my NotesController@store method i'm trying to access the logged in user, but i'm getting Class auth does not exist. I tried to resolve it through the from the container directly (App::make('auth')) but i'm getting the same error.

The only way i can do it is to instantiate the AuthManager directly!!

Can anyone try to reproduce this error and confirm?

Thanks

[Whyounes]

Inside the modules/system/Providers.php, we don't have the AuthServiceProvider, why is that?
Can somebody please explain or this is a bug!!

[daftspunk]

Class Auth is provided by the RainLab.User plugin, is it installed?

[Whyounes]

No, it's not installed.

I'm now using BackendAuth::getUser(), however, i don't think this is the correct way to do it!
is there a better way?

[daftspunk]

BackendAuth will give you the backend user, yes, that's it. The Auth\Manager in the Rain library is a shared/abstract class not really designed to be implemented directly. The backend module and User plugin extend this class.

edit: We have purposefully avoided using the IoC container in many places, we can fall back to this approach if there is an absolute need to do so. The issue relates to managing a scenario where multiple plugins decide to entirely replace the class with their own. i.e

1. Standard IoC says "Use Class A"
2. Plugin 1 says IoC "Use Class B"
3. Plugin 2 says IoC "Use Class C"

Plugin 1 now fails to operate. So extension by events handles this problem far better, and the code is simpler too.

[Whyounes]

I understand the problem, but at least we should stay consistent we can user BackendAuth::user() instead of BackendAuth::getUser(), just to keep things predictable.

[daftspunk]

Consistent to what? I thought most accessors are prefixed with "get".

[Whyounes]

when saying consistent, i mean doing things the Laravel way, and also i'm
not a big fan of set and get.

In your previous comment, you mentioned Extension by events, do you have
some resources where i can clear the ambiguity? thanks :)

i also tweeted to you on @octobercms about putting some of my articles on
octobercms.com/resources!! (of course if you think they are eligible for
that :D)

On Mon, Dec 1, 2014 at 10:12 PM, Samuel Georges [email protected]
wrote:

Consistent to what? I thought most accessors are prefixed with "get".

—
Reply to this email directly or view it on GitHub
https://github.com/octobercms/october/issues/799#issuecomment-65144315.

[daftspunk]

Laravel is inconsistent, it uses get/set more than it goes without. This article explains extension by Events. We will add the articles soon, they are great! Thanks

[frthjf]

Hi, I ran into the same problem when using the jwt-auth package in a plugin.
My routes.php with DingoAPI and JWT looks like this:

\App::register('\Dingo\Api\Provider\LaravelServiceProvider');
\App::register('Tymon\JWTAuth\Providers\JWTAuthServiceProvider'); 

$api->version('v1', function ($api) {
      $api->group( [ 'middleware' => '\Tymon\JWTAuth\Middleware\GetUserFromToken' ], function ($api) {
           $api->resource('foo', 'Bar');
 ....

Then JWTAuth raises the 'Class auth does not exist' exeption. Is there any way how I can register the Auth class of the Rainlab.User plugin, such that JWTAuth makes use of it?

[daftspunk]

The RainLab.User plugin uses this code to do it:

    $alias = AliasLoader::getInstance();
    $alias->alias('Auth', 'RainLab\User\Facades\Auth');

    App::singleton('user.auth', function() {
        return \RainLab\User\Classes\AuthManager::instance();
    });