[
https://issues.apache.org/jira/browse/ISIS-2727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Keir Haywood updated ISIS-2727:
--------------------------------------
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]*
was:
[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}}.
* 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
* 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]*
> Expose minimal InteractionFactory in the applib, to create new
> InteractionLayers. Perhaps this is an extension of SudoService ?
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISIS-2727
> URL: https://issues.apache.org/jira/browse/ISIS-2727
> Project: Isis
> Issue Type: New Feature
> Components: Isis Core
> Affects Versions: 2.0.0-M5
> Reporter: Daniel Keir Haywood
> Assignee: Daniel Keir Haywood
> Priority: Major
> Fix For: 2.0.0-M6
>
>
> [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]*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
