Challenge #1 of 1

In our app, we're using the entity user provider:

security
    # ...
    providers:
        app_user_provider:
            entity:
                class: App\Entity\User
                property: email

In theory, could we design a security system that never actually called any methods on our user provider?

Yes: If you used a "stateless" firewall (one that doesn't store the user in the session between requests) and passed a custom user loader in your authenticator (like we are).

No: At the very least, the user provider is needed to "refresh" the user on every request.

No: The user provider is used in various spots. For example, the web debug toolbar uses it to tell us who is logged in.

Rewatch Video

TRACK

Symfony 5 >

COURSE

Symfony 5 Security: Authenticators >

CHAPTER

Authentication Success & Refreshing the User

Challenge #1 of 1

Q:
In our app, we're using the `entity` user provider:

`security # ... providers: app_user_provider: entity: class: App\Entity\User property: email`

In theory, could we design a security system that never actually called any methods on our user provider?

TRACK

Symfony 5 >

COURSE

Symfony 5 Security: Authenticators >

CHAPTER

Authentication Success & Refreshing the User

Challenge #1 of 1

Q: In our app, we're using the entity user provider: security # ... providers: app_user_provider: entity: class: App\Entity\User property: email In theory, could we design a security system that never actually called any methods on our user provider?

Q:
In our app, we're using the `entity` user provider:

`security # ... providers: app_user_provider: entity: class: App\Entity\User property: email`

In theory, could we design a security system that never actually called any methods on our user provider?