The debug build of some code utilizing SFHFKeychainUtils that is working without complaint on the mac which I'm developing on is triggering an error on another mac:
The code makes use of the following methods provided by SFHFKeychainUtils:
+[SFHFKeychainUtils getPasswordForUsername:andServiceName:accessGroup:error:]
+[SFHFKeychainUtils storeUsername:andPassword:forServiceName:accessGroup:updateExisting:updateExisting:error:]
A password is added for a username using +[SFHFKeychainUtils storeUsername:andPassword:forServiceName:accessGroup:updateExisting:updateExisting:error:]. Some time later, an attempt is made to retrieve the password using +[SFHFKeychainUtils getPasswordForUsername:andServiceName:accessGroup:error:]. However, this method is returning the error; its domain is SFHFKeychainUtilsErrorDomain and its code is -25293 (so it is errSecAuthFailed). This error is only returned when a password is in fact stored in the keychain (or at least when it is visible from Keychain Access).
Why is this taking place?
The problem is a lack of code signing. Code signing is required in order for the second machine to access the keychain. The fix was to enable code signing for the debug build.
Related
I have attempted to set up xero-node passing in the consumer key and consumer secret along with the app name as the user Agent. However when I do a test call e.g. xeroClient.core.users.getUsers() the code just seems to freeze not giving any errors however I cannot move any further.
Are you able to post a gist of the code you are using?
What App type are you using (Private, Public or Partner)?
Have you seen the code samples on the main GitHub page? There is also a sample app here: https://github.com/XeroAPI/xero-node-sample-app
Edit:
As of 3/21/2017, even after upgrading from Azure client SDK version 2 to 3.0.1, this is still a problem. So... bump.
I have an Azure Mobile App with custom authentication. I am developing a client for iOS and a client for Windows (VB.NET WinForms).
On iOS, everything works just fine. Registration and Login work, and also a standard API call.
On WinForms, all of the pieces works fine, just not exactly when and how I want (i.e., not all of the time).
Registration works.
Login works.
Standard API call works.
What doesn't work is the standard API call after a Login event.
I have put a console.log() line in my API code, and in all cases, it gets to the line just before the res.json() finishing call.
Here's how I am assigning my user to the client in iOS:
NSString *token = dict[#"token"];
NSString *userId = dict[#"userId"];
MSUser *user = [[MSUser alloc] initWithUserId:userId];
[user setMobileServiceAuthenticationToken:token];
client.currentUser = user;
Here's how I am assigning my user to the client in VB.NET:
Dim token = result.Item("token")
Dim userId = result.Item("userId")
Dim user As New MobileServiceUser(userId)
user.MobileServiceAuthenticationToken = token
MobileService.CurrentUser = user
So, the standard workflow is as follows:
User logs in
Program calls standard API method
On iOS, this works flawlessly. I see the log entry on the API output and it immediately returns the correct information to the iOS app.
On Windows.NET, the following 2 scenarios exist:
If I skip the login process and just call the standard API method (which has been set to access "anonymous"), it works.
If I force the login process and then call the standard API method, the code just hangs forever. The log entry does show up on the API output, but waiting several minutes on the .NET debugger yields no output and no error message. It's just (apparently) hung indefinitely.
So, from what I can tell, the following statements apply:
The API code seems to run the same way every time, no matter which platform is calling the code.
The iOS code seems to run correctly.
Logging in always seems to go fine on either platform.
The .NET code runs fine if the *.json permissions are "anonymous" and no Login attempt has been made.
The .NET code breaks (i.e., hangs indefinitely) if the standard API call is sent after logging in.
This would seem, then, to be related to something happening to the MobileServiceClient during my LoginWithResult method. But, from what I can see, it's the EXACT same code (effectively) on both iOS and Windows.
Does anybody see a flaw in my thinking or code?
I have a custom action which is used to elevate users to be able to log on as a service. This gets run during the installer. It works fine for years on every Windows operating system up until Windows Server 2012. When the below code is run on this version of Windows instead of getting a long back of 0 for success I get a different error code back.
LsaAddAccountRights(
IntPtr PolicyHandle,
IntPtr AccountSid,
LSA_UNICODE_STRING[] UserRights,
long CountOfRights)
The problem is the code appears to be different every time and is a very large number, e.g. 102938473.
I run the error code through the following method to get the error code but this returns a different large number which doesn't appear to be a valid error code.
LsaNtStatusToWinError(long status)
I have tried looking these error codes up, but with no luck. They seem to be randomly generated and nonsensical.
If I ignore the returned error code, It appears that the user is successfully allowed to log on as a service. So everything appears to be working, except I am getting an error code back. I could ignore this error code, but what happens when it is a valid error, I may ignore it in the future.
Extra Information
I can run the code that is in the Custom action fine on its own in a console application without error. Only when it is part of the wix installer it seems not to work.
I'd take a look at the WiX Util extensions's User element. The name attribute can be a property. Using the CreateUser, LogonAsService and UpdateIfExists attributes you can take an existing account and grant it the rights. Or perhaps you have more code that you can refactor.
Issue could be with the return type of LsaAddAccountRights in C#.
I was able to solve the issue by changing the return type of LsaAddAccountRights in C# from long to UInt32. Found this information here . This change must be done for LsaNtStatusToWinError and LsaClose as well.
This question already has answers here:
How to obtain codesigned application certificate info
(2 answers)
Closed 8 years ago.
I have app signed. I created an identity and used codesign to sign my app as per Apple's Code Signing Guide.
Now, how do I check the signature from within my application?
I need to verify this on Cocoa apps (Objective-C) and apps written in C.
You could use NSTask and run "codesign --verify" and check the exit status. Of corse if the program was altered it could be altered to remove the check, so I'm not sure what that buys you.
If you are not worried about directed tampering (like the kind that might remove your check of the signature) you can use the codesign "kill" option, if you do merely executing means the signature is valid (at least for all pages that have been executed so far...but if a not-yet-resident page has been tampered with you will get killed when that one is read in anyway).
Maybe if you could explain a little more about why you want to verify the signature a better answer could be formed.
Note: Currently MacOS X does not verify signed code prior to execution. This may be different for sandboxed code, and it would seem sensible that it is otherwise anybody could edit the entitlements.
To check an applications signature from within the application itself you use the Code Signing Services. In particular look at SecCodeCheckValidity. The code to do the checking is not long, but there is quite a bit to understand so I won't give a code sample - you need to read and understand the documentation.
Checking the signature allows your application to detect changes to its code & resources and report it is "damaged" (it may well be, not all changes are malicious) and refuse to run. Adding such code does not of course guarantee your code is not damaged, but certainly it does raise the barrier higher against intentional damage (and if MacOS X starts doing the check itself then there will be a big win).
The way signiture verification is implemented on iOS is that when an application is being launched, the launchd daemon decrypts the binary using that device's specific private key (this is why you can't just decompile apps or copy-paste them from one device to another), if the decryption fails, the application fails to launch.
The native tools that do this are not available within applications due to the iOS sandboxing.
If you're simply attempting to track if someone has modified your binary, you can perform an MD5 or SHA1 hash of it, store it in NSUserDefaults and compare it at each app start. If the hash changes between executions you know it has been modified (possibly by a legitimate application update or possibly nefariously.)
Here's an example on how to get the hash of an NSData.
The binary file you're looking for is: AppName.app/AppName
Ok. I know. This has been covered 100^1000 times here and everywhere, but I have been trying to create my .ipa for submission for the past week (not kidding, thats how much I spent working on just this) and I keep getting this warning. BTW - not sure it makes a difference, but thats an iPad app.
I am getting this warning:
warning: Application failed codesign verification. The signature was invalid, or it was not signed with an iPhone Distribution Certificate. (-19011)
Executable=/Users/username/Library/Developer/Xcode/DerivedData/JudgeIt-ebfrsivdbrxukqhbupfnzzqgoftd/ArchiveIntermediates/JudgeIt/IntermediateBuildFilesPath/UninstalledProducts/JudgeIt.app/JudgeIt
codesign_wrapper-0.7.10: using Apple CA for profile evaluation
Illegal entitlement key/value pair: com.apple.developer.ubiquity-kvstore-identifier, 6366MSW2TK.com.JudgeIt.JudgeIt
Illegal entitlement key/value pair: com.apple.developer.ubiquity-container-identifiers, {type = mutable-small, count = 1, values = (
0 : {contents = "6366MSW2TK.com.JudgeIt.JudgeIt"}
)}
AssertMacros: filter_entitlements(entitlements_whitelist, entitlements_requested, allowable_entitlements), file: codesign_wrapper.c, line: 932
- (null)
I tried:
Delete all the certificates and keys and start all over again
Unistall Xcode
Restarting my computer
Deleting build library
Cleaning project
Also attaching a screenshot of the Code Signing setting of my project - looks ok to me.
UPDATES:
- I am using Xcode 4.2
- All certificates on Keychain are valid and I have one of each (developer, distribution, AWDR)
This might sound totally stupid, but that was the failure message when I wanted to validate my archive yesterday while submitting an app. I had used a "+" sign in the bundle name, and that was the problem source!! Renaming the required fields, I didn't get the code sign error anymore!!