[cdi-dev] CDI security release around the corner

Mark Struberg struberg at yahoo.de
Mon Aug 13 15:40:24 EDT 2018


Right, no API signature got changed etc.
The only change was doing some parts in a doPrivileged block. 
It's really just a security bugfix release. 

It's imo perfectly fine since the API is usually provided by the container and user projects only have it as <scope>provided</scope> in their projects.
So it's really mostly important for container vendors.

LieGrue,
strub


> Am 10.08.2018 um 18:22 schrieb Werner Keil <werner.keil at gmail.com>:
> 
> Antoine/all,
> 
> It seems, the security release is already out:
> https://search.maven.org/artifact/javax.enterprise/cdi-api/2.0.SP1/jar
> 
> Was there no structural change to the API so not calling it MR1 as none was filed or voted on according to JCP.org?
> 
> How does CDI plan to evolve? It is currently not under Jakarta EE, so do you plan to file a new JSR for CDI 2.1 (unless it is small enough to be a MR) or 3.0 via the JCP?
> 
> Regards,
> Werner 
> 
> On Mon, Jul 16, 2018 at 10:11 AM <cdi-dev-request at lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
>         cdi-dev at lists.jboss.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
>         cdi-dev-request at lists.jboss.org
> 
> You can reach the person managing the list at
>         cdi-dev-owner at lists.jboss.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Portable decorable Bean<T> instances (arjan tijms)
>    2. Re: Portable decorable Bean<T> instances (Martin Kouba)
>    3. CDI security release around the corner (Antoine Sabot-Durand)
>    4. [JBoss JIRA] (CDI-732) Clarify that the Context for
>       RequestScoped must be active during @PreDestroy calls
>       (Mark Struberg (JIRA))
>    5. [JBoss JIRA] (CDI-732) Clarify that the Context for
>       RequestScoped must be active during @PreDestroy calls
>       (Romain Manni-Bucau (JIRA))
>    6. [JBoss JIRA] (CDI-730) The order in which contexts are
>       destroyed is undefined. (Mark Struberg (JIRA))
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 10 Jul 2018 12:45:12 +0100
> From: arjan tijms <arjan.tijms at gmail.com>
> Subject: Re: [cdi-dev] Portable decorable Bean<T> instances
> To: Matej Novotny <manovotn at redhat.com>
> Cc: cdi-dev at lists.jboss.org
> Message-ID:
>         <CAE=-AhD9wr1B-pC8BfpY7RA3CwHDKPBd-nsejwZn4__0+mv3yw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi,
> 
> Thanks for the reply. I already feared that to be the answer.
> 
> This would probably be a good enhancement request for CDI 2.1. At the very
> least the BeanConfigurator could have a method like
> BeanConfigurator#setDecorators<Decorator<?>... decorators. That's seemingly
> doable to implement by the CDI implementations.
> 
> Kind regards,
> Arjan
> 
> 
> 
> 
> 
> On Tue, Jul 10, 2018 at 11:04 AM Matej Novotny <manovotn at redhat.com> wrote:
> 
> > Hi,
> >
> > yes, there is no portable way.
> > It is a similar situation as was with interceptors before
> > InterceptionFactory was added.
> >
> > [impl 'details']
> > In principle, to implement this, you need to create a "wrapper class"
> > around the object which is to be intercepted/decorated.
> > If you provide a custom way to create the bean, it is very difficult to
> > create this wrapper on-the-fly.
> > Even the solution for interceptors has some shortcomings and flaws and
> > decorators seem even more complex (less restrictions on how does a
> > decorator look like).
> >
> > Matej
> >
> > ----- Original Message -----
> > > From: "arjan tijms" <arjan.tijms at gmail.com>
> > > To: cdi-dev at lists.jboss.org
> > > Sent: Tuesday, July 10, 2018 11:30:54 AM
> > > Subject: [cdi-dev] Portable decorable Bean<T> instances
> > >
> > > Hi,
> > >
> > > When adding a manually constructed Bean<T> instance using
> > > AfterBeanDiscovery.addBean(Bean<?>), or using the
> > > AfterBeanDiscovery.addBean() method and the BeanConfigurator, the
> > resulting
> > > bean can't be decorated.
> > >
> > > This is because seemingly CDI expects the create() method of Bean<T> to
> > > locate the decorators itself and apply them to the instance it returns.
> > >
> > > Using BeanManager.resolveDecorators one can obtain the Decorator<T>
> > > instances, but am I right that there's no portable way to actually apply
> > > those decorators to the bean instance?
> > >
> > > Kind regards,
> > > Arjan
> > >
> > >
> > >
> > > _______________________________________________
> > > cdi-dev mailing list
> > > cdi-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/cdi-dev
> > >
> > > Note that for all code provided on this list, the provider licenses the
> > code
> > > under the Apache License, Version 2
> > > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> > > provided on this list, the provider waives all patent and other
> > intellectual
> > > property rights inherent in such information.
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20180710/df6ec1f4/attachment-0001.html 
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 10 Jul 2018 14:46:23 +0200
> From: Martin Kouba <mkouba at redhat.com>
> Subject: Re: [cdi-dev] Portable decorable Bean<T> instances
> To: arjan tijms <arjan.tijms at gmail.com>, Matej Novotny
>         <manovotn at redhat.com>
> Cc: cdi-dev at lists.jboss.org
> Message-ID: <229cfa79-b39b-af5b-bc75-757085270acf at redhat.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Dne 10.7.2018 v 13:45 arjan tijms napsal(a):
> > Hi,
> > 
> > Thanks for the reply. I already feared that to be the answer.
> > 
> > This would probably be a good enhancement request for CDI 2.1. At the 
> > very least the BeanConfigurator could have a method like 
> > BeanConfigurator#setDecorators<Decorator<?>... decorators. That's 
> > seemingly doable to implement by the CDI implementations.
> 
> Well, it's not that simple. In order to make decorators work the 
> instance produced by Bean#create(CreationalContext<T>) must be proxied, 
> decorated types only include interfaces, etc.
> 
> There are few issues related to this topic. I'd suggest to walk through 
> all those issues, close duplicates and outdated issues and create a new 
> one with distilled summary...
> 
> > 
> > Kind regards,
> > Arjan
> > 
> > 
> > 
> > 
> > 
> > On Tue, Jul 10, 2018 at 11:04 AM Matej Novotny <manovotn at redhat.com 
> > <mailto:manovotn at redhat.com>> wrote:
> > 
> >     Hi,
> > 
> >     yes, there is no portable way.
> >     It is a similar situation as was with interceptors before
> >     InterceptionFactory was added.
> > 
> >     [impl 'details']
> >     In principle, to implement this, you need to create a "wrapper
> >     class" around the object which is to be intercepted/decorated.
> >     If you provide a custom way to create the bean, it is very difficult
> >     to create this wrapper on-the-fly.
> >     Even the solution for interceptors has some shortcomings and flaws
> >     and decorators seem even more complex (less restrictions on how does
> >     a decorator look like).
> > 
> >     Matej
> > 
> >     ----- Original Message -----
> >      > From: "arjan tijms" <arjan.tijms at gmail.com
> >     <mailto:arjan.tijms at gmail.com>>
> >      > To: cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
> >      > Sent: Tuesday, July 10, 2018 11:30:54 AM
> >      > Subject: [cdi-dev] Portable decorable Bean<T> instances
> >      >
> >      > Hi,
> >      >
> >      > When adding a manually constructed Bean<T> instance using
> >      > AfterBeanDiscovery.addBean(Bean<?>), or using the
> >      > AfterBeanDiscovery.addBean() method and the BeanConfigurator, the
> >     resulting
> >      > bean can't be decorated.
> >      >
> >      > This is because seemingly CDI expects the create() method of
> >     Bean<T> to
> >      > locate the decorators itself and apply them to the instance it
> >     returns.
> >      >
> >      > Using BeanManager.resolveDecorators one can obtain the Decorator<T>
> >      > instances, but am I right that there's no portable way to
> >     actually apply
> >      > those decorators to the bean instance?
> >      >
> >      > Kind regards,
> >      > Arjan
> >      >
> >      >
> >      >
> >      > _______________________________________________
> >      > cdi-dev mailing list
> >      > cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
> >      > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >      >
> >      > Note that for all code provided on this list, the provider
> >     licenses the code
> >      > under the Apache License, Version 2
> >      > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
> >     ideas
> >      > provided on this list, the provider waives all patent and other
> >     intellectual
> >      > property rights inherent in such information.
> > 
> > 
> > 
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> > 
> > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
> > 
> 
> -- 
> Martin Kouba
> Senior Software Engineer
> Red Hat, Czech Republic
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Wed, 11 Jul 2018 10:10:54 +0200
> From: Antoine Sabot-Durand <asd at redhat.com>
> Subject: [cdi-dev] CDI security release around the corner
> To: CDI Java EE Specification <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CAHTnX=cPEQngop0ASYtu8ge6CLDx+38WcK3pi-z_VtYCOAa3eA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi all,
> 
> As stated a few weeks ago we have worked on issues in CDI API regarding
> security manager.
> 
> 2 PR are currently open [1] [2]. The first one is ready to merge, second
> one need some discussion and possible rework.
> 
> If none of you raise concern about these, I plan to merge these PR and
> release CDI 2.0.SP1 by the end of next week.
> 
> Thanks for your feedback,
> 
> Antoine
> 
> 
> [1] https://github.com/cdi-spec/cdi/pull/390
> [2] https://github.com/cdi-spec/cdi/pull/391
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20180711/217bf5ab/attachment-0001.html 
> 
> ------------------------------
> 
> Message: 4
> Date: Mon, 16 Jul 2018 03:01:00 -0400 (EDT)
> From: "Mark Struberg (JIRA)" <issues at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-732) Clarify that the Context for
>         RequestScoped must be active during @PreDestroy calls
> To: cdi-dev at lists.jboss.org
> Message-ID:
>         <JIRA.12757897.1530531484000.672.1531724460377 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
> 
> 
>     [ https://issues.jboss.org/browse/CDI-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13605259#comment-13605259 ] 
> 
> Mark Struberg commented on CDI-732:
> -----------------------------------
> 
> > It seems logical to first destroy the "shorter-lived" scopes
> 
> Hmm but Welds destroy order according to CDI-730 is
> > At present weld destroys conversation, request, then session context in that order.
> conversation is clearly longer than request. Thus this argument makes no sense. 
> 
> Another point to think about: in CDI the RequestScoped Context is also used as kind of 'ThreadScoped'. For example it is also active in an Asynchronous EJB method, in JBatch threads, etc. 
> 
> So even if the Session gets destroyed outside of a HTTP Request (e.g. via timeout), then we could start a RequestContext, perform the @PreDestroy method and stop if afterwards. 
> 
> > Clarify that the Context for RequestScoped must be active during @PreDestroy calls
> > ----------------------------------------------------------------------------------
> >
> >                 Key: CDI-732
> >                 URL: https://issues.jboss.org/browse/CDI-732
> >             Project: CDI Specification Issues
> >          Issue Type: Feature Request
> >          Components: Contexts
> >    Affects Versions: 2.0 .Final
> >            Reporter: Mark Struberg
> >
> > We have the explicit rule that the Context for @RequestScoped must be active during @PostConstruct of any bean. 
> > But it seems we don't force the same for invocations of @PreDestroy methods.
> > That's especially weird since a few containers now blow up during a destroyal of a @SessionScopedBean which has a @RequestScoped Principal injected, even if the session destroyal was triggered by an explicit Session#invalidate() call in an open HTTP request.
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v7.5.0#75005)
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Mon, 16 Jul 2018 03:05:00 -0400 (EDT)
> From: "Romain Manni-Bucau (JIRA)" <issues at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-732) Clarify that the Context for
>         RequestScoped must be active during @PreDestroy calls
> To: cdi-dev at lists.jboss.org
> Message-ID:
>         <JIRA.12757897.1530531484000.702.1531724700312 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
> 
> 
>     [ https://issues.jboss.org/browse/CDI-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13605260#comment-13605260 ] 
> 
> Romain Manni-Bucau commented on CDI-732:
> ----------------------------------------
> 
> [~struberg] this doesn't solve the problem correctly IMHO. request = thread scope is an abuse of users but not what is the scope normally. A lot of usages are about request = ... request :). If you think about an audit implementation by request you breaks it if the request scope is not the last one destroyed so I think session should be destroyed before the request in any case. Having 2 instances in the same real servlet request would be very misleading and pretty much unusable at all stages (perf, understanding, impl).
> 
> > Clarify that the Context for RequestScoped must be active during @PreDestroy calls
> > ----------------------------------------------------------------------------------
> >
> >                 Key: CDI-732
> >                 URL: https://issues.jboss.org/browse/CDI-732
> >             Project: CDI Specification Issues
> >          Issue Type: Feature Request
> >          Components: Contexts
> >    Affects Versions: 2.0 .Final
> >            Reporter: Mark Struberg
> >
> > We have the explicit rule that the Context for @RequestScoped must be active during @PostConstruct of any bean. 
> > But it seems we don't force the same for invocations of @PreDestroy methods.
> > That's especially weird since a few containers now blow up during a destroyal of a @SessionScopedBean which has a @RequestScoped Principal injected, even if the session destroyal was triggered by an explicit Session#invalidate() call in an open HTTP request.
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v7.5.0#75005)
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Mon, 16 Jul 2018 04:11:00 -0400 (EDT)
> From: "Mark Struberg (JIRA)" <issues at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-730) The order in which contexts
>         are destroyed is undefined.
> To: cdi-dev at lists.jboss.org
> Message-ID:
>         <JIRA.12756107.1529484750000.1399.1531728660954 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
> 
> 
>     [ https://issues.jboss.org/browse/CDI-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13605310#comment-13605310 ] 
> 
> Mark Struberg commented on CDI-730:
> -----------------------------------
> 
> I understand the argument that the order is really hard to get right.
> But I would love if we could clarify the following:
> 
> * When a request ends, first ALL the @BeforeDestroyed events for the following contexts are sent: RequestScope, ConversationScoped (if context ends), SessionScoped (if session ends)
> * Only after that the proper @PreDestroy methods are called on all those scopes.
> 
> PS: the deferral of the session destroy to the end of the request is a left over of the (failed) Seam2 compatibility mode. It should have never be done that way and really causes tons of problems :(
> In OWB there is even a way to turn this off and make it follow the standard Servlets Sesion lifecycle because it caused so many problems.
> 
> > The order in which contexts are destroyed is undefined.
> > -------------------------------------------------------
> >
> >                 Key: CDI-730
> >                 URL: https://issues.jboss.org/browse/CDI-730
> >             Project: CDI Specification Issues
> >          Issue Type: Clarification
> >    Affects Versions: 2.Future, 1.2.Final, 2.0 .Final
> >            Reporter: Benjamin Confino
> >            Priority: Minor
> >
> > The order in which contexts are destroyed is not defined in the spec, I believe this should be made explicit.
> > At present weld destroys conversation, request, then session context in that order. I think this should become the standard and written into the spec.
> > For background there is this email by Martin Kouba: http://lists.jboss.org/pipermail/weld-dev/2018-June/003694.html
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v7.5.0#75005)
> 
> 
> ------------------------------
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html).  For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
> 
> End of cdi-dev Digest, Vol 89, Issue 2
> **************************************
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.




More information about the cdi-dev mailing list