Well, I solved my issue with this, although it wasn’t easy. I ended
up switching to Jetty. The problem was two things, Spring Security isn’t
capable of protecting comet connections on Tomcat since it doesn’t have a
filter that implements CometFilter. Switching to Jetty fixed this since it
doesn’t have any such thing. Also, the AsyncDispatcher will likely interrupt
Spring Security’s SecurityContext since I had to disable that on Jetty.
From: Kevin Jordan
[mailto:kevin.jordan@xteconline.com]
Sent: Thursday, February 11, 2010 4:34 PM
To: 'Mike Brock'
Cc: 'errai-users@lists.jboss.org'
Subject: RE: [errai-users] Errai Authentication
What is it that makes it not possible for me to do this? I
assume that another Thread is spawned for the @Service since the POST that
executes it is able to close. Why am I not able to access the parent
thread data (i.e. the web server thread where the Spring Security data lives)
via an InheritedThreadLocal?
From: Mike Brock
[mailto:cbrock@redhat.com]
Sent: Thursday, February 11, 2010 11:49 AM
To: Kevin Jordan
Cc: errai-users@lists.jboss.org
Subject: Re: [errai-users] Errai Authentication
Ah yes, that's definitely a bug. I'll fix that
immediately (rules not being applied to RPC endpoints).
I'll think about what I can do with the SessionProvider
stuff to make it easier to expose these things as needed.
Mike.
On 2010-02-11, at 12:27 PM, Kevin Jordan wrote:
Yes. I was trying to avoid having to pass the username to
the server when it should already know it.
And actually I guess @RequiredAuthentication might be working,
just on a regular @Service implementing MessageCallback, but not for RPC.
From: Mike Brock
[mailto:cbrock@redhat.com]
Sent: Thursday, February
11, 2010 10:43 AM
To: Kevin Jordan
Cc: errai-users@lists.jboss.org
Subject: Re: [errai-users]
Errai Authentication
You've implemented an AuthenticationAdapter for
SpringSecurity?
There's really no way of doing it unless you were to
implement your own SessionProvider... even then you could only copy in
information from the HTTPSession.
Party of the reason we separated these concerns so
aggressively was so we could run ErraiBus in something like Netty... without a
Servlet container. I'm certainly open to ideas as to how we can improve
this situation to satisfy a case like yours.
On 2010-02-11, at 11:29 AM, Kevin Jordan wrote:
Any ideas why I wouldn’t be able to access Spring Security
information from inside it? It uses ThreadLocal (http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ThreadLocal.html?is-external=true)
for access to the session/login information. I also tried making it use
an InheritableThreadLocal (http://java.sun.com/j2se/1.5.0/docs/api/java/lang/InheritableThreadLocal.html)
holder strategy for the SecurityContext seen below, but it doesn’t seem to be
able to get it through that either.
From: Mike Brock
[mailto:cbrock@redhat.com]
Sent: Thursday, February 11,
2010 8:16 AM
To: Kevin Jordan
Cc: errai-users@lists.jboss.org
Subject: Re: [errai-users]
Errai Authentication
It *should* be enforcing @RequireAuthentication and @RequireRoles
... let me look into it on my side.
On 2010-02-10, at 1:43 PM, Kevin Jordan wrote:
I’m
wondering how authentication works (or is supposed to work) in Errai. It
seems from what I can gather, you’re supposed to use doAuthentication in the
SecurityService, however, even if my custom AuthenticationAdapter does nothing
as it currently does (I was curious to see if I could get Spring Security
authentication information using it to pass it on since I can’t seem to in my
services, which I can’t in there either), but nothing calls isAuthenticated or
anything related to it later on even if I have @RequireAuthentication or
@RequireRoles on my services. In fact, it lets me call the services even
though as far as I think Errai knows, it should have no authentication
principals or roles. Is Authentication incomplete at this point in
time? At this time, I’m not requiring/needing the annotations, but I do
want to get my login information from Spring Security. I
would normally do it in the context of a servlet or jsp as:
try {
SecurityContext context = SecurityContextHolder.getContext();
Object principal = null;
User user = null;
if (context != null) {
Authentication auth = context.getAuthentication();
if (auth != null) {
principal = auth.getPrincipal();
if (principal instanceof User) {
user = (User) principal;
logger.info(user.getUsername());
} else {
logger.debug("Principal is null or not a User");
}
} else {
logger.debug("No authentication");
}
} else {
logger.debug("No context");
}
} catch (Exception e) {
logger.error("Error", e);
}
However,
that doesn’t seem to work, probably because it can’t access the ThreadLocal
since I’m assuming most things in Errai, especially services, get a new
Thread? Is there any way for me to access the remote user from the
servlet? I doubt services get a link to the requesting servlet, correct?
_______________________________________________
errai-users mailing list
errai-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-users