I have a windows application getting ported for Mac.In windows i store encrypted data in the registry.But when it comes to Mac im unfamiliar.
The application is licensed per PC.So all Users using the Machine will be able to use it.So in windows im storing the key in HKEY\LOCAL MACHINE
How does user access rights work in Mac? Where do i need to store the data?
This type of data is usually stored in a file in Application Support directory. If you want to store one file for all users you should choose /Library/Application Support system directory.
The directory is not user-writable, so you will have to run installer with root privileges. This directory can't be used by sandboxed apps.
You should create a subfolder in this directory and store your file inside.
For more information see The Mac Application Environment, especially Table 1-1, "Key directories for Mac apps", and File System Basics.
Edit:
Usually OS X apps don't need any installation. They are self-contained bundles that can be run from any location. Usually you keep them in Applications folder (drag it there). System wide /Applications folder is accessible for all users. There is also private ~/Applications folder in each user's home.
On the other hand apps that need to install data to system folders use installers. Installer usually copies application bundle to /Applications folder, but also handles authentication and asks user for admin credentials. Installers may also run scripts.
Maybe your license could be generated by a script during installation?
If not, you would have to generate license file on first application run. In such case, if you want to keep one file for all users in /Library/Application Support, you will have to escalate privileges and ask user for admin access. If you don't want to do that, consider storing separate license file for each user in their home ~/Library/Application Support folder.
Related
I have a macOS application should be registered for all users on that physical machine. I'm currently using nsuserdefaults to store the registration info, but this prevents other users of the machine from using the software, because nsuserdefaults is user-specific.
I've looked into using the CFPreferences API:
CFPreferencesSetValue(key,
value,
kCFPreferencesCurrentApplication,
kCFPreferencesAnyUser,
kCFPreferencesCurrentHost);
But that requires root privileges, which I do not want to require for my application.
What is the best way to store registration info for all users of a machine, without requiring root privileges?
What I do is to create a folder in /Library/Application Support that anyone can write to in the postinstall script in my installer package. Then the application can do whatever it likes in that folder and in fact, like you, I use it primarily to store registration information.
The folder should be named as your application's bundle ID and your installer package needs to be set to run as root so that postinstall can create the folder in the first place.
If you don't yet have an installer package, you will have to make one. For this, I recommend Packages. Avoid Apple's Package Maker tool - it's terrible.
On Window 7, 8 and 10 I want my app to store data in shared location so all users who run the app on the PC will access the same data. The data are readable/writable. What location should I use?
Windows has funny rules regarding program' shared data.
Program Files ("C:\Program Files" and "C:\Program Files (x86)") is intended for immutable (read-only) program data and executable files - consequently files here require administrative permissions to edit. Thus it makes it useful for important files that should not be compromised (e.g. your main executable). This is why installers run with elevated permissions. There is a downside in that if your program has an auto-update mechanism then that too needs to run elevated.
Program Data (C:\ProgramData on Windows Vista and later, or C:\Documents and Settings\All Users\Application Data) is intended for mutable program data - you don't need administrative permissions to create files in this folder, except that once a file has been created only the user that originally created that file can subsequently edit it (though everyone can read it). This is the special CREATOR OWNER permission.
This is described here: Privileges/owner issue when writing in C:\ProgramData\
AppData (C:\Users\(you)\AppData\Local and C:\Users\(you)\AppData\Roaming) is user-specific and is intended for user-specific settings, configuration and data. The Local version should be used for machine-specific settings that shouldn't roam if the user is using Roaming Profiles, such as data caches (e.g. a browser cache).
So in your case ProgramData looks ideal, but you need to be careful about the default CREATOR OWNER rules - but there's a workaround: your program's installer (which would run as admin) has the ability to change the ACL permissions on its ProgramData subdirectory to allow other users to edit files. I suggest granting the Users group permission instead of Everyone to prevent possible remote attacks and modifications by unauthenticated users.
If I install my app to program files, will it always be able to create and write files within its install directory? It seems to work in a lot of different versions of windows, but are there situations where this wouldn't work?
Mainly I'm using this approach for logging. If this is not the correct approach, is there a better place to log?
Note: My installer requires Admin privileges to run and it grants Full Access to all users in the install directory.
Apps don't run as users, users run as users. If you install an app into Program Files, and let's assume you needed elevated permissions to do so, when your standard user then runs that app, that is the user that needs permissions.
App is installed with elevated permissions (user: Admin, for example)
All permissions on the AppName folder might well be "Admin:Full, Users:Read"
User runs app, so cannot change any files
At install-time, your installer will need to know which of it's own files need to be made writable to standard users, and set permissions accordingly. Of course, user-data should not be in Program Files anyway. That's what %appdata% and the user profile are for, usually.
If your app has a globalsettings.ini or whatever, that lives in "Program Files\YourApp", then while you have admin permissions (i.e. at install time) you need to grant write permission to all users to that globalsettings.ini file. Or Power Users. Or a group. Or whatever is correct for your app.
In summary, no, users do not have default write-access to ProgFiles, nor should they.
Yes, there are definitely situations where this won't work, such as when your app is running on Windows 7, or if your user account is a limited user.
We always put our log files in a temp directory or a special folder such as AppData.
I'm currently working on my applications installer and I'm wondering where the executable files should be installed to in Windows 7.
If I'm installing as admin my executables files get put in C:\Program Files.
If I install my product as a normal user where should the executables be put?
Thanks in advance.
Which installer are you using?
MSI runs in elevated privileges. You can install your application in program files folder
Put the files in the user folder.
This will mean that the application is only available to that user.
You should probably store that in the AppData directry, as I saw you mention in reply to #ChrisF. Remember that the user can move this directory though, so I wouldn't point to it explicitly. There is an environment variable that you can grab, that only applies to the logged-in user, which is %AppData%.
Keep in mind that putting it in %AppData%/Roaming would follow the user across multiple machines on the same Domain and %AppData%/Local would just stay on the one machine.
The executables should be under Program Files, who's precise location may vary from installation to installation. This means that the setup should run elevated. If InnoSetup makes .msi files, they will request elevation. If it makes a file called setup.exe, it will also request elevation. If for some reason the exe has a different name, like GetStarted.exe, then you should hand create an external manifest (GetStarted.exe.manifest) and put in requireAdministrator for the requestedExecutionLevel which will ensure your installer requests elevation.
Regardless of how it requests elevation, if the user doing the install is an admin (eg you) they will just have to click consent. If they are not an admin they will need to get an admin to consent for them. After that the installer will be able to write to Program Files.
If it's important to you that non admins be able to install the app then have the executables go under the users profile - but that would not be my first choice. The protection given to Program Files means that users are less likely to find themselves with messed up copies of your application if you install it to the protected area.
I wonder about this because we are developing an application, after installation some files were copied to program files and some to user profile directory. But, we found some issues w.r.t program files. Now all files are installed in the current user's directory. Even Google Chrome, does so. What do you think?
If you install a given application on 10 different accounts, do you really want the application to exist 10 times on disk?
The program files directory is for just that, the executable files, dlls, assemblies and other executable code and non editable configuration data associated with a program. The user profile directory is for data and code associated with the individual user.
The program files directory in Windows is a place where all the installed files go.
But there are some customizations needed depending on users. Those go into user's directory.
Like Downloads folder, customization of Mozilla firefox, Winamp, etc.
There has to be different profiles for each user to customize the applications.
But the commonly needed files of a software need not be installed in each user account; hence they are installed in Program Files
Since Vista the Program Files directory has been marked as off limits so applications can't write to it by default unless given admin privileges.
This is for better security to stop other applications manipulating existing installed applications.
There is a good write up of this here on how to work with UAC but also learning to write more secure applications.
http://msdn.microsoft.com/en-au/magazine/cc163486.aspx