[Freeipa-devel] [PATCH] 710 webui: review pending operation after expired session

[Petr Vobornik]

On 25.7.2014 22:26, Endi Sukma Dewata wrote:
> On 7/23/2014 8:16 AM, Petr Vobornik wrote:
>> Disable automatic re-execution of command after pending authentication.
>>
>> It's possible to enable it again globally by
>> 'freeipa/config':`rpc_retry_auth`.
>>
>> https://fedorahosted.org/freeipa/ticket/4374
>>
>> # Additional info:
>> This ticket is in 4.0 stabilization milestone. I don't think it's the
>> best fit. It has a potential to break things. It's also harder to test
>> because integration tests don't test it - one has to remove session
>> cookie every time and then react appropriately.
>>
>> It's also first usage of ./config module (other items there are not
>> used). This module was originally implemented to contain global webui
>> config which could be overwritten by config configured on server, ie for
>> disabling paging in large deployments. The server part doesn't exist
>> yet. Other reason is to split ipa.js into more single-purpose files.
>
> It works a little bit differently than expected.
>
> Right now suppose I'm trying to delete a user, I have the delete dialog
> open and I let it sit until the session expires, then when I click
> Delete it will show me a login screen. Once I re-login, the dialog box
> is gone. It still has the user to be deleted selected, but there's no
> indication what the operation I was trying to do before.
>
> I was thinking the session expiration would work like desktop
> screensaver lock. So when I re-login I would see same screen as I left
> it, i.e. the delete dialog is still waiting for action.
>

Components have not been made with this feature in mind. Take for 
example the delete issue. Deleter dialog is a subclass of confirm 
dialog. Confirm dialog is closed right after confirmation/cancellation. 
It doesn't wait for the result of the operation because it's handled by 
other components. The behavior was OK so far because we showed error 
dialog on "normal" error. On auth error, the command was re-executed. 
Now we don't show any error on auth error nor we leave the dialog open. 
Seems like that we should change all usages of confirm dialog to try to 
do the operation first and close the dialog after the operation was 
successful or canceled. But this is only one set of use cases. There 
might/will be others we don't know about atm.

Proper solution is to test all Web UI features (or feature sets) with 
expired session (deletion of cookie) and identify the issues. Then 
address the identified issues - much bigger task then this simple patch. 
I think it is not good to push this patch without fixing the issues and 
definitely not into stabilization release (4.0).

I propose to move this ticket into 4.1 or maybe even 4.2. Fix other 
tickets in the milestone and then return to this one. I'm giving it 
lower priority because I didn't see many people complaining about 
current behavior.


> The patch itself is fine, so it's ACKed, but I'll let you decide if this
> is sufficient to close the bug.
>

I'll postpone the push until solution for the issue above is made.

-- 
Petr Vobornik