[security] serialize the user, again #24731
Comments
|
The I agree that it should be simplified, but there's one thing you can do already: https://stovepipe.systems/post/decoupling-your-security-user |
|
Yes that's the blog I was talking about and what I'm doing, but if it is the only solution to have a proper login system it should be on the official doc... I don't know about my FQCN, I'm not doing any fancy things, just a user with some relations. :( |
|
What about introduce to TokenSerializerInterface like that interface TokenSerializerInterface {
public function serialize(TokenInterface $token): mixed
public function unserialize(mixed $data): TokenInterface
public function supports(TokenInterface $token): bool
}
class StandardTokenSerializer implements TokenSerializerInterface {
public function serialize(TokenInterface $token): mixed
{
return serialize($token);
}
public function unserialize(mixed $data): TokenInterface
{
return unserialize($data);
}
public function supports(TokenInterface $token): bool
{
return $token instanceof \Serializable
}
}
class MyTokenSerializer implements TokenSerializerInterface {
public function __construct(UserRepository $repository)
{
$this->repository = $repository
}
public function serialize(TokenInterface $token): mixed
{
if (!$token instanceof UserPasswordToken) { throw new UnsupportedToken() }
return $token->getUser()->getId();
}
public function unserialize(mixed $data): TokenInterface
{
return new UserPasswordToken($this->repository->find($data));
}
public function supports(TokenInterface $token): bool
{
return $token instanceof UserPasswordToken
}
}
class JWTTokenSerializer .... |
|
No workarounds serializer interfaces etc, the only proper solution is what @iltar is suggesting. |
fabpot
added a commit
that referenced
this issue
Jan 8, 2018
…t be unserialized from the session (thewilkybarkid) This PR was merged into the 2.7 branch. Discussion ---------- [Security] Fail gracefully if the security token cannot be unserialized from the session | Q | A | ------------- | --- | Branch? | 2.7 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | | License | MIT | Doc PR | If the security token in the session can't be unserialized, an `E_NOTICE` is issued. This prevents it (and provides a better log message if it's not even a `__PHP_Incomplete_Class`). This is similar to #24731, but I saw it triggered when changing OAuth library (elifesciences/journal#824), so the token class itself no longer exists. (I want to avoid having to manually invalidate all sessions, as not all sessions use that token class.) Commits ------- 053fa43 [Security] Fail gracefully if the security token cannot be unserialized from the session
6 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
One more time I have a "Class __PHP_Incomplete_Class has no unserializer" thanks to security component. It is probably caused by a doctrine relation, the security component wants to serialize a proxy or something, I don't know.
However I implemented \Serializable on my User, and serialize only the ID, so why implement serializable seems completely useless ?
As the doc say, This may or may not be needed depending on your setup, but it's probably a good idea. not very clear...
I still have to do a special object like SecurityUser to log my users, and have to surcharge "user" service, etc... and this solution is not in SF docs (but in some blogs).
After all those years, this serialize thing has always been a balls breaker thing to me. Could you try to simplify it ? Une fois pour toute qu'on en parle plus !
The text was updated successfully, but these errors were encountered: