!!! FEATURE: Introduce AccountInterface, Roles API and Account ValueObjects

[sorenmalling]

What I did Introducing a AccountInterface to avoid hardcoding authentication to only a Neos.Flow defined model.

This also opened for a streamlining of the AccountInterface object, so the following ValueObjects was introduced

• AccountIdentifier
• AuthenticationProviderName
• CredentialsSource

How I did it Created a AccountInterface, have the current Account model implement it to keep the backward compatibility.

All possible places we refere to AccountInterface and (string) cast the new ValueObjects

How to verify it

Test it together with the task/adjust-to-account-interface branch of Neos CMS and look at the changes made to the codebase

Resolves #1077

[sorenmalling]

@bwaidelich I will focus on updating the docs once we have the functionality straight . And provide a test package :)

[albe]

Ok, so one big point is still open: How do we deal with the major breakyness of this change right now?

[sorenmalling]

This PR has some conflicts in the meantime. Would you be up for rebasing it to current master?

I will bring it up to date 👍

[bwaidelich]

@sorenmalling anything I can help to bring this one up to date? It would be cool to have the breaking changes in as soon as possible in order to given them some time to "ripe" :)

[sorenmalling]

@bwaidelich Let me spend some time right now to get the conflicts removed and tests green :) Update coming in 1 hour 👍

[sorenmalling]

Conflicts solved via the web ui - will get my local environment up to date again and go through test results from travis and compare to local results 👍

[robertlemke]

Does the CredentialsSource value actually have to be a string?

Right now, there are some authentication providers which set it to something else. For example, the OIDC package uses a JWT object as its credentials source (see code). Sure, that could be serialized, but then would cause some hassle at other ends.

If there's a good reason to force this to a string, let's do that. But let's be sure about that …

[bwaidelich]

Does the CredentialsSource value actually have to be a string?

It has to be representable as a string at least or it could not be persisted as is. $account->setCredentialsSource($someObject) actually only works because the setter is missing a corresponding type hint, the field itself is a string, and since it maps 1:1 to a column in the database, a complex type would break persistence.

Then again, we could of course introduce an interface for the CredentialSource but what methods would you expect there?

[bwaidelich]

As discussed with @sorenmalling we'll try the following next steps:

• remove hasRole() from the AccountInterface and maybe introduce some method to the PolicyService that "expands" an instance of RoleIdentifiers to retrieve all role ids including parent roles
• Adjust core and tests so that they refer to the AccountInterface (or TransientAccount when creating new instances) where possible.
• Mark Account deprecate in favor of a new PersistedAccount that just implements the interface and has proper constructors

[bwaidelich]

Some input from todays session at the Sprint:

• Updated AccountInterface PR coming up for Flow 8
• WIP on moving route mapping to persistent cache instead of database
• Question: Account model without ORM, but DBAL? (or a 3rd one?)
  • Idea: keep the existing Account as is, and create a DBAL "repository" to save/load the immutable one (=> rename it from TransientAccount to s.th. more general)
  • !!! maybe de-importantize the ORM (explain why we want that)