Hi,
On Mon, Mar 16, 2015 at 6:02 PM, Werner Keil <werner.keil_at_gmail.com> wrote:
> What feels a bit unusual about it, is it doesn't use CDI events, but
> "SecurityEvent" and others seem "plain old" java.util.EventObject.
>
It are in fact events usable by CDI.
Hooking into the associated source events is container specific now, but in
Undertow I have experimental code that throws it like this:
CDI.current().getBeanManager().fireEvent(new LoggedOutEvent(notification,
notification.getAccount().getPrincipal()));
And in test code I observe those events via CDI as follows:
@SessionScoped
public class SessionAuthListener implements Serializable {
public void onAuthenticated(@Observes AuthenticatedEvent event) {
if (user == null ||
!event.getUserPrincipal().getName().equals(user.getName())) {
user = userService.getActiveUser(); // just an example, can be anything
}
}
public void onLoggedOut(@Observes LoggedOutEvent event) {
user = null;
}
}
See
http://jdevelopment.nl/bridging-undertows-authentication-events-cdi
I'm not really sure why they wouldn't qualify as CDI events. AFAIK CDI can
fire any plain types, which can then be observed. Of course the specific
event types used here are not set in stone, and they could have a no-arg
ctor and you could use qualifiers etc, but I'm not sure if that would make
them "more" CDI then the current ones.
I choose "plain old" java.util.EventObject as the base class basically as
analogy to JSF, see e.g.
https://docs.oracle.com/javaee/7/api/javax/faces/event/PreRenderViewEvent.html
It's not strictly necessary perhaps to have the EventObject base class.
Those event types where introduced to experiment with them and to use them
for the
http://jdevelopment.nl/bridging-undertows-authentication-events-cdi
article.
> Except for the name SocialEvent, similar functionality in Agorava (what
> you mentioned about Apache 2.0 is similar here) looks like this:
> https://github.com/agorava/agorava-core/tree/develop/agorava-core-api/src/main/java/org/agorava/api/event
> Using CDI Events (just like the examples described here:
> http://docs.oracle.com/javaee/6/tutorial/doc/gkhpa.html)
>
> Some of the code uses libraries from "RedBrick.org" which is then
> forwarded to http://www.3pillarglobal.com.
> Do you own these external dependencies, too?;-)
>
Nope, this is a different external project that is not owned by me. Only
the SocialServerAuthModule uses this dependency, which is an authentication
module that can basically use any social authentication provider to login,
but delegates to socialauth which abstracts social network specifics and
the OAuth1 and OAuth2 protocols among others. Obviously this dependent
library can not be contributed and neither can it be re-licensed.
Furthermore there's some patched social auth code in
https://github.com/omnifaces/omnisecurity/tree/master/src/main/java/org/omnifaces/security/socialauth
that can not be re-licensed either, but this too is only used by the
SocialServerAuthModule.
Too make it a bit clearer I was thinking of moving the
SocialServerAuthModule to a separate project, but I hadn't found the time
for that yet.
Kind regards,
Arjan Tijms
>
> Cheers,
> Werner
>
> On Mon, Mar 16, 2015 at 5:41 PM, arjan tijms <arjan.tijms_at_gmail.com>
> wrote:
>
>> Hi,
>>
>> On Mon, Mar 16, 2015 at 11:01 AM, David Blevins <dblevins_at_tomitribe.com>
>> wrote:
>>
>>> Scoured the JIRAs in an attempt to pull out the code snippets used in
>>> all the JIRAs.
>>>
>>
>> Nice, thanks! ;)
>>
>>
>> A while back I started an experimental project that contains a lot of
>> things that are basically prototypes for the Java EE security issues I
>> created or still intend to create: See http://omnisecurity.omnifaces.org
>>
>> For example, here I tried out some code for a "remember me" function that
>> can work with all kinds of authentication mechanisms:
>>
>>
>> https://github.com/omnifaces/omnisecurity/blob/master/src/main/java/org/omnifaces/security/jaspic/wrappers/RememberMeWrapper.java
>>
>>
>> And this is a base class for HTTP authentication modules, that (IMHO)
>> greatly simplifies the existing very general interface:
>>
>>
>> https://github.com/omnifaces/omnisecurity/blob/master/src/main/java/org/omnifaces/security/jaspic/core/HttpServerAuthModule.java
>>
>>
>> Here's a stateless token authentication module which I showed before:
>>
>>
>> https://github.com/omnifaces/omnisecurity/blob/master/src/main/java/org/omnifaces/security/jaspic/authmodules/TokenAuthModule.java
>>
>>
>> Here's a utility method that makes it really easy to programmatically
>> register an auth module:
>>
>>
>> https://github.com/omnifaces/omnisecurity/blob/master/src/main/java/org/omnifaces/security/jaspic/core/Jaspic.java#L319
>>
>>
>> Here two simple authentication events and a base class for them:
>>
>>
>> https://github.com/omnifaces/omnisecurity/tree/master/src/main/java/org/omnifaces/security/events
>>
>> etc etc
>>
>> The overarching idea of this code is that it does not try to reinvent the
>> wheel, but provides ease of use abstractions on top of existing APIs.
>>
>> Everything in this repo can be contributed to the security jsr if needed,
>> and re-licensed if needed (it currently uses Apache 2.0).
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>
>>> I do my best thinking in my editor rather than email. It's also
>>> significantly faster for me to use the IDE in presentations rather than
>>> pull code and put into slides.
>>>
>>> - https://github.com/dblevins/javaee-security-proposals
>>>
>>> Let me know your Github ID and I'll add you. Found a few of you already
>>> and added.
>>>
>>>
>>> Side note, I did grab the `javaee-security-spec` org on Github just to
>>> make sure someone in the EG had it.
>>>
>>> - https://github.com/javaee-security-spec
>>>
>>> Didn't open it up as I don't want to step on toes.
>>>
>>>
>>> --
>>> David Blevins
>>> http://twitter.com/dblevins
>>> http://www.tomitribe.com
>>> 310-633-3852
>>>
>>>
>>
>