Major Description
https://the-asf.slack.com/archives/CFC42LWBV/p1623056272236700
A fixture script that mocks the clock "just" needs to push an AuthenticationLayer with the desired VirtualClock.
We also need to be able (within the test) to "sudo". This is where we need the ability to create an AuthenticationLayer (we'll rename it to InteractionLayer) on the fly.
Discussion:
some thoughts on how to do this:
- ExecutionContext is already in the applib, though its name is confusing as it suggests it is related to the Interaction.Execution class (it isn't, really) and also the fixtures applib provide FixtureScript.ExecutionContext. Really it acts more like a context for creating an InteractionLayer, so I think it should be called InteractionContext. [DONE]
- That then means that the current InteractionContext - which exposes the Isis applib Interaction to domain apps - then needs to be renamed. I suggest this is called InteractionProvider instead [DONE]
- We promote some small super-interface of InteractionFactory up into the applib. This might allow us to remove the AnonymousInteractionFactory interface that was recently introduced into security.
- Rather than InteractionFactory#openInteraction(...) taking an Authentication, I think it could instead take the (now renamed) InteractionContext which is wrapped by an Authentication. My reasoning is that Authentication is not much more than a wrapper around InteractionContext, so I doubt there is any code that has a hard dependency on Authentication that couldn't be refactored to work with InteractionContext instead. [DONE]
- The responsibilities of Authentication are then to do with ensuring that it is valid (the validation code) and the type (delegated or not etc). Those responsibilities hopefully won't need to leak outside of security, ie Authentication is not used elsewhere, ie other modules just use InteractionContext as mentioned..
Also:
- Rename AuthenticationContext to AuthenticationProvider , as this follows a similar pattern [DONE]