I do believe your assumption is correct.
> On Oct 28, 2013, at 2:51 AM, "mailingl...@j-b-s.de" <mailingl...@j-b-s.de>
> wrote:
>
> Hi Lenny
>
> Thanks for your answer. I guess my description was somehow incomplete...
>
> OnActivate from the "unauthorized" page is not called, that's surprising to
> me.
>
> The user has permission to view the page in general but misses certain
> functionality permissions triggered by event callback methods. My initial
> failure was to show such event links at all, but that's a different story...
>
> Nevertheless its still possible to enter such a link URL directly in the
> browser, but luckily in this case everything works as expected (redirect to
> "unauthorized" page and onActivate from the unauthorized page gets called)
>
> As the only difference is "zone/ajax" related, I guess shiro does not handle
> XHR requests correctly when rendering/redirecting, but this just an
> assumption. I have to dig deeper in the shiro source
>
> Jens
>
> Von meinem iPhone gesendet
>
>> Am 27.10.2013 um 14:44 schrieb Lenny Primak <lpri...@hope.nyc.ny.us>:
>>
>> I don't think Tapestry-Security works for Ajax requests.
>> I think it's geared more of blocking access to pages for initial load.
>> How can you have AJAX requests for a page that's not authorized?
>> Also, in Tapestry 5.4, this should be handled properly by way T5.4 handles
>> JavaScript.
>>
>> onActivate isn't getting called because Tapestry-Security / Shiro intercepts
>> it (and denies it's permission)
>> before onActivate ever gets called.
>>
>>> On Oct 27, 2013, at 8:55 AM, Jens Breitenstein wrote:
>>>
>>> Hi all!
>>>
>>> I have a strange problem and maybe one of you can give me a hint...
>>>
>>> Basically I have a table and each individual <tr> forms it's own zone and
>>> can be replaced independently from each other by an eventlink (works
>>> perfectly).
>>> Next I added @RequiresPermissions("MyPermission:modify") on the
>>> event-callback method to limit access. In case an user does not have the
>>> required permissions Shiro correctly identfies it and throws an
>>> OperationException("Subject does not have permission"), perfect too.
>>> Unfortunately there is no redirect to the "Unauthorized" page but instead
>>> the page is rendered in the "ajax dialog box" (which tapestry shows in case
>>> of problems/errors).
>>>
>>> From the stacktrace I see
>>> "SecurityExceptionHandlerAssistant.handleRequestException" is called to
>>> retrieve the page name to show ("Unauthorized"). Unfortunately there is no
>>> redirect to the page but instead "renderer.renderPageResponse(page)" is
>>> called and surprisingly "onActivate" of my "Unauthorized" page is not
>>> called at all.
>>>
>>> Any idea what happens and how to solve it?
>>>
>>>
>>> Jens
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
