"A CAPTCHA must be filled out to log in". is the error message in the screenshot - nothing else worth to see.

Cannot open calendar: Unexpected HTTP status code 7 returned (Connection terminated unexpectedly)

Exact steps to reproduce are welcome.

We don't have support for CAPTCHA prompts at the moment.  Gotta go to google.com/calendar and do it.

Unfortunately I don't know how to trigger Google's CAPTCHA.  It happened right after the EDS update, but I actually had it pop up on my Android phone as well earlier in the day (I have never seen on my phone either).  I have not seen it since on either.   

Apparently Google does it when they see unusual traffic patterns, or suspect DNS redirection or traffic interception which some ISPs do from time to time. Maybe a tweak to my squid proxy could make it reproducible.  

I can't reproduce it today using my work connection.  

I believe the message generated was from Glib, and I assume the detection was legitimate based on the fact that I saw it in a similar timeframe on my phone.  

If that Glib message was passed up consistently then the user would at least know what is going on, even if it is not handled.  I couldn't make it go away with my calendar in browser.. and I couldn't find the specific caldav URL evolution was using to test natively for myself (though I know it shows up in the status bar from time to time).  

I believe the captcha being presented is the one below,

https://www.google.com/accounts/UnlockCaptcha 

I tried failing it a few times, but Google still "trusts" me both in evolution and my browser session.  

It seems it only can be used to make the tokens work, not break them to create a test case.

"Once the user has successfully responded to the challenge, the Google server will trust the computer in use. The application can then resend the original login request to obtain the authentication token."

I found this here:
http://code.google.com/googleapps/faq.html#captchas

Maybe just catch the CaptchaRequiredException at all auth rejections and pass this info to the user with the clickable unlock URL if a link is allowed in the error message. 

http://code.google.com/apis/gdata/docs/auth/clientlogin.html#HandlingCaptchas
http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html#Response

Yeah, problem is we don't talk to Google Calendar through libgdata.  We use Google's standard-but-apparently-neglected CalDAV interface.

Is it safe to assume the the calendar retrieval does use gdata and that is why I saw what I think is a libgdata CAPTCHA exception there and not from the alarm-notify connection or client interface?

The Online Accounts seems to use something new too initially when setting up accounts using a little browser window that looks OAuth-ish.  I assume that CAPTCHA might be handled there too.

So the e-calendar-factory stuff that is CalDAV that will probably change over in some future major milestone.

I don't think its going to hurt my day to day given I now know the unlock URL which I'll post to the downstream bug.

This happened to me today again. All of a sudden my account with a password prompt came up. 

Initially I went into "Retrieve Calendars" and it worked (saw the list and re-selected and closed) but immediately the prompt from evolution client came back up.  I canceled the prompt and disabled the calendar and then went back into Properties to try and retrieve calendars again.

Sure enough I received the CAPTCHA required error this time.

I tried in my Chrome browser to hit the CALDAV URL:https://www.google.com/calendar/dav/you@gmail.com/user/

With correct credentials the prompt just kept popping up, with no hint of CAPTCHA required or good/bad password.

Next I tried the following URL:
https://www.google.com/accounts/UnlockCaptcha 

After filling it in correctly, it said "Unlocked" and my next evolution password prompt worked and I successfully created and verified some calendar events. 

I then went back to the CALDAV URL in my browser and successfully authenticated which resulted in a "Method Not Allowed" Error 405 which I assume is just what you get when you are a dumb client. The /events/ gave me a download. 

So it seems CAPTCHA issue is as expected, and can be unlocked with this workaround IF we can help users identify it somehow.

(In reply to comment #1)
> Cannot open calendar: Unexpected HTTP status code 7 returned (Connection
> terminated unexpectedly)

This is bug #659233, the rest can be just because of it. Could you retest with that fix, please?

Well, I suppose I could the next time I get locked out due to CAPTCHA.  I had a look at the bug, and it applies to a gnutls 3.x issue. So a non-starter there.

Ubuntu 11.10 ships with 2.10.5 (libgnutls26)

Is the thinking that a bad caldav handshake is causing the CAPTCHA?

Yup, I think (and only think) it's a consequence of "Cannot open calendar: Unexpected HTTP status code 7 returned (Connection terminated unexpectedly)"

I also believe this to be the case, as I have seen it on my Android phone and HP Touchpad (awaiting Android) as well, only since the 3.1.91 upgrade.  On the Touchpad, the login just fails.. looks like a WebOS bug.. but the CAPTCHA validate URL fixes it too.  

Any way to get more info, like run e-calendar with some extra debug for the CalDav?

Yup, you can run the factory as:
   $ CALDAV_DEBUG=all /usr/libexec/e-calendar-factory
and then run evolution and see what will be shown in the factory's console.

Okay, I have found this to be somewhat reproducible.  I will try and capture a debug output tomorrow at lunch.

The prompt for calendar passwords occurs when I leave my evolution open and idle for a few hours.  In my case, the passwords for my two active Google calendars are prompted after I unlock my screen (no sleep, plugged in).  These persist until I execute the Unlock/Captcha on each of them.  If I do only one, then only the remaining calendar is prompted for credentials, so this also suggests that the failure is due to a mishandled captcha. 

Finally, if I try and accept a calendar event before I do the capthca, even if there are no prompts (they disappear after entering a password for minutes at a time prior to doing the captcha) I seem to generate a crash.

This crash is linked below, and will be public once the retrace is complete. I suspect it may be similar to https://bugzilla.gnome.org/show_bug.cgi?id=659491

One more observation from this current session (I am sure if I restart evolution this will fix itself.

I am able to make the password prompts go away using the captcha.. but they always seem to come back 5-10 minutes later.  And each time the only way to make them dissappear is with the captcha.  Since I have three Google accounts (One personal, one work, one is my wife's), I have to log out of Google, and execute the captcha URL with each Google user.

Even after I close the evolution main interface, evolution remains running and sends me the authentication dialogue until I force-shutdown.

Created attachment 201102 [details]
Output when Captcha likely is occuring

Well I have a 2Million line debug output from the calendar e-factory when the Authorization fails. It is probably best to share only directly with devs if it will be useful given the personal information. Email me if you would like it. 

The process to trigger the issue seems to be 100% reproducible in my case by just leaving my 3.2.1-0ubuntu1 idle for a few hours. If I use it to do emails (even without accessing the calendar directly) it does not trigger this issue, presumably because certain emails are calendar events and *touch* the factory to keep it alive. 

How to create the problem,

1) Open evolution and leave it open for a few hours without using it until a password prompt appears.  

The transcript of the subsequent events during my session are as follows,

2) Pressed OK, not changing the password, and attempted to close evolution
3) Prompts were re-occurring too quickly, so I tried "Cancel" and then attempted to close evolution
4) It closed, but my e-calendar factory was still going hard (lots of output) and I could see an "Unauthorized" flying by on the console along with some valid data that seemed to be repeating from my one calendar account that had not prompted me
5) I subsequently completed the Captcha for both the accounts that had prompted for passwords, and I think I saw some in-conjunction "CalDAV - finished syncing" events.
6) The communication seemed to be spinning, so eventually I called a --force-shutdown from another unprivileged console. 

Here is my analysis of the factory log, which seems to support my theory of the Captcha event, sucessfull re-authentication to resolve via Web browser, followed by some unexplained spinning of sucessful events prior to eventual shutdown. Also attached is the one message which actually appears to contain the captcha image (if this is useful). 

1) SoupMessage 1 starts for all three of my Google calendars, and ends with 401 Unautorized for all three endinng at timestamp 1320846121
2) SoupMessage 2 starts for all three of my Google calendars, has a 401 for all three, restarts for all three and results in 200 OKs for all three ending at timestamp 1320846123
3) SoupMessage 774 starts at 1320854921, followed by 200 OK, a REPORT events, and then a 302 followed by a restart and a 405 Method Not Allowed at 1320854969
There is an embedded image as seen in the attachment which contains the SoupMessage, so this is indeed the Captcha IMHO. 
There is also a console message e-cal-backend-caldav-WARNING **: Server did not response with 207, but with code 405 (Method Not Allowed) 
4) SoupMessage 769 has a 401 Unauthorized shortly thereafter at timestamp 1320855055
on the console I see: e-cal-backend-caldav-WARNING **: Server did not response with 207, but with code 401 (Unauthorized)
5) Same thing with SoupMessage 770, 773-796, 800-871.
6) SoupMessage 872 is 200 OK at 1320855078 and the has a 401 at 1320855169 and then a 503 Unavailable at 1320855170 followed by a 207 Mutlistatus at 1320855317. 
I think that this is when I did the browser Captcha Unlock
7) SoupMessage 875 has a 401 at 1320855081, restarts and has a 207 Multi-status, two more 401s  and then a 207 Multistatus at 1320855320
8) SoupMessage 796 is 200 OK at 1320855038, goes 401 at 1320855105 and is 200 OK at 1320855106
9) There are no more Unauthorized after 1320855322 and everything is fine (200,207) until the force-shutdown. The factory did appear to be spinning for whatever reason and taking CPU load up at the same time, possibly re-collecting the same information over and over again as the same events appear over and over in the logs from all three calendars until I shut it down.

This is reproducible in evolution-3.6.90 and evolution-3.6.4 if user doesn't use gmail and simple adds a calendar both Google or CalDAV

Interesting, I used to have a Google ID with only a calendar configured as well.  Now I access the same calendar via my main google account and I no longer have this issue.

I suspect that that Comment 17 identifies the specific conditions that caused the issue in the original report.

(In reply to comment #17)
> This is reproducible in evolution-3.6.90 and evolution-3.6.4 if user doesn't
> use gmail and simple adds a calendar both Google or CalDAV

Could you provide more detailed steps, please? I do not understand all of the above. Also, could you test with 3.8.1? Even I guess it'll be mostly the same.

>Could you provide more detailed steps, please?

1. Disable/remove any GMail email account
2. Setup any other email account
3. Go to Calendar, File - New - Calendar
4. Select Type = 'Google' and specify google credentials
5. Select new google calendar

Result: HTTP 405 error message appears

Reproduced in evolution-3.8.1-1

(In reply to comment #20)
> Result: HTTP 405 error message appears
> 
> Reproduced in evolution-3.8.1-1

Nice, I see it too. The reason is that evolution tries to OPTIONS a www.google.com/ , not the calendar URL. I suppose it's new and unrelated to this CAPTCHA issue, even I agree it's similar. Could you open a new bug report for this, please?

(In reply to comment #21)
> (In reply to comment #20)
> > Result: HTTP 405 error message appears
> > 
> > Reproduced in evolution-3.8.1-1
> 
> Nice, I see it too. The reason is that evolution tries to OPTIONS a
> www.google.com/ , not the calendar URL. I suppose it's new and unrelated to
> this CAPTCHA issue, even I agree it's similar. Could you open a new bug report
> for this, please?

It seems I'm quicker :) (checked on IRC as well).

Created commit 0ccccea in evo master (3.9.2+)
Created commit 9d0632e in evo gnome-3-8 (3.8.2+)

From the commit log:

   Newly configured Google calendar cannot be opened

   Unless the button to choose a calendar was clicked, because
   the calendar path is not filled, thus the server claims
   "HTTP 405 error", which means an OPTIONS request cannot be done
   on the path, which was just root of www.google.com, instead
   of a calendar path. (This was reported as part of bug #659522.)

-------------------------------------------------------------------------

Let's keep this bug opened for the CAPTCHA issue, though I'm not sure how much we can do with it, because the backend returns whatever error code and description the server gave.

Hmm, I guess the Google server just redirects any requests to a /googlecalendar/unavailable.html page, but the CalDAV calendar doesn't notice it (is there any way to recognize this state in general?) and tries to do whatever it is doing, which yields to the 405 error.

Issue in comment #20 fixed, thanks

I still do not know how this could happen, but I agree that a URI in the generic connection error message would help to identify the issue, instead of just claiming "Unexpected HTTP status code 405 returned (Method Not Allowed)". That may give the missing hint in cases when the server redirects the page to some odd address, like the CAPTCHA is. I tested this with my server and it returns the URI in the error message too now.

Created commit f7e7724 in eds master (3.15.91+)