Announcement Announcement Module
Collapse
No announcement yet.
Missing info in case of 403 error. Acegi design issue? Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Missing info in case of 403 error. Acegi design issue?

    I am using Acegi 0.8.2. I have encountered a strange situation.

    I have two types of roles: Sell_Read and Sell_Write. They are designed for 2 types of URLs. One is for displaying records and the other for editing records. See the following:

    \A/sell/viewSell.html\Z= Sell_Read
    \A/sell/editSell.html\Z=Sell_Write

    When a user with Sell_Read role accesses viewSell.html, the user is directed to a 403 page. On this 403 page, there is one piece of information defined as follows:

    <authz:authorize ifAnyGranted="Sell_Read,Sell_Write">
    Invoice: $100.00
    </authz:authorize>

    This piece of information is also available on the pages of the viewSell.html and editSell.html and it does appear when Sell_Read user accesses vewSell.html or Sell_Write user accesses editSell.html.
    However, the same piece of information never gets displayed on the 403 page. What am I missing here? Any workaround?

    There are other situations in which we need to display certain pieces of authorized information. For example, I need to display information about the logged user even in case of 403 error as follows:

    <authz:authentication operation="principal"/>

    However, this piece of information is also missing in case of 403 in my program.

    Not sure whether I did something wrong. I guess the "strange" situation is related to the design of Acegi.

    Thanks in advance for your input.

    Pete

  • #2
    Nobody has similar experiences?

    Thanks.

    Comment


    • #3
      I'd suspect the 403 page isn't having the Acegi Security filters applied, which means the SecurityContextHolder isn't populated. If you switch on DEBUG logging you should see whether the filters are being fired. If they're not being fired, you might need to override SecurityEnforcementFilter so it doesn't send a 403 but redirects to a standard page where the filters will be fired.

      Comment


      • #4
        Ben,

        Thanks so much for the explanation. SecurityContextHolder no being populated in case of 403 is what I was thinking. Thanks for the
        suggested solution!

        Regards,
        Pete

        Comment

        Working...
        X