Announcement Announcement Module
Collapse
No announcement yet.
Accessing username in application context Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Accessing username in application context

    I've got an audit object that is used to audit changes made to other objects. Within that audit object I'd like to have access to the username of the active user, and possibly their list of roles. I'd like to do that withouth tying the audit object to the security library. It seems to me that the right way to do that is to set a property on the audit object using the application context. But I can't figure out if there's an easy way to get at the username within the app context?

    I suppose I could just create an object that does that and is tied to the security scheme and exposes the username as a property. Then I could reference that in the app context. Is there an easier way using just the acegi stuff?

    So, in the app context I'd like to have

    <bean id="audit" class="com.domain.me.Audit">
    <property name="auditedUsername">[stuff that gets current active username here]</property>
    </bean>

    Is this doable? Or am I on the wrong track. I believe that Acegi stores the information in a thread local context, so it should be retrievable.

    Thanks for your help.

    Stephen Owens
    Corner Software

  • #2
    ((SecureContext) ContextHolder.getContext()).getAuthentication();

    If you didn't want that in your audit object, you could write an interface:
    Code:
    public interface CurrentUser &#123;
       public Object getUser&#40;&#41;;
    &#125;
    Then an implementation:
    Code:
    public class CurrentUserAcegiSecurityImpl implements CurrentUser &#123;
       public Object getUser&#40;&#41; &#123;
          return &#40;&#40;SecureContext&#41; ContextHolder.getContext&#40;&#41;&#41;.getAuthentication&#40;&#41;;
       &#125;
    &#125;
    Although I'd wonder whether it was necessary to make this pluggable, as you'd probably cast the returned Object back to Authentication anyway in order to view its roles etc. You could always add an additional method to your interface to achieve that, though. It's really a matter of personal preference.

    Comment


    • #3
      Thanks for the input. I guess that's the way to go then.

      Comment

      Working...
      X