Re: [wicket-atmosphere] Spring Security context while rendering subscribed components

2013-03-18 Thread Emond Papegaaij
Hi,

I'm sorry for the late reply, but I haven't been well last week.
Wicket-atmosphere follows the wicket request cycle. Perhaps you can add a
RequestCycleListener to setup the context? Keep in mind though that this
listener is also called for normal requests. Let me know if this is ok for
you. Another solution would be to add another listener system, but I think
it's better to try to use existing systems before adding another wheel.

Best regards,
Emond
Op 8 mrt. 2013 14:31 schreef Andrei Badea andrei.ba...@movzx.net het
volgende:

 Our Wicket application uses Spring Security for authentication and
 authorization. All service methods check that the current user (in the
 Spring Security context) has the right to execute the method.

 When the subscribed components are rendered for an Atmosphere broadcast,
 the security context is not the right one. We call EventBus.post() in a
 background (non-HTTP) thread, so there is no security context at all (and
 even if it were, its user would not be the right one).

 I can use ResourceRegistrationListener to keep track of the
 resource-UUID-to-user assignment, but I see no way to set the user into the
 security context before the subscribed components are rendered. Is there
 one? If not, it is conceivable to add one, such as some sort of hook to
 EventBus.post()? The security context would ideally be set around
 postToSingleResource(), and it must be reset after all resources have been
 handled.

 Thank you,

 Andrei


 --**--**-
 To unsubscribe, e-mail: 
 users-unsubscribe@wicket.**apache.orgusers-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




[wicket-atmosphere] Spring Security context while rendering subscribed components

2013-03-08 Thread Andrei Badea
Our Wicket application uses Spring Security for authentication and 
authorization. All service methods check that the current user (in the 
Spring Security context) has the right to execute the method.


When the subscribed components are rendered for an Atmosphere broadcast, 
the security context is not the right one. We call EventBus.post() in a 
background (non-HTTP) thread, so there is no security context at all 
(and even if it were, its user would not be the right one).


I can use ResourceRegistrationListener to keep track of the 
resource-UUID-to-user assignment, but I see no way to set the user into 
the security context before the subscribed components are rendered. Is 
there one? If not, it is conceivable to add one, such as some sort of 
hook to EventBus.post()? The security context would ideally be set 
around postToSingleResource(), and it must be reset after all resources 
have been handled.


Thank you,

Andrei


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org