Re: [evolution-patches] Patch for suppressing multiple password prompts in Calendar

[Rodrigo Moya <rodrigo novell com>]

On Thu, 2004-06-17 at 00:49 +0800, Not Zed wrote:
> 
> Ok so here's the basic idea I had, it is very simple (not compiled/
> etc, so no idea if it works).  This is more or less what the mail code
> does.  It should handle the case of a concurrently-used ccad, i think.
> its kinda late and i'm not that familiar with the whole code though.
> 
this is more or less what I suggested to Harish (keeping a list of the
accounts to be authenticated). It fixes the problem in Harish's patch,
that only works for a single GW account.

cheers

> The volatile keyword is because auth_queue is used inside a loop, to
> force it to memory each time it changes rather than any optimisations
> that might be made, since the code is multithreaded.  I think this is
> the right way to do it.
> 
> The locking is kinda fugly too ...
> 
> static volatile GSList *auth_queue;
> static pthread_mutex_t auth_mutex = PTHREAD_MUTEX_INITIALIZER;
> static volatile guint auth_idle_id;
> 
> static gboolean
> async_auth_idle_cb (gpointer data)
> {
> 	pthread_mutex_lock(&auth_mutex);
> 	while (auth_queue) {
> 		GSList *head = auth_queue;
> 		ECalAsyncData *ccad = head->data;
> 
> 		auth_queue = g_slist_remove_link(auth_queue, head);
> 		g_slist_free1(head);
> 		pthread_mutex_unlock(&auth_mutex);
> 
> 		g_mutex_lock (ccad->mutex);
> 		ccad->password = ccad->real_auth_func (ccad->ecal, ccad->auth_prompt, ccad->auth_key, ccad->real_auth_user_data);
> 		g_cond_signal (ccad->cond);
> 		g_mutex_unlock (ccad->mutex);
> 
> 		pthread_mutex_lock(&auth_mutex);
> 	}
> 
> 	auth_idle_id = 0;
> 	pthread_mutex_unlock(&auth_mutex);
> 
> 	return FALSE;
> }
> 
> static char *
> async_auth_func_cb (ECal *ecal, const char *prompt, const char *key, gpointer user_data)
> {
> 	ECalAsyncData *ccad = user_data;
> 	char * password;
> 
> 	ccad->auth_prompt = prompt;
> 	ccad->auth_key = key;
> 
> 	pthread_mutex_lock(&auth_mutex);
> 	password_queue = g_slist_append(password_queue, ccad);
> 	if (auth_idle_id == 0)
> 		auth_idle_id = g_idle_add ((GSourceFunc) async_auth_idle_cb, NULL);
> 	pthread_mutex_unlock(&auth_mutex);
> 
> 	g_mutex_lock (ccad->mutex);
> 	g_cond_wait (ccad->cond, ccad->mutex);
> 	password = ccad->password;
> 	ccad->password = NULL;
> 	g_mutex_unlock (ccad->mutex);	
> 
> 	return password;
> }
> 
> 
> 
> On Mon, 2004-06-14 at 22:04 +0530, Harish Krishnaswamy wrote: 
> > The patch below suppresses multiple password prompts for GroupWise
> > accounts in the Calendar component and is a fix for the bug #59386.
> > 
> > The Calendar source and the task source of a GroupWise account share the
> > same authentication tokens. The calendar component initiates the
> > asynchronous creation of a cal source as well as a task source (Task
> > summary in the Calendar view) in the same thread. (The gtk_main_loop
> > thread invokes the authentication callback function). 
> > This patch sets up the async_gw_auth_idle_cb function that delays the
> > authentication call for the second source till the first has had the
> > chance to obtain the password.
> > (This function can be used by any backend which provides both calendar
> > and task services as part of a single account).
> > 
> > harish
> > 
> > Index: ChangeLog
> > ===================================================================
> > RCS file: /cvs/gnome/evolution-data-server/calendar/ChangeLog,v
> > retrieving revision 1.290
> > diff -u -p -r1.290 ChangeLog
> > --- ChangeLog	14 Jun 2004 05:53:23 -0000	1.290
> > +++ ChangeLog	14 Jun 2004 16:19:04 -0000
> > @@ -1,4 +1,10 @@
> >  2004-06-14  Harish Krishnaswamy  <kharish novell com>
> > +	
> > +	* libecal/e-cal.c: (async_gw_auth_idle_cb), (async_auth_func_cb):
> > +	Fixes #59386. The calendar component for GW does not prompt for
> > +	password twice (for calendar and todo items).
> > +
> > +2004-06-14  Harish Krishnaswamy  <kharish novell com>
> >  
> > 
> >  	* backends/groupwise/e-cal-backend-groupwise-utils.c:
> > Index: libecal/e-cal.c
> > ===================================================================
> > RCS file: /cvs/gnome/evolution-data-server/calendar/libecal/e-cal.c,v
> > retrieving revision 1.68
> > diff -u -p -r1.68 e-cal.c
> > --- libecal/e-cal.c	2 Jun 2004 16:15:00 -0000	1.68
> > +++ libecal/e-cal.c	14 Jun 2004 16:19:05 -0000
> > @@ -1589,6 +1589,34 @@ typedef struct {
> >  } ECalAsyncData;
> >  
> >  static gboolean
> > +async_gw_auth_idle_cb (gpointer data)
> > +{
> > +	ECalAsyncData *ccad = data;
> > +	static gboolean authenticating = FALSE;
> > +	static gboolean cancelled = FALSE;
> > +
> > +	/* Check if Calendar authentication is already in progress */
> > +	if (!authenticating) {
> > +		/* If calendar authentication had been cancelled, 
> > +		 * todo authentication is considered cancelled as well. */
> > +		if (cancelled)
> > +			return FALSE;
> > +		authenticating = TRUE;
> > +		g_mutex_lock (ccad->mutex);
> > +		ccad->password = ccad->real_auth_func (ccad->ecal, ccad->auth_prompt,
> > ccad->auth_key, ccad->real_auth_user_data);
> > +		if (!ccad->password)
> > +			cancelled = TRUE;
> > +		g_cond_signal (ccad->cond);
> > +		g_mutex_unlock (ccad->mutex);
> > +		authenticating = FALSE;
> > +		return FALSE;
> > +	}
> > +	else 
> > +		return TRUE; /* this would cause the idle thread to be called again
> > and provide
> > +			      a chance for calendar authentication to be completed. */
> > +}
> > +
> > +static gboolean
> >  async_auth_idle_cb (gpointer data)
> >  {
> >  	ECalAsyncData *ccad = data;
> > @@ -1629,7 +1657,10 @@ async_auth_func_cb (ECal *ecal, const ch
> >  	ccad->auth_prompt = prompt;
> >  	ccad->auth_key = key;
> >  
> > -	g_idle_add ((GSourceFunc) async_auth_idle_cb, ccad);
> > +	if (!strncmp (ecal->priv->uri, "groupwise://", strlen
> > ("groupwise://")))
> > +		g_idle_add ((GSourceFunc) async_gw_auth_idle_cb, ccad);
> > +	else
> > +		g_idle_add ((GSourceFunc) async_auth_idle_cb, ccad);
> >  		
> >  	g_mutex_lock (ccad->mutex);
> >  	g_cond_wait (ccad->cond, ccad->mutex);
> > 
> > _______________________________________________
> > evolution-patches mailing list
> > evolution-patches lists ximian com
> > http://lists.ximian.com/mailman/listinfo/evolution-patches
> -- 
> 
> Michael Zucchi <notzed ximian com>
> 
> Ximian Evolution and Free Software
> Developer