RE: Read/Write to info.plist's LSEnvironment
RE: Read/Write to info.plist's LSEnvironment
- Subject: RE: Read/Write to info.plist's LSEnvironment
- From: "Lee, Frederick" <email@hidden>
- Date: Mon, 21 Jul 2008 13:32:01 -0400
- Thread-topic: Read/Write to info.plist's LSEnvironment
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