You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Michael Osipov <mi...@apache.org> on 2020/01/23 10:29:06 UTC
[DISCUSS] Mapping internal roles to external ones (web.xml and API)
Folks,
I'd like to discuss the architecture of BZ 55477 [0], this shall apply
to Tomcat 8.5+ only.
The feature has been requested several times over time years, being able
to map some technical role from a specific store to an application role.
E.g., A group SID from AD
'S-1-5-21-126432666-1270913926-3679153413-372575' to role 'User'.
What do we have now?
* org.apache.catalina.Context.addRoleMapping(String, String) can be
called to establish such a link
* org.apache.catalina.Context.findRoleMapping(String) queries for such a
link
My recent changes to the codebase make RealmBase and Wrapper fully
support Context#findRoleMapping(). So, it will work automatically.
What do we need?
* Something which must not be tied to the realm as described in [1] and [2]
* Some extension point to inject/call Context#addRoleMapping()
I have solved this problem for us at work years ago with a listener [3].
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?
* 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?
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.
From my understanding, the mapping source can be arbitrary: inline,
database, file, etc.
[0] https://bz.apache.org/bugzilla/show_bug.cgi?id=55477
[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=55477#c14
[2] https://bz.apache.org/bugzilla/show_bug.cgi?id=55477#c15
[3]
http://mo-tomcat-ext.sourceforge.net/xref/net/sf/michaelo/tomcat/extras/listeners/PropertiesRoleMappingListener.html
Please bear with me since I am a slow responder.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [DISCUSS] Mapping internal roles to external ones (web.xml and
API)
Posted by 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
Re: [DISCUSS] Mapping internal roles to external ones (web.xml and API)
Posted by Rémy Maucherat <re...@apache.org>.
On Wed, Jan 29, 2020 at 5:26 PM Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Mark,
>
> On 1/28/20 4:56 PM, Mark Thomas wrote:
> > 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.
>
> Oh, that's interesting.
>
I also added a FrameworkListener in the core package to be able to go crazy
with listeners. It was based on the ThreadLocalLeakPreventionListener which
was a better example than MapperListener (it works too, but it does too
much and is too complex to be a good example).
Rémy
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4xsi0ACgkQHPApP6U8
> pFhXnxAAmrMtnIlzzsFEu1ihLXsogf7XuZ3hpOZH7VY90Zhn3p2aLvLcACCFvjOc
> +/ClAvddQbQtA/RVn65y1NLuTQeUtttlaeDAUWbh/iWcDo+wniNAlsPidesWHCAN
> kgxGDzOZyFH30HO16gJfb4dcWFTm/h15o0Ur7cL15Z4/NMGVZP9G3en9crH40qBW
> 7vSzbBm5j2wFM6jjsFd8lSqTeV+JK4NtiWXqb1nCkSZDJDzreJOpQcUjYoMaYWqw
> Ut5YLL35ukuph7rry/erfjM84BvT87U/mf1ZjLSs6YmZgbGrQ7/Yw95263j9Td0b
> bECMEkJnqBprDt/b5LPesMs48D3JTUdAluHTI0BzKa9Qsk8Ypsuy6dkB3A7oHgop
> 6I/Ry5LSZmkQt2HIQPody0TOiCHCYrdQMQtwgiyK5zOtl1v/L/sUKmw71K+wNwOh
> TjW+ZKaPNbZ7lwHDhgBG4cM2soycPge8euiyJZ1JHp4Tf7/7zUarnoohfKPUtgGP
> YWnXzcD99azoS5tohlFsZm+Gj3CYs46f01uQx0BqusC4YEUiYT3IYTyQqlGpSNs5
> uCijLZZXLuwdzUWaFanOEKsmPKrgN13ZTCxvO67vPygOs3OSz5lO+UzEgbYu5SEg
> LN55Uqs1H/Le8n/+9PpZyETr8GEOPy1E9rvN0kTxbFpIlVKWd8k=
> =Vo/x
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: [DISCUSS] Mapping internal roles to external ones (web.xml and
API)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 1/28/20 4:56 PM, Mark Thomas wrote:
> 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.
Oh, that's interesting.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4xsi0ACgkQHPApP6U8
pFhXnxAAmrMtnIlzzsFEu1ihLXsogf7XuZ3hpOZH7VY90Zhn3p2aLvLcACCFvjOc
+/ClAvddQbQtA/RVn65y1NLuTQeUtttlaeDAUWbh/iWcDo+wniNAlsPidesWHCAN
kgxGDzOZyFH30HO16gJfb4dcWFTm/h15o0Ur7cL15Z4/NMGVZP9G3en9crH40qBW
7vSzbBm5j2wFM6jjsFd8lSqTeV+JK4NtiWXqb1nCkSZDJDzreJOpQcUjYoMaYWqw
Ut5YLL35ukuph7rry/erfjM84BvT87U/mf1ZjLSs6YmZgbGrQ7/Yw95263j9Td0b
bECMEkJnqBprDt/b5LPesMs48D3JTUdAluHTI0BzKa9Qsk8Ypsuy6dkB3A7oHgop
6I/Ry5LSZmkQt2HIQPody0TOiCHCYrdQMQtwgiyK5zOtl1v/L/sUKmw71K+wNwOh
TjW+ZKaPNbZ7lwHDhgBG4cM2soycPge8euiyJZ1JHp4Tf7/7zUarnoohfKPUtgGP
YWnXzcD99azoS5tohlFsZm+Gj3CYs46f01uQx0BqusC4YEUiYT3IYTyQqlGpSNs5
uCijLZZXLuwdzUWaFanOEKsmPKrgN13ZTCxvO67vPygOs3OSz5lO+UzEgbYu5SEg
LN55Uqs1H/Le8n/+9PpZyETr8GEOPy1E9rvN0kTxbFpIlVKWd8k=
=Vo/x
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [DISCUSS] Mapping internal roles to external ones (web.xml and
API)
Posted by Mark Thomas <ma...@apache.org>.
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [DISCUSS] Mapping internal roles to external ones (web.xml and
API)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4wrKwACgkQHPApP6U8
pFjKxw/7BNjDmsU1BHXUqEXbyxKcpHsP3x+iz++ECzkFiSse2kfSff018KSsqjYk
nosqP9TVTGbFA/7UV94TBNY8s2UbzN+bJAOveLweIU1CPTo8bcI9lpBwnnGezBci
PBMhw7BtAOcf9rCrSTZQSOeU1AkGHvoF+ikMfoqPGdbm0vbV9PJWZwcTbM/ILM9Q
jKkbZPTnaQyKmoJWZnMiJaa+JnzhJebCmQljQI+6E7r9mH2XixBiExG0ZljwwU8c
HvpObmOy/rjibUeR2XUZ/QtRYoBVWEBBa8dvysr63m9t9Vrz5kqMDUMkdSloc/6i
8I4/ZQWZ0FHjfM/3KB+Ng0L5rXzmeD6zasyTW6QTOQ9y9Uk+7EsGo9dCB+ei2yWv
3/PP0rTurt5/KycUKKUxHnTLPeYZ/RM62FPruxjmGhIy9MVpltTc22dLeTWgIEpg
Ztcc+tNAEkZ6WKNYMGiCUQkhh/LlZjgIWTqdq+GEFETzFVukekqjmqp32PUMZS8P
apAGiPvvzPzpRzJnxbB0hDQqFMd6uNpMVIQfZwfLJ9Ja1qLXak3NItwg87doYazj
tUYFofam73LIJ0CbIC2maIRInIP9+OfNVEZfZQTkCIZn4onb+MY8VKM5U3Z/41mt
xI6ewxcaxoX3pJ7I+BP3A8yxj2+nbMMz36Q9J+cWwEUNUoNcRco=
=1DpC
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [DISCUSS] Mapping internal roles to external ones (web.xml and
API)
Posted by Michael Osipov <mi...@apache.org>.
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?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [DISCUSS] Mapping internal roles to external ones (web.xml and API)
Posted by Rémy Maucherat <re...@apache.org>.
On Sat, Jan 25, 2020 at 12:13 PM Mark Thomas <ma...@apache.org> wrote:
> 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.
>
I can easily make that change later, the API is rather new so it's ok if
people don't want to write the code for it.
>
> > From my understanding, the mapping source can be arbitrary: inline,
> > database, file, etc.
>
> Agreed.
>
Rémy
>
>
> >
> > [0] https://bz.apache.org/bugzilla/show_bug.cgi?id=55477
> > [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=55477#c14
> > [2] https://bz.apache.org/bugzilla/show_bug.cgi?id=55477#c15
> > [3]
> >
> http://mo-tomcat-ext.sourceforge.net/xref/net/sf/michaelo/tomcat/extras/listeners/PropertiesRoleMappingListener.html
> >
> >
> > Please bear with me since I am a slow responder.
> >
> > Michael
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: [DISCUSS] Mapping internal roles to external ones (web.xml and
API)
Posted by Mark Thomas <ma...@apache.org>.
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.
Mark
>
> [0] https://bz.apache.org/bugzilla/show_bug.cgi?id=55477
> [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=55477#c14
> [2] https://bz.apache.org/bugzilla/show_bug.cgi?id=55477#c15
> [3]
> http://mo-tomcat-ext.sourceforge.net/xref/net/sf/michaelo/tomcat/extras/listeners/PropertiesRoleMappingListener.html
>
>
> Please bear with me since I am a slow responder.
>
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org