Announcement Announcement Module
No announcement yet.
Remote application using Burlap + ACEGI Page Title Module
Move Remove Collapse
This topic is closed
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Remote application using Burlap + ACEGI


    Now I'm writing remote client application to communicate with server by Burlap. Web services are protected by the ACEGI security framework. As the sample Contacts client application, each time I have to provide the username and password for authentication.

    Questions 1: Will the acegi authenticate the request each time when I calling different services even I have already authenticated? If not, is acegi just use the user id and the Authentication object in the server side to determine the user already login? If not, how to avoid the server to authenticate the user in each service call?

    Question 2: Can I get back the session ID information after login in the client side? Then, can I present it(session id) instead of providing login information again on the next burlap request call like the web browser application?

    Question 3: In my application, we need to implement session management such as we have to force user logout. How can we do it with ACEGI? Do we only need to remove the Authentication object from the Httpsession and remove it from the ContextHolder?



  • #2
    Acegi Security essentially re-authenticates on every Hessian/Burlap request based on the BASIC authentication header. This is because these protocols do not provide a stateful session management solution, so we really have little option. There might be a way, but I am unaware of it. There is negligible performance implication with doing this, as Acegi Security uses caching to avoid hitting expensive (ie AuthenticationDao) backends to evaluate subsequent authentication requests.

    You might prefer to approach the login/logout sequence at an application level. ie not at a security level. At the start of the business application, a "session establishment" method is called, which gives you a workflowId that can be presented on subsequent method invocations. At the end, it calls a "session termination" method. That way all the operations in your business workflow can be associated.

    Now, if you'd really like to use HttpSession etc, my recommendation is to look into Hessian/Burlap at the lower-level of headers and responses. Acegi Security will be only too happy to honour a subsequent jsessionid. Indeed the BASIC authentication model drops the Authentication into HttpSession, so the jessionid representation on a subsequent request will be honoured.

    Alternatively, look into HttpInvoker. There's a good thread,, which demonstrates how flexible HttpInvoker is. In my own experience I have found the Resin protocols have serialization issues and HttpSession does not, although you should of course test with your own application.
    Last edited by robyn; May 19th, 2006, 05:45 AM.