iCal keeps prompting me for password

1. I was originally using old single factor. Starting getting the prompts to re-enter my password in iCal. Searched online on google groups and found someone saying that they turned on 2 factor authentication and that fixed it. I then turned on 2 factor auth, setup app specific passwords through google's account management site. I then put the new passwords into iCal but it didn't fix it. I then disabled 2 factor authentication. That didn't fix it either. I then changed my google password and put that password into iCal and it worked.
2. iCal and iOS don't support 2 factor authentication. You have to create app specific passwords through google account management and then use those passwords in OSX and iOS.
3. I use 1Password to generate all my passwords (i have different passwords for every site). They are over 32 characters long and a mix of numbers, letters and symbols.
4. In iCal i deleted the Google account and set it back up using the new master password i described in #1

I think I may have found quite a simple solution.

Here is what I did, and for now it seems to be working.

1. Open iCal and wait for the password prompt.
2. Generate an appliaction specific password on Google (assuming you are using two token authentication)
3. Put the password into iCal and press ok. Leave iCal open.
4. Then go to System Preferences, Mail, Contacts and Calendars
5. Select the same account in the left hand bar, then select Details
6. Paste the same password there as you just did in iCal.

That seems to now work perfectly for Mail and Calendar.

If it stops working, I will update the thread again.

Warren

P.S. I assume it works for normal passwords in the same way.

I had this exact problem while using 2-factor auth. When I went to look at the application-specific passwords I'd generated, I noticed the one issued to the computer in question conked out at exactly the 1-year mark. Issuing a new one solved it.

Fix:

• visit https://accounts.google.com/b/1/IssuedAuthSubTokens?hl=en
• scroll down to Application-specific passwords
• enter a name (e.g. iMac 2013) and hit the "generate password" button
• copy password
• go to settings/email & calendars and the account in question, click details, and replace the password there with the one you just copied.

I have this problem too. It's only started in the past few days but now it's affecting all my calendars. I'm seeing the same error as you plus hundreds of copies of:

8/9/12 1:38:54.237 PM CalendarAgent[660]: Unexpected EOF, returning last token as fallback

The only way I could make it stop was to disable all delegated calendars and restart the app a couple of times. It's clearly either a bug in Mountain Lion or a Google issue, and I suspect ML: colleagues running 10.8 are experiencing this issue but those still on 10.7 are not.

I'm curious if Apple and/or Google are tweaking security policies following the Wired hack last week. I'm using two factor authentication, I wonder if anyone without two factor are seeing this issue?

I was having this issue and thought the same thing about 2 factor authentication. However, i have the problem using the old password sytel and the 2 factor authentication. The problem doesn't happen until i try to enable my delegage calendars.

Ok. So after it keeps asking me to re-enter my password in Calendar app, i thought maybe that the attempts were triggering Google to lock the account to protect it from attacks. I went to google and changed my google password, then used that new password in Calendar and its working again. Delegates refreshed and everything working correctly.

I'm seeing exactly the same thing. The moment I add any Delegate calendars the password prompts begin. This only started last night for me (may be coincidence that I had just changed my password). Nothing I have tried works, so I just hope this is something on Google's end that is fixed with us simply waiting this out. It is annoying, but at least everything being synced means we have other options to access it and issues with Calendar don't compromise the data (and my iOS devices still sync properly without any hitches).

I got the password prompt, too and also "error 302". I was not able to sync new events from iCal to Google. I force quit the process "CalendarAgent" using Activity Monitor, and now syncing seems to work. And I haven't seen the password prompt nor error messages yet (though Console is full of errors).

Im also getting the same problem.

Ive tried deleting passwords through keychain, force stopping Caldav processes in Activities, and deleting and reinstalling Calendar accounts.

Im on 10.8 and using delegates (8).

Here's what I get:

8/13/12 5:01:17.479 PM CalendarAgent[59836]: [com.apple.calendar.store.log.caldav.queue] [Account refresh failed with error: Error Domain=CoreDAVHTTPStatusErrorDomain Code=401 "The operation couldn’t be completed. (CoreDAVHTTPStatusErrorDomain error 401.)" UserInfo=0x7fe89606d290 {AccountName=Google, CalDAVErrFromRefresh=YES, CoreDAVHTTPHeaders=<CFBasicHash 0x7fe8938b9e40 [0x7fff78720190]>{type = immutable dict, count = 10,

entries =>

0 : Case Insensitive Key: X-Content-Type-Options = <CFString 0x7fe893895e80 [0x7fff78720190]>{contents = "nosniff"}

1 : Case Insensitive Key: Content-Type = <CFString 0x7fe893895c80 [0x7fff78720190]>{contents = "text/html; charset=UTF-8"}

2 : Case Insensitive Key: Server = <CFString 0x7fe8938d3310 [0x7fff78720190]>{contents = "GSE"}

3 : Case Insensitive Key: Transfer-Encoding = <CFString 0x7fff78b9c6b8 [0x7fff78720190]>{contents = "Identity"}

6 : Case Insensitive Key: Date = <CFString 0x7fe8938e4080 [0x7fff78720190]>{contents = "Mon, 13 Aug 2012 16:01:17 GMT"}

7 : Case Insensitive Key: X-Frame-Options = <CFString 0x7fe8938c17c0 [0x7fff78720190]>{contents = "SAMEORIGIN"}

8 : Case Insensitive Key: X-XSS-Protection = <CFString 0x7fe896016b70 [0x7fff78720190]>{contents = "1; mode=block"}

9 : Case Insensitive Key: Www-Authenticate = <CFString 0x7fe8938e0630 [0x7fff78720190]>{contents = "BASIC realm="Google CalDAV""}

11 : Case Insensitive Key: Cache-Control = <CFString 0x7fe8938f1c60 [0x7fff78720190]>{contents = "private, max-age=0"}

12 : Case Insensitive Key: Expires = <CFString 0x7fe896002560 [0x7fff78720190]>{contents = "Mon, 13 Aug 2012 16:01:17 GMT"}

}

}]

I may just have figured out a fairly complicated way to fix this issue, or at least glean some insight into the problem (as in the course of this writing the problem came back for me). I'll try to explain it in simple terms here, but please ask questions if you don't follow me (and know that I'm writing this after just minutes of not seeing the dreaded password prompt.

Thinking of this possible fix started with first seeing the syncing work with the trial versions of BusyCal and BusySync… So it is not directly an issue with CalDAV on the Google end, and might well be Calendar specific (maybe not OS X Calendar specific if iOS Calendar shares the bug).

Then I paid close attention to the first part of the log entries most of us have posted: “8/12/12 4:58:21.263 PM CalendarAgent[431]:”, specifically “CalendarAgent”. The process that actually does the syncing with Google Calendar is not Calendar directly, but Apple’s system-level background process CalendarAgent. CalendarAgent is located (as found using Activity Monitor in /Applications/Utilities) in /System/Library/PrivateFrameworks/CalendarAgent.framework/Executables.

Then, where does the system (supposedly, given these issue…) store the account passwords? In the keychain, which we can view and edit using Keychain Access (in /Applications/Utilities).

I just did two things that (for more than one functional sync at least) eradicated the password prompts. It may be worth trying if you’ve had these issues, it may work more permanently for you, or at least give you ideas for future attempts at fixing the problem and further insight into the issue. I made two changes to every Google-related keychain item in my login keychain:

1. If the stored password was my old password I updated it to my current/new password.

2. Added CalendarAgent as a process that can access the password under the Access Control tab of the keychain item editor

That’s all I did, and at least for a bit it appeared that I had fixed the issue. I suggest you try this and see if it fixes the problem for you. If not then at least this write-up furthers our documenting of this issue even if it doesn’t resolve it.

Also, anyone and not just registered developers can log in at https://bugreport.apple.com and submit bug reports. I think as many of you who are willing ought to at this point regarding this problem.

Ah. You need to search for the CalDav keychains - search for DAV or or Caldav. You should then have two google related items in the finder pane - and it should indicate that they are for calendar use. Good instructions for this stage are here:

http://www.atpeaz.com/index.php/2011/fixing-lions-icals-caldav-password-problem/

Except you dont delete the keychain - but rather select it and and then when you have found the keychain double click, select Access Control, select + to add a new application, and then navigate to the Calendare Agent.

Good luck...it's still working for me - though it does still ask for a password intermittently, but not as bad as it was before.

As I mentioned in an earlier post, I am having this same problem with iCal except my calendar server is a Zimbra server, not Google. Because this is a work calendar, I reported the behavior to our IT group and they told me that the Zimbra server does not do any authentication -- it relies entirely on our AD (Active Directory) infrastructure. To test this, they asked me to try to log in to an internal password protected website when the iCal problem started occurring again. They were right -- when iCal started rejecting my password I was also unable to log in to the website with my credentials. So -- at least in my case -- this appears to be more of an AD problem than an iCal or calendar server problem. (Depending on how Google's calendar server authenticates, the root cause could be the same there as well.)

I noticed that people testing the upcoming Mountain Lion patch release have been asked to focus on Active Directory, which leaves me hopeful that Apple understands the problem and has fixed it.