1

I've noticed a pattern with some apps not logging into my Google account when they are hidden. After some digging, I think I have identified a common thread - the LSUIElement which is basically a flag telling Mac OS X to not show an "agent" app in the dock.

Many things that I always keep open (RSS, Mail, etc) I will hide from the dock by using the LSUIElement key in the app's Info.plist. But, for some reason, I noticed this causes login problems.

My two problem apps in heavy use, Sparrow for email, Reeder for RSS work fine when not hidden. When I hide them, they fail to log in to my Google account.

  1. What might be causing this?
  2. Can I prevent it?
  3. If #2 is no, is there an alternative to LSUIElement?
| improve this question | |
  • 1
    We've had some flags asking that this be moved to SO but as I read it, it's clearly about a user level issue where the OP has identified a technical reason why two user apps are not functioning as expected. I'll try editing the question to make it look less like an "how do I code my app" question at first glance. I hope lucase.62 can add details on how the "hiding" or plist manipulation is happening as well as what alternatives are sought as "an alternative to LSUIElement" – bmike♦ Jun 4 '12 at 22:03
  • 2
    @bmike I agree - while LSUIElement is intended for programmers' use, it can be used in an app's main internal plist file to (as the OP is doing) hide it from the Dock. – Cajunluke Jun 4 '12 at 22:12
  • 1
    @lucase.62 How do these apps authenticate with your Google account when they work? Is there a pop-up window? How, specifically, are they failing to log in to your Google account when they don't work? – Cajunluke Jun 4 '12 at 22:18
5

Modifying the Info.plist of an app usually invalidates its code signature, so it's not allowed to access the keychain automatically.

You can see if the code signature is valid with for example codesign -vv /Applications/Sparrow.app. An invalid signature can be replaced with sudo codesign -f -s - /Applications/Sparrow.app.

| improve this answer | |
  • I can see why that would happen, but it gave me the "app would like to access Keychain" message, and I gave it permission. And on top of that, I entered the password manually within the app, so keychain should be irrelevant. – tkbx Jun 7 '12 at 11:47
  • @lucase.62 So were the code signatures actually invalid? Those dialogs shouldn't be shown normally. – Lri Jun 7 '12 at 13:45
  • How would I know if they are? Is there a way to check? And if so, can I just allow that app to run unsigned, since I trust it? – tkbx Jun 8 '12 at 14:41
  • @lucase.62 It's in the answer: codesign -vv /Applications/Sparrow.app/ (--verify --verbose). I don't know any other way to allow apps with an invalid code signature to access the keychain by themselves. See also osx - If Mac code signing is tampered with, what might fail? - Super User. – Lri Jun 9 '12 at 1:47
  • It would seem that's the problem, it gives me "code or signature modified". But either way, after I give the app my account info manually, it still says it's incorrect. – tkbx Jun 10 '12 at 20:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .