How to enable "access rights" for keyfob access groups "has a value not allowed by the provisioning profile"

I use keychain in my application and I get this error when starting the application as AdHoc. It does not appear when I run it using a debugger (with a developer training profile). If the application is already installed on the device, and I install it again on top of it from Xcode, I noticed that the application does not have access to keychain. This is, of course, due to this error.

I spent a lot of time on this error, and some recommend adding a rights file with the keychain-access-group. But I could not find any Apple document or any reasonable explanation for what the rights file is for.

Can someone help me solve this problem?

+8
ios keychain adhoc
source share
5 answers

There is a rather old message here that you need permissions to say which Bundle Identifier you use to sample the application, since that is how KeyChain allows your application to access it.

Once two Applications have the same Bundle identifier in their package seed, they can share KeyChain access.

So, if application A has a common package identifier: com.yourcompany.AAAAAA and application B as a common package identifier com.yourcompany.BBBBBB

And if they both have a rights file in their .ipa (plist containing an array with the keys "keychain-access-groups" with the string ".com.yourcompany.AAAAA" and .com.yourcompany.BBBBB ")

They can provide access to KeyChain ..

  • Regarding your debugging / adhoc problem. in the project settings, in the section "Signing the code" → "Rights to sign the code", which are both empty.
+5
source share

I have found a solution. The appID prefix seems to be different for adHoc and Debug profiles.

Suppose we have the following AppIds:

  • a.com.mycompany.A
  • b. *

The second identifier was created using xcode, and this prefix is ​​used to sign the debug version of the application. The first identifier is used to sign the AdHoc version of the application.

If you try to use the keychain with accessgroup a.com.mycompany, you will get access to the keychains for the AdHoc version. If you use the accessgroup b.com.mycompany group, you get access in the debug version. None of them work for both.

I solved the problem by creating a new wildcard identifier: a. * and using it for the "iOS Team Provisioning Profile: * profile profile." It seems that this provisioning profile is somehow used to sign the debug build of the application. I really thought he was using Provisioning Provisioning profiles for signing ?!

However, with these changes, I can access the keychain in debug mode and adHoc with the same access group.

It seems that the new registered users are not facing this problem, now xCode automatically creates an identifier with the right prefix.

+2
source share

Several variations arose in this problem (bug ITMS-90164, among other things). After hours of working with various settings, I, unfortunately, reluctantly, after Apple Technical Q & A QA1814: setting up Xcode to automatically manage training profiles . The steps are very simple and straightforward, complete with screenshots and an important entry for the disposal of Xcode after you make the changes. Most importantly, he solved my problems and allowed me to finally upload my archive to the App Store.

+1
source share

As mentioned in other answers, this is due to the wrong training profile that is being used.

I had this problem in Xcode 6. I had two goals in my project, and one of them was always created with the wrong profile, regardless of what I did (including changing the Provisioning profile setting in the build settings).

After several hours of working with him, I noticed the following:

  • A good goal was to use a provisioning profile called "XC: com.mycompanyname.mytargetname1"
  • The broken goal was to use a profile called "XC:". This profile is the profile of "Xcode: Wildcard AppID ()".

I don’t know where it came from, but I decided to fix my problem:

  • Sign in to developer.apple.com
  • Go to certificates, identifiers and profiles
  • Click "All" in the "Profile Profiles" section in the left pane.
  • Click "+"
  • Created a new profile called "XC: com.mycompanyname.mytargetname2" (NOTE: the settings will be specific to you. The name com.mycompanyname.mytargetname2 should be replaced by your application package identifier.

After that he worked.

0
source share

In addition to the solutions mentioned above, I came across another version of this problem.

My organization identifier has changed (it may be due to the adoption of the latest agreement update on developer.apple.com), and therefore the prefix for my application has changed. So while before it was ABCCYZ0U812.com.whatever.app , now it was 90210SUXX11.com.whatever.app

When I went to send, and you get a screen that says: “Sends (application name) to Apple”, as well as a list called “Binary and Rights”, when I expand the listing under my application (twice, since I guess Xcode has an error for the first time) I would see something like

 AppName.app (5 entitlements) (provisioning profile) (arrow) application-identifier 90210SUXX11.com.whatever.app ... keychain-access-groups ABCCYZ0U812.com.whatever.app com.apple.developer.team-identifier 90210SUXX11 

So for some reason, he still used the old command identifier for the keychain-access-groups bit, but now does not match the new command identifier

I did the following

  • Click the arrow next to the provisioning profile to open the Finder where the profiles are located.
  • Removed all .mobileprovision files in this directory
  • Closed send dialog
  • In Xcode, click Xcode -> Preferences -> Accounts and upgrade my account for provisioning profiles
  • I tried to send the archive again

Now everything is agreed and it works

 AppName.app (5 entitlements) (provisioning profile) (arrow) application-identifier 90210SUXX11.com.whatever.app ... keychain-access-groups 90210SUXX11.com.whatever.app com.apple.developer.team-identifier 90210SUXX11 

There may be a subtler way to fix this without deleting everything, but this should put you on the right track.

0
source share

All Articles