• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Read/Write to info.plist's LSEnvironment
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Read/Write to info.plist's LSEnvironment


  • Subject: Re: Read/Write to info.plist's LSEnvironment
  • From: Colin Cornaby <email@hidden>
  • Date: Mon, 21 Jul 2008 14:55:43 -0700

iPhone apps are signed (so are some Mac OS X apps). Modifying a signed app's Info.plist can cause things to go haywire. On the iPhone, it can cause the app to not work at all.

Don't modify your own info.plist. It's the Apple recommended way.

On Jul 21, 2008, at 10:32 AM, Lee, Frederick wrote:

Point well taken.
I'm going with key chain.
BTW: this is for an iPhone environment.
I'm hesitant to mention iPhone via NDA; so tried to be as generic as
possible.
Thanks for the needed insight.

Ric.



-----Original Message-----
From: Jens Alfke [mailto:email@hidden]
Sent: Monday, July 21, 2008 12:22 PM
To: Lee, Frederick
Cc: email@hidden; email@hidden
Subject: Re: Read/Write to info.plist's LSEnvironment


On 21 Jul '08, at 10:09 AM, Lee, Frederick wrote:

I was thinking of keeping the User ID and other simple < 2KB of
identifiers within the bundle.  I found the LSEnvironment option and
it 'appears' to be what I'm after.

What if there are multiple users on the machine? Then they'll all be forced to use the same user ID. Even worse: in many enterprise environments, applications are stored on a central file server that only network admins can modify. With your scheme, not only would users not be able to set their own user ID, but they wouldn't even have write access.

In general you should *never* modify the contents of your app bundle
at runtime. (The only exception would be for apps that can software-
update themselves, as with the Sparkle framework.) Any modifiable data
should go in user defaults, or in the user's Library/Application
Suppport/ directory. Data to be shared between users should go in /
Library/Application Support/.

Also, *never* store passwords in regular files! Especially not files
that can be read by other users! The Keychain is a secure place to
store passwords and you should use it for that.

But FWIW... using XML based LSEnvironment had appeared to more...
modular.

Modular how? (And user defaults are based on property lists just as the Info.plist is, though it really doesn't matter to the developer.)

-Jens
_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden

_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Read/Write to info.plist's LSEnvironment (From: "Lee, Frederick" <email@hidden>)
 >Re: Read/Write to info.plist's LSEnvironment (From: "Finlay Dobbie" <email@hidden>)
 >RE: Read/Write to info.plist's LSEnvironment (From: "Lee, Frederick" <email@hidden>)
 >Re: Read/Write to info.plist's LSEnvironment (From: Jens Alfke <email@hidden>)
 >RE: Read/Write to info.plist's LSEnvironment (From: "Lee, Frederick" <email@hidden>)

  • Prev by Date: Re: StopWatch Application Help
  • Next by Date: Re: set posterImage in QTKit?
  • Previous by thread: RE: Read/Write to info.plist's LSEnvironment
  • Next by thread: Avoiding mutual retain cycles
  • Index(es):
    • Date
    • Thread