简体   繁体   English

测试Keychain - OSStatus错误-34018

[英]Testing the Keychain - OSStatus error -34018

I'm trying to test code that reads and alters the keychain using the basic SenTest framework on Xcode. 我正在尝试使用Xcode上的基本SenTest框架来测试读取和更改钥匙串的代码。 The code works fine on device, but when I start the test I get these errors every time I want to touch the keychain with SecItemDelete / SecItemAdd /etc. 代码在设备上工作正常,但是当我开始测试时,每次我想用SecItemDelete / SecItemAdd / etc触摸钥匙串时都会出现这些错误。

The operation couldn't be completed. (OSStatus error -34018 - client has neither application-identifier nor keychain-access-groups entitlements)

I have matching wildcard provisioning profiles ( iOS Team Provisioning Profile: * ) for both the build target and the test target. 我为构建目标和测试目标配备了匹配的通配符配置文件( iOS Team Provisioning Profile: * )。

These (unconfirmed) stack overflow answers: 这些(未经证实的)堆栈溢出答案:

Read from keychain results in errSecItemNotFound 25300 从钥匙串中读取结果为errSecItemNotFound 25300

say that I need a provisioning profile matching my app identifier every time I use the keychain, but that can't be right, or I'd get the same errors outside of the test target. 假设我每次使用钥匙串时都需要一个与我的应用程序标识符匹配的配置文件,但这可能不对,或者我会在测试目标之外得到相同的错误。

Digging deeper, the (unconfirmed) answers here: 更深入地挖掘(未经证实的)答案:

SecItemAdd and SecItemCopyMatching returns error code -34018 (errSecMissingEntitlement) SecItemAdd和SecItemCopyMatching返回错误代码-34018(errSecMissingEntitlement)

imply that there might be a bug within keychain and more generally Security.framework , which is frankly terrifying. 意味着钥匙串中可能存在一个错误,更常见的是Security.framework ,这是坦率的可怕。

My question is; 我的问题是; has anyone hit OSStatus error -34018 only when they were on a test-target? 有没有人只有当他们在测试目标上时才会遇到OSStatus错误-34018? That appears to be the behavior I am seeing. 这似乎是我所看到的行为。

EDIT: Adding this answer that JorgeDeCorte used in his answer below. 编辑:添加JorgeDeCorte在下面的答案中使用的答案。

This thread seems to contain the solution if the problem exits in your unit-test target. 如果问题在您的单元测试目标中退出,则此线程似乎包含解决方案。

https://devforums.apple.com/message/917498#917498 https://devforums.apple.com/message/917498#917498

Basically you have to codesign your .xcttest folder by adding the following as a run script in your test target. 基本上,您必须通过在测试目标中添加以下作为运行脚本来对.xcttest文件夹进行编码。

codesign --verify --force --sign "$CODE_SIGN_IDENTITY" "$CODESIGNING_FOLDER_PATH"

I got a lot of -34018 errors when testing my keychain on the device and this managed to fix it. 在设备上测试我的钥匙串时,我收到了很多-34018错误,并设法解决了这个问题。

If the problem does not exist in your test target this is probably not the solution. 如果您的测试目标中不存在该问题,则可能不是解决方案。

So I guess the solution is: force sign your test target. 所以我猜解决方案是:强制签署您的测试目标。

To answer your question: Yes, I experience the same problem. 回答你的问题:是的,我遇到了同样的问题。 It seems to work fine when running my app. 它似乎在运行我的应用程序时工作正常。 But when I run my XCTests on my device it seems that the keychain returns error -34018. 但是当我在我的设备上运行我的XCTests时,似乎钥匙串返回错误-34018。 The strange thing is that it doesn't happen when I run the tests on the simulator. 奇怪的是,当我在模拟器上运行测试时,它不会发生。

EDIT: I found a solution which I have explained in this answer 编辑:我找到了一个解决方案,我在这个答案中已经解释过了

I got this error when attempting to run keychain operations via Grand Central Dispatch. 尝试通过Grand Central Dispatch运行钥匙串操作时出现此错误。 Find a way to instantiate your keychain (or keychain wrapper) on the main thread. 找到一种在主线程上实例化您的钥匙串(或钥匙串包装器)的方法。

//results in code -34018
   static dispatch_once_t token;
    dispatch_once(&token, ^{
        keychain = [[KeychainWrapper alloc] init];

    });

//works fine
keychain = [[KeychainWrapper alloc] init];

Codesigning a .xctest bundle isn't as easy as it sounds in some cases. 在某些情况下,对.xctest包进行协同设置并不像听起来那么容易。 Principally JorgeDeCorte is right with his answer that the given short line as a Run Script is enough for most of the devs. 主要是JorgeDeCorte的回答是正确的,对于大多数开发者来说,作为Run Script的给定短线是足够的。

codesign --verify --force --sign "$CODE_SIGN_IDENTITY" "$CODESIGNING_FOLDER_PATH"

But when you have multiple certificates in your keychain this will fail with the following line 但是当您的钥匙串中有多个证书时,这将失败并显示以下行

iPhone Developer: ambiguous (matches "iPhone Developer: Your Name (ABC123DEF45)" and "iPhone Developer: Your Name (123ABC456DE)"

A solution to get the right certificate even with multiple ones is this short script. 这个简短的脚本是一个获得正确证书的解决方案,即使是多个证书。 For sure this is not ideal, but as of my knowledge you have no chance to get the certificate that Xcode found and uses for signing your .app. 当然这并不理想,但据我所知,你没有机会获得Xcode发现并用于签署.app的证书。

echo "codesign --verify --force --sign \"$CODE_SIGN_IDENTITY\" \"$CODESIGNING_FOLDER_PATH\""
IDENTITIES=`security find-identity -v -s "Code Signing" | grep "iPhone Developer" | awk '{ print $2 }'`

for SHA in $IDENTITIES; do
    codesign --verify --force --sign $SHA "$CODESIGNING_FOLDER_PATH"
    if [ $? -eq 0 ]; then
        echo "Matching identity found: $SHA"
        exit 0
    fi
done;

exit 1

I also got the "OSStatus error -34018". 我也得到了“OSStatus错误-34018”。 I solved it by recreating my provisioning profile. 我通过重新创建配置文件来解决它。

I was also unable to run tests that involved the Keychain. 我也无法进行涉及Keychain的测试。

What worked for me was adding a "Host Application" for the tests. 对我有用的是为测试添加“主机应用程序”。 You can find this by going to your project targets, tapping "MyTestTarget", click the "General" tab and select a "Host Application" with a drop-down. 您可以通过转到项目目标,点击“MyTestTarget”,单击“常规”选项卡并选择带有下拉菜单的“主机应用程序”来找到它。

I was testing a CocoaTouch Framework so there was no host application for it. 我正在测试CocoaTouch框架,因此没有主机应用程序。 I had to create one (ex. "MyFrameworkTestApp") just for the tests. 我必须为测试创建一个(例如“MyFrameworkTestApp”)。

If that didn't help, you can also try to go to the "Capabilities" tab for the "MyFrameworkTestApp" target and try enabling the "Keychain Sharing" capability. 如果这没有帮助,您还可以尝试转到“MyFrameworkTestApp”目标的“功能”选项卡,并尝试启用“钥匙串共享”功能。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM