How do I setup the pubnub cocoa objective-c client api to NOT store anything on the keychain? Is it possible to store the keys on the Application Support folder instead? When I am using XCode the keychain messagebox modal appears three times even when I press the 'Always Allow' button. It stops for a while but then after a few minutes it asks me again the same way again.
I've checked on my side and it really requested password for each read from Keychain. Tried to find solution and after system reboot, tried again - it requested for password one or three times and then just keep working. As for now, there is no option to configure client without Keychain usage.
Earlier Keychain worked like well after single password input. Looks like one of system updates broke how system interact with developed applications.
Maybe it is somehow related to security and checking "Automatically manage signing" and specifying proper profiles will help you (I'm unable to check this, since Keychain gives me access w/o asking password now since I marked awlays).
Keychain used to store few fields: publish sequence number, uuid, and push token. It had been added to Keychain to survive application re-install.
We will review macOS Keychain usage and if it will be allowed, we will add ability to use file-based data storage (maybe by default for macOS).
Related
My Use case :
I have an automation framework for Mac that launches 2 instances of the same app ( same bundle id) available at different locations to simulate two endpoint cases for media calls. With introduction of Mojave permissions, when I grant permission( camera , mic & accessibility) for one instance of the app, the other instance doesn't have the same permissions.
Since the bundle id is same, is it not that providing permission for the app is carried over to both instances?
I tried pushing a system profile to provide permissions but that doesn't seem to work
Also added an apple script to continuously check for permission pop-up and click ok to it. This works for mic and camera but not for accessibility. Also when each instance is launched the permission would be asked again.
Is there a way to by default provide all access to the application by default without asking for any permission pop-ups?
Or is there any way to tweak something at the OS level to not ask for permissions at all ( behave same as <10.14) .. I tried disabling system integrity but that doesn't seems solve this issue
You need to code-sign all versions/copies of the app using the same identity.
When an app is not code-signed and the system needs to record its identity (as for permissions), it generates an ad hoc code signature. That signature, though, only matches that exact build of the app. Another copy of the app that is different in any code-signature-relevant way is not considered to have the same identity. In fact, it's likely to be considered "malicious" as it appears to have been tampered with.
If you code-sign your app with appropriate designated requirements, that enables the system to understand that two different versions of an app have the same identity and should share permissions. This is key to an app maintaining permissions through an upgrade to a new version, for example.
I've noticed something somewhat strange when I ran the Xcode build of my app and then launch the app store build. If I run the xcode build (using development certificates), then run my app through the app store (using production certificates) I get prompted with the following dialog box
MyApp want to use your confidential information stored in "com.myApp in the keychain.
I also get this dialog when I run the app store build first, then the Xcode development build. I believe this dialog appears because both builds have different certificates (could be wrong).
My biggest concern is the user updates the app, will the user see this dialog?
Not sure if this is important, but this is how I save data to the keychain.
[[A0SimpleKeychain keychain] setString:string forKey:#"key"];
Apple's code signing guide has the answers.
I believe this dialog appears because both builds have different certificates
Correct. See Understanding the Code Signature:
The most important internal requirement is the designated requirement, or DR. This rule tells an evaluating system how to identify a particular piece of code. Any two pieces of code that have (and successfully verify against) the same DR are considered to be the same code.
...
Some parts of macOS do not care about the identity of the signer. They care only whether the app is validly signed and stable. Stability is determined through the DR, and does not depend on the nature of the certificate authority used. The keychain system and parental controls are examples of such usage.
From Code Signing Tasks:
Shipping and Updating Your Product
The user’s system considers the new version of your product to be the
same program as the previous version. For example, Keychain Services
does not distinguish older and newer versions of your program as long
as both are signed and the unique Identifier remains constant.
Signing your code with a different certificate makes the system consider it a different app. As long as you sign your releases with the same certificate between versions, you will be fine.
My app is rejected by
2.3 Apps that do not perform as advertised by the developer will be rejected
It said that the file copied into "~/Library/Fonts" failed.
It works when test by myself, I find that it will get permission fail when using the sandbox mode, did Apple reviewer will accept this feedback?
thanks
Apps must work in the sandbox no exceptions allowed.
A sandboxed application cannot write to ~/Library/Fonts.
Either store the font in the app bundle and use it from there, or put up a standard file dialog asking the user to grant permission to write to ~/Library/Fonts by selecting it.
If you get stuck doing either of those ask a specific question on them showing what you've tried. Such a question is unlikely to be seen as off topic.
HTH
I'm trying to understand the whole provisioning-proccess, but I just don't get it..
I have tried to read up, but it's too weird and difficult for me to understand, especially when English is neither my primary or secondary language..
I have been developing for a while, and I remember stressing alot when setting up my iphone for development the first time. When I go into Settings->General on my phone I have 17 profiles, but at least I got it working in the end.
Now, I'm porting my app to iPad, and I'm trying to add my iPad to the table.
This is what I did:
I went to developer.apple.com, added my udid in devices, I then went to provisioning on the same webpage, and saw three profiles, one uneditable(controlled by xcode), one connected to my app's AppID, and one connected to myself as an AppID.
I added my new iPad-device to all three of them to be sure, and downloaded them again.
I dragged the .mobileprovisions to iTunes and to Xcode, and I went into organizer and clicked Refresh to update them. I clicked Use for development on my iPad, and it says it contains those profiles. They're also in Settings->General on my iPad.
In my XCode project, I go under Targets->Build Settings->Code Signing, and set one of my new profiles to Debug, and one of the other to Any iOS Sdk inside it. I've tried multiple combinations. I also went to Project->Build Settings->Code Signing and did the same thing.
When I run my app on my device, it pops up two of the same error message saying A valid provisioning profile for this executable was not found.
When I now connect my iPhone, which has been working perfectly fine all along, the exact same thing happens. Two of the same error message.
The question:
Which profiles goes where? What is the difference between the profile containing myself as an AppID and the one containing my actual app's ID as AppID? What is the difference between Target->Build Settings and Project->Build Settings when it comes to Code Signing?
Also, we spent a lot of time making push work, and out app is on AppStore rigth now, so I don't want to start deleting profiles and ID's, cause I think I read somewhere that that could make the notification stop working.
Oh, and I downloaded a new certificate as well at some point, containing the new profiles, and it ended up in keychain named along with 1000 others..
Help :( ?
Sorry for long and extremely boring/noobish question.
I think that your code doesn't build because of a certificate issue - like you said at the end of your question - you "downloaded a new certificate at some point containing the profiles..." You need to understand that a certificate does not 'contain' profiles, but profiles are created and signed using a specific certificate. Check that you have the private key of this certificate - if the signing request was not issued by you, it will require someone else exporting this certificate for you from his own keychain. Keep in mind that downloading the certificate available in your developer account will not suffice.
As for everything else:
Which profiles goes where?
Make sure you're creating relevant profiles with correct bundle IDs for your apps. Distribution profiles should include AdHoc and AppStore profiles, while Development profiles are, well, for development :)
What is the difference between the profile containing myself as an AppID and the one containing my actual app's ID as AppID?
Not sure what you mean here. Myself as an AppID? Each profile is linked to a specific App ID that has a bundle ID - it can be used to compile any app that has this bundle or any sub-domain of it in the info.plist of the project.
What is the difference between Target->Build Settings and Project->Build Settings when it comes to Code Signing?
You can think of your Project->Build Settings as the global settings and the Target->Build Settings as the target-specific settings. If XCode can't figure out which profile to use from the target settings, it will go and fetch it from the project settings.
The problem was that after we had released our app to the AppStore, we forgot to put the "Edit Scheme->Run" back to Debug from Release. This had no effect on my iPhone because I have added it to the release-provisioning-test thing.
I'm writing a suite of applications that all require login to a server. It's come together quite nicely, but I've run into a logistic snag. The nature of the applications require that they be closed and launched again later with some frequency. It is very annoying to have to login every time one of the applications needs to launch.
I'm trying to think of a secure way of perhaps having the login information stored on the local user's machine. Is there a good way to even go about that? Permissions protected config files? The registry? How does Firefox store its passwords? Have you ever had to do something like this?
The suite is more of a protocol than anything, all the applications are written in a variety of languages (Python, C#, Java, etc) and run on a variety of operating systems (Windows, Linux, OSX, etc). I'm not really looking for code examples, but more just general approaches to this problem. Is it wise to have locally stored passwords? How can you have a session login for a suite with such disparate components? Right now I use application.rc config files stored locally to each application, but they are plain text and far from secure.
I'm going with Jeff on this one and assuming that since you mention the registry, you're referring to Windows. I'm also going to assume that you're talking about a desktop application (otherwise you could just use the builtin browser cookies to store the user's session).
Off the top of my head, I'd engineer the application so that when the user logs in to the server, the server returns a unique session id that identifies the authenticated user. I would then store than id along with an salted/encryped timestamp (which gives you the option of expiring the cached credentials).
The storage mechanism is up to you. You could store them in the HKEY_LOCAL_USERS section of the windows registry, or the Application Data folder in Windows. Both give you the option of user segmented storage.
Typically, this sort of thing is done by use of a "cookie"; a key which (securely) indicates that the user has successfully previously logged in to the server resource. This is how most web sites manage login information, and Firefox (all browsers, really) store the cookies that the browsers set on the user login. A few important things about cookies: they should be encrypted, to assure that malicious programs cannot generate one and thereby bypass the login process, they should match to server-kept resources (same reason), and they should age out, so that while you can maintain login information on a site for a while, your login information is not permanent (which is another security hole).
Personally I would use an encrypted local config file with some sort of an ID value of the machine (motherboard ID, Chip ID, HD ID etc) as part of the encryption key so that the config file cant be just copied from one machine to another. I would also include the date and time so you can expire it when you decide it gets stale.
Alternatively, you can create a host exe or launcher that does the log in and then goes to sleep and wake it up each time you want to launch a new application. The host exe would take the application as a parameter and decide whether or not to ask for login credentials (usually when the first app is started and then keep the login user and an encrypted password in memory. When the host exe has exited the login info is forgotten and when you start up again the cycle starts over.)
Tomcat 6 supports persistence/replication of sessions, so you should care about choosing the manager and configure it ;-)
More info: http://tomcat.apache.org/tomcat-6.0-doc/config/manager.html