8000 Security: User provider is mandatory, even if I don't need it. · Issue #21998 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content

Security: User provider is mandatory, even if I don't need it. #21998

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jkufner opened this issue Mar 14, 2017 · 5 comments
Closed

Security: User provider is mandatory, even if I don't need it. #21998

jkufner opened this issue Mar 14, 2017 · 5 comments
Assignees

Comments

@jkufner
Copy link
jkufner commented Mar 14, 2017
Q A
Bug report? maybe
Feature request? maybe
BC Break report? no
RFC? no
Symfony version 3.2.5

I use custom authentication which stands on tokens without users. Therefore, I don't use UserProvider. But configuration loader requires me to provide at least one user provider.

Please make user provider optional. When some component asks for user from user provider, it should crash, so I know there is something wrong.

@Nek-
Copy link
Contributor
Nek- commented Mar 14, 2017

@jkufner

As I understand it's not a bug but something mandatory that may not be.

Also it's present in any version of Symfony as it's a "missing feature". Right ?

@jkufner
Copy link
Author
jkufner commented Mar 14, 2017

Well… it's hard to tell. I updated the Q/A table.

It is a bug in a sense that I cannot use authenticator which don't use users, but there is nothing really broken. It is just an unnecessary constraint.

@xabbuh xabbuh added this to the 3.x milestone Mar 15, 2017
@robfrawley
Copy link
Contributor

"There is nothing really broken. It is just an unnecessary constraint." LMFTFY:

Q A
Bug report? no
Feature request? yes

@curry684
Copy link
Contributor

If this part is being refactored I'd suggest taking it larger, as a lot of Symfony's configuration in this area is pretty outdated in practice. When implementing APIs or external authentication mechanisms I commonly have implementations of UserInterface around that are not about users at all, and have a ton of empty methods around that are not relevant.

The UserProvider/UserInterface subsystem is geared far too much towards the classical user/password website login, and hence also stem 'weirdish' things like the one mentioned here with a UserProvider being mandatory.

@jkufner
Copy link
Author
jkufner commented Mar 20, 2017

Exactly. As far as I understand, there is no need for UserProvider unless AuthenticationListener requires one. When a different paradigm is used for authentication, this entire UserProvider infrastructure is not used at all.

Firewall and AuthenticationListeners are fine and generic enough. Tokens are a bit confusing and there is an unnecessary bound to sessions, but thats for another story. Questionable is the rest of the infrastructure above the AuthenticationListeners. So, let's make UserProviders optional. It would allow us to build a new lighter and simpler infrastructure while keeping the old one in place until the new is ready.

@chalasr chalasr self-assigned this Jul 19, 2017
@chalasr chalasr removed this from the 3.4 milestone Oct 2, 2017
@fabpot fabpot closed this as completed Apr 19, 2018
fabpot added a commit that referenced this issue Apr 19, 2018
This PR was squashed before being merged into the 4.1-dev branch (closes #26787).

Discussion
----------

[Security] Make security.providers optional

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #21998
| License       | MIT

Don't really know if it's viable but I just hit #21998 so I would like to tackle this.

Commits
-------

ee54bfa [Security] Make security.providers optional
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants
0