After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 678611 - Authentication requests cannot be cancelled
Authentication requests cannot be cancelled
Status: RESOLVED FIXED
Product: gcr
Classification: Core
Component: General
3.4.x
Other Linux
: Normal normal
: ---
Assigned To: GNOME keyring maintainer(s)
GNOME keyring maintainer(s)
3.6.1
Depends on:
Blocks: 682830 684478
 
 
Reported: 2012-06-22 09:04 UTC by Milan Crha
Modified: 2019-02-22 11:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gcr: Make the mock prompter's response handling more extensible (3.44 KB, patch)
2012-09-21 08:27 UTC, Stef Walter
committed Details | Review
gcr: Always specify the context for 'running' prompts (950 bytes, patch)
2012-09-21 08:27 UTC, Stef Walter
committed Details | Review
gcr: Remove the waiting field in the system prompt CallClosure (1.28 KB, patch)
2012-09-21 08:27 UTC, Stef Walter
committed Details | Review
gcr: Add prompt-close action signal to GcrPrompt (4.66 KB, patch)
2012-09-21 08:27 UTC, Stef Walter
committed Details | Review
gcr: Implement prompt-close in GcrPromptDialog (4.80 KB, patch)
2012-09-21 08:27 UTC, Stef Walter
committed Details | Review
gcr: Implement prompt-close in GcrSystemPrompt and GcrSystemPrompter (22.96 KB, patch)
2012-09-21 08:27 UTC, Stef Walter
none Details | Review
gcr: Implement prompt-close in GcrSystemPrompt and GcrSystemPrompter (24.01 KB, patch)
2012-10-12 19:19 UTC, Stef Walter
committed Details | Review

Description Milan Crha 2012-06-22 09:04:10 UTC
When I get an authentication request (a password prompt) and my try_password_sync takes long, then the authentication request window disables all its widgets and shows a nice spinning circle in "Continue" button, but, as it disables all the widgets in the window, the prompt cannot be cancelled if it takes too long (imagine a user making a typo in a host name, or the destination host is temporarily unavailable).

Is there anything we can do with it?
Comment 1 Matthew Barnes 2012-06-22 12:02:49 UTC
Reassigning to gnome-keyring / gcr.

Sounds like you're seeing Gcr's built-in GcrPromptDialog, which I think would be the case if you're not running GNOME Shell (e.g. fallback mode, XFCE, etc.).  I believe I've noticed this myself.  Closing the window through the window manager control doesn't seem to have the desired cancellation effect (or else I'm just handling it wrong).
Comment 2 Stef Walter 2012-06-28 14:31:21 UTC
Hmmm, thinking about how to solve this. As a UI experience here's what we want (and have):

 * Only one prompt is displayed at a time (whether via gnome-shell or the
   dialog).
 * An application creates a prompt object which asks for a password or something
   like that, and then until it closes that prompt object the prompt remains
   displayed.
 * This is so that we can then display messages like 'password invalid' and ...
 * But more importantly so that prompts from multiple applications are not
   interleaved. Hope that makes sense.

So what we can do obviously is keep the the cancel button sensitive, and have it send the appropriate "PromptDone" signal back to the applications GcrPrompt object. 

But from there I'm wondering how to relay that information back to the application. Should there be a "closed" signal on GcrPrompt, and then perhaps have a gcr_prompt_cancel_on_close (GcrPrompt *prompt, GCancellable *cancellable);
Comment 3 Matthew Barnes 2012-06-28 15:59:33 UTC
(In reply to comment #2)
> But from there I'm wondering how to relay that information back to the
> application. Should there be a "closed" signal on GcrPrompt, and then perhaps
> have a gcr_prompt_cancel_on_close (GcrPrompt *prompt, GCancellable
> *cancellable);

Apparently I assumed gcr_prompt_password() would return NULL with no error set.

http://git.gnome.org/browse/evolution-data-server/tree/libebackend/e-authentication-session.c#n534

Can't remember if that was a guess or if I actually observed that behavior.  Documentation wasn't clear about that scenario.
Comment 4 Matthew Barnes 2012-06-28 16:07:20 UTC
A better solution might be to define a GError code for password prompt cancellations (E-D-S uses the term "dismissal" so as not to confuse with cancellations from a GCancellable).
Comment 5 Stef Walter 2012-06-28 16:09:01 UTC
No, this is *between* calls to gcr_prompt_password() and such. The prompt remains displayed until the GcrPrompt object is unreffed (or gcr_system_prompt_close()).
Comment 6 Matthew Barnes 2012-06-28 17:02:33 UTC
Maybe stash the aforementioned GError internally to be returned immediately on the next gcr_prompt_password() call for the cancelled GcrPrompt.  If the next call is gcr_system_prompt_close(), forget the error and return success.
Comment 7 Stef Walter 2012-09-20 11:00:43 UTC
(In reply to comment #6)
> Maybe stash the aforementioned GError internally to be returned immediately on
> the next gcr_prompt_password() call for the cancelled GcrPrompt.  If the next
> call is gcr_system_prompt_close(), forget the error and return success.

This won't work. The point is to cancel and close the prompt immediately. Not wait for the next call to gcr_prompt_password(), which doesn't solve the problem.
Comment 8 Stef Walter 2012-09-21 08:27:12 UTC
Created attachment 224902 [details] [review]
gcr: Make the mock prompter's response handling more extensible

 * So that we can handle closing of prompts in later commits
 * Also makes it more predictable as to which context the response
   is sent from.
Comment 9 Stef Walter 2012-09-21 08:27:18 UTC
Created attachment 224903 [details] [review]
gcr: Always specify the context for 'running' prompts

 * Don't automatically use the thread context, unless that's what
   was passed to run_closure_begin().
Comment 10 Stef Walter 2012-09-21 08:27:21 UTC
Created attachment 224904 [details] [review]
gcr: Remove the waiting field in the system prompt CallClosure

 * This field wasn't being used for anything.
Comment 11 Stef Walter 2012-09-21 08:27:28 UTC
Created attachment 224905 [details] [review]
gcr: Add prompt-close action signal to GcrPrompt

 * This signal is fired when the prompt is closed, regardless of
   whether that closure was initiated by the user, or by the the
   application.
 * Add a gcr_prompt_close() method to fire this signal.
 * After closing a prompt the prompt should not display any further
   password or confirm prompts to the user.
Comment 12 Stef Walter 2012-09-21 08:27:31 UTC
Created attachment 224906 [details] [review]
gcr: Implement prompt-close in GcrPromptDialog

 * When the dialog is closed, fire the prompt-close signal and
   close the dialog.
Comment 13 Stef Walter 2012-09-21 08:27:34 UTC
Created attachment 224907 [details] [review]
gcr: Implement prompt-close in GcrSystemPrompt and GcrSystemPrompter

 * Properly relay the prompt-close signal from GcrSystemPrompter
   back to GcrSystemPrompt by firing the PromptDone callback method
   on the caller's DBus interface.
 * Make sure GcrSystemPrompt emits prompt-close appropriately for
   all the various paths that can close the prompt.
 * Add testing of the above, and changes in the mock prompter for this.
Comment 14 Stef Walter 2012-09-21 08:29:01 UTC
With these changes you can g_signal_connect_after with the prompt-close signal on GcrPrompt. In the signal handler you call g_cancellable_cancel() on the GCancellable passed to method 'trying out' the password.
Comment 15 Matthias Clasen 2012-09-21 13:09:53 UTC
We should address this for 3.6.1, I'd say.
Comment 16 Stef Walter 2012-10-12 19:19:56 UTC
Created attachment 226349 [details] [review]
gcr: Implement prompt-close in GcrSystemPrompt and GcrSystemPrompter

 * Properly relay the prompt-close signal from GcrSystemPrompter
   back to GcrSystemPrompt by firing the PromptDone callback method
   on the caller's DBus interface.
 * Make sure GcrSystemPrompt emits prompt-close appropriately for
   all the various paths that can close the prompt.
 * Add testing of the above, and changes in the mock prompter for this.
Comment 17 Stef Walter 2012-10-22 14:13:39 UTC
Comment on attachment 224902 [details] [review]
gcr: Make the mock prompter's response handling more extensible

Committed to gcr 3.7.x
Comment 18 Stef Walter 2012-10-22 14:13:44 UTC
Comment on attachment 224903 [details] [review]
gcr: Always specify the context for 'running' prompts

Committed to gcr 3.7.x
Comment 19 Stef Walter 2012-10-22 14:13:53 UTC
Comment on attachment 224904 [details] [review]
gcr: Remove the waiting field in the system prompt CallClosure

Committed to gcr 3.7.x
Comment 20 Stef Walter 2012-10-22 14:13:57 UTC
Comment on attachment 224905 [details] [review]
gcr: Add prompt-close action signal to GcrPrompt

Committed to gcr 3.7.x
Comment 21 Stef Walter 2012-10-22 14:14:02 UTC
Comment on attachment 224906 [details] [review]
gcr: Implement prompt-close in GcrPromptDialog

Committed to gcr 3.7.x
Comment 22 Stef Walter 2012-10-22 14:14:05 UTC
Comment on attachment 226349 [details] [review]
gcr: Implement prompt-close in GcrSystemPrompt and GcrSystemPrompter

Committed to gcr 3.7.x