Re: [DISCUSS] Mapping internal roles to external ones (web.xml and API)

[Michael Osipov <mi...@apache.org>]

Am 2020-01-28 um 22:56 schrieb Mark Thomas:
> On 28/01/2020 21:50, Christopher Schultz wrote:
>> Michael,
>>
>> On 1/28/20 3:51 PM, Michael Osipov wrote:
>>> Am 2020-01-25 um 12:13 schrieb Mark Thomas:
>>>> On 23/01/2020 10:29, Michael Osipov wrote:
>>>>
>>>> <snip/>
>>>>
>>>>> Design questions: * Shall this remain a listener or do we want
>>>>> to introduce a new interface for that? If yes, how should it
>>>>> look like?
>>>>
>>>> Given the use cases (could apply at various levels) a
>>>> LifecycleListener looks like a reasonable design choice to me.
>>>>
>>>> I don't see the need for an additional interface (although I
>>>> could be persuaded if someone else makes an argument for one)
>>>>
>>>>> * Where can this element be placed? Only in context.xml? Also
>>>>> in server.xml? If yes, at which level are contexts available to
>>>>> be modified? Can this be placed in server.xml at all?
>>>>
>>>> LifecycleListener can be placed on most elements so it gives
>>>> plenty of flexibility.
>>>>
>>>>> If it remains as a listener, I would be willing to donate my
>>>>> listener to the Tomcat codebase and add support for file:// or
>>>>> other stuff required.
>>>>
>>>> Fantastic. Thank you. Take a look at the ConfigFileLoader. All
>>>> Tomcat config should be loaded through that.
>>>>
>>>>>  From my understanding, the mapping source can be arbitrary:
>>>>> inline, database, file, etc.
>>>>
>>>> Agreed.
>>
>>> Great, I will pick this up next month and have a look how the
>>> ConfigFileLoader works. I hope I can cover at least all current
>>> cases.
>>
>>> I wonder now which of the components implementing Container should
>>> be subject to this listener?
>>
>>> Engine, Host, Context? Context is trivial, but the rest? They
>>> start before the contexts, I cannot simply say Host#findChildren()
>>> at CONFIGURE_START_EVENT. It does not make sense logically.
>>
>>> At the moment the Context seems to be the only viable place unless
>>> the mappings are held in memory unless all contexts load and query
>>> them. This would require to change the Container interface.
>>
>>> Comments?
>>
>> I think this only makes sense at the <Context> level because the
>> security-roles are all defined at the context-level as well. They may
>> be shared across a bunch of applications, but that's just a coincidence.
>>
>> Mapping this across multiple <Context>s won't be a huge burden, given
>> the other options.
>>
>> Another option might be to allow a LifecycleListener to attach some
>> information to a <Host> (not sure where that might be) and then you
>> can have /another/ LifecycleListener attached to the <Context>. The
>> global one defines the mapping but doesn't actually take any action.
>> The <Context>-attached LifecycleListener then looks-up the tree to
>> parent components looking for the mappings, and applies them as the
>> context is being deployed.
>>
>> Seems more work than necessary, though. Just have admins bless each
>> <Context> and be done with it.
> 
> You can add something to a host and then have it do something every time
> a child (i.e. Context) is added. Looking at the code for MapperListener
> might give you some ideas of the sort of thing you can do.

This is basically what I have assumed to be done. I will go with the 
simplest approach first: context-only.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org