Post not yet marked as solved
Does Apple allow extensions to Face ID?
I have a problem with the way it often reacts.
I also have a simple solution.
But does Apple allow extensions to Face ID?
Post not yet marked as solved
If someone in Apple WWDR sees this, please take the feedback to heart and report it up the chain:
When you announce that a technology is being deprecated — such as CGDisplayStream — and also publish WWDC sessions about the intended replacement — ScreenCaptureKit — then you also need to give third-party developers a clear deadline by which this technology will be deprecated so that they can plan engineering efforts around implementing the new feature, and have ample time to communicate this to their customers. If it's important for third-party developers to get on board with this change, you should use every available means to communicate this to them, including multiple email alerts to their registered email address.
Additionally, if you plan to make a BREAKING change in a framework that results in a wildly different user experience, you should probably hold that off until the summer release for the next major OS.
What you should definitely NOT do is roll out a new privacy prompt in a mid-year release of macOS; or give your developers, customers, and AppleSeed program participants zero advance notice that this alert is coming, ignore your own Human Interface Guidelines when designing said prompt, and perform no user experience design testing (aka "putting on your customer hat") during a presumed internal alpha testing cycle to refine the experience and still find the most effective and least annoying way to present this additional prompt and spur change with your third-party developers.
Oh, wait, you've done exactly all those things the wrong way with respect to ScreenCaptureKit.
Right now, a host of Apple device administrators and client platform engineers are sending mountains of feedback to you, and they're also scrambling to contact third-party developers to let them know this is coming. Most of the vendors being discussed in private forums are said to be caught off guard by this change.
We anticipate that users are not going to like this, and there is no way we can manage it with MDM or configuration profiles. In short, the current experience is a ghastly mess. WE, the administrators, will get blamed for this, not the third-party developers. WE will have to explain to our leadership why this experience is terrible and cannot be managed.
Engineers need deadlines to help plan their work and prioritize tasks. In this case, vendors have had no firm deadline for this effort. There's already precedence for Apple announcing estimated deadlines for deprecations and feature removals. You do your developers and customers a great disservice by not communicating schedules to them.
Please do better.
P.S.: Feedback filed as FB13619326.
Post not yet marked as solved
On recent macOS versions(Sonoma or previous), if system.login.screensaver is updated to use “authenticate-session-owner-or-admin” then fancy screensaver is not coming up, instead we are seeing only black screensaver ( black screen).
Note: Observed we are getting fancy screensavers with this setting on macOS BigSur.
Can you please let us know if this is an intentional change from macOS or we have any settings to enable to get fancy screensavers with recent macOS versions?
Thanks & Regards,
Tata Chaitanya
Post not yet marked as solved
Hi there,
I’m having issue using Apple’s API. I can’t initialize SFAuthorizationPluginView using Swift.
I’ve done numerous google searches, but haven’t found any examples/tutorials of anyone using Swift for SFAuthorizationPluginView / AuthorizationPluginCreate.
I managed to get the AuthorizationPlugin and AuthorizationMechanism up, but simply creating the SFAuthorizationPluginView fails the failable initiator.
https://developer.apple.com/documentation/securityinterface/sfauthorizationpluginview
Here are some log messages I wrote:
error 16:08:33.689244-0800 kernel Library Validation failed: Rejecting '/Library/Security/SecurityAgentPlugins/XXXAgent.bundle/Contents/MacOS/XXXAgent' (Team ID: 7X6364JT77, platform: no) for process 'SecurityAgentHel(2689)' (Team ID: N/A, platform: yes), reason: mapping process is a platform binary, but mapped file is not
error 16:08:33.689501-0800 SecurityAgentHelper-arm64 Error loading /Library/Security/SecurityAgentPlugins/XXXAgent.bundle/Contents/MacOS/XXXAgent (78): dlopen(/Library/Security/SecurityAgentPlugins/XXXAgent.bundle/Contents/MacOS/XXXAgent, 0x0106): tried: '/Library/Security/SecurityAgentPlugins/XXXAgent.bundle/Contents/MacOS/XXXAgent' (code signature in <BFF0D7BA-5CF8-3F2F-A604-DCC235499234> '/Library/Security/SecurityAgentPlugins/XXXAgent.bundle/Contents/MacOS/XXXAgent' not valid for use in process: mapping process is a platform binary, but mapped file is not), '/System/Volumes/Preboot/Cryptexes/OS/Library/Security/SecurityAgentPlugins/XXXAgent.bundle/Contents/MacOS/XXXAgent' (no such file), '/Library/Security/SecurityAgentPlugins/XXXAgent.bundle/Contents/MacOS/XXXAgent' (code signature in <BFF0D7BA-5CF8-3F2F-A604-DCC235499234> '/Library/Security/SecurityAgentPlugins/XXXAgent.bundle/Contents/MacOS/XXXAgent' not valid for use in process: mapping process is a platform binary, but mapped file is not)
default 16:08:33.760679-0800 SecurityAgentHelper-arm64 callbacks: Optional(0x00000001001b1f88)
default 16:08:33.760710-0800 SecurityAgentHelper-arm64 andEngineRef: Optional(0x0000000156f384d0)
error 16:08:33.762404-0800 SecurityAgentHelper-arm64 Test API call result: OSStatus 0 i.e. No error.
error 16:08:33.763298-0800 SecurityAgentHelper-arm64 Failed to create Authorization Plugin Adapter
default 16:08:33.763524-0800 authd engine 66: running mechanism XXXAgent:XXXAgentMechanism (1 of 1)
Here is the calling code with the error message:
class AuthorizationMechanismXXX : AuthorizationMechanism
{
let mLogger = …
let mAuthorizationPluginView : AuthorizationPluginViewAdapter?
override init(inPlugin: UnsafeMutablePointer<AuthorizationPlugin>,
inEngine: AuthorizationEngineRef,
inMechanismId: AuthorizationMechanismId)
{
…
let pCallbacks : UnsafePointer<AuthorizationCallbacks> = inPlugin.pointee.EngineCallback()
self.mAuthorizationPluginView = AuthorizationPluginViewAdapter(callbacks: pCallbacks, andEngineRef: inEngine)
if (self.mAuthorizationPluginView == nil)
{
mLogger.error("Failed to create Authorization Plugin Adapter")
}
super.init(inPlugin: inPlugin, inEngine: inEngine, inMechanismId: inMechanismId)
}
Here is the class:
class AuthorizationPluginViewAdapter : SFAuthorizationPluginView
{
let mLogger = …
let mLoginView = NSHostingView(rootView: LoginView())
override init!(callbacks: UnsafePointer<AuthorizationCallbacks>!, andEngineRef engineRef: AuthorizationEngineRef!)
{
mLogger.notice("callbacks: \(callbacks.debugDescription, privacy: .public)")
mLogger.notice("andEngineRef: \(engineRef.debugDescription, privacy: .public)")
var sessionId: UnsafeMutablePointer<AuthorizationSessionId?>?
let result = callbacks.pointee.GetSessionId(engineRef, sessionId)
LogSecurityOSStatus(logger: mLogger, osStatus: result, message: "Test API call result")
super.init(callbacks: callbacks, andEngineRef: engineRef)
mLogger.notice("Never gets here")
}
override func buttonPressed(_ inButtonType: SFButtonType)
{
if (inButtonType == SFButtonTypeOK)
{
let osStatus = callbacks().pointee.SetResult(engineRef(), AuthorizationResult.allow)
if (osStatus != errSecSuccess)
{
LogSecurityOSStatus(logger: mLogger, osStatus: osStatus, message: "Error setting authorization result")
}
}
else if (inButtonType == SFButtonTypeCancel)
{
let osStatus = callbacks().pointee.SetResult(engineRef(), AuthorizationResult.deny)
if osStatus != errSecSuccess
{
LogSecurityOSStatus(logger: mLogger, osStatus: osStatus, message: "Error setting authorization result")
}
}
else
{
mLogger.error("Invalid buttonType.")
}
}
override func view(for inType: SFViewType) -> NSView!
{
if (inType == SFViewTypeIdentityAndCredentials)
{
mLogger.debug("Identity and credentials")
}
else if (inType == SFViewTypeCredentials)
{
mLogger.debug("Credentials only")
}
else
{
mLogger.error("Invalid buttonType.")
}
return mLoginView
}
}
Here is the view:
import SwiftUI
struct LoginView: View {
var body: some View {
Text(/*@START_MENU_TOKEN@*/"Hello, World!"/*@END_MENU_TOKEN@*/)
}
}
#Preview {
LoginView()
}
Post marked as Apple Recommended
On Sonoma beta 7, if system.login.screensaver is updated to use “authenticate-session-owner-or-admin”, and then Lock Screen is not hiding the macOS Desktop.
Step1. Update system.login.screensaver authorizationdb rule to use “authenticate-session-owner-or-admin”( to get old SFAutorizationPluginView at Lock Screen ).
Step 2. Once the rule is in place after logout and login, now click on Apple icon and select “Lock Screen”.
Even after selecting Lock Screen, complete macOS Desktop is visible with no control for the user to unlock the screen. To gain access we have to restart the MAC.
Post not yet marked as solved
I am having trouble creating a CSR to renew a SecIdentity whose private SecKey is stored in slot 9d of a smartcard.
For slot 9a, I am able to accomplish this by way of SecKeyCreateSignature using CertificateSigningRequest from a gently-modified fork of swift-certificates/swift-crypto to sort out all the details.
But for the SecKey associated with slot 9d, the Security framework instantly returns an "algorithm not supported by the key" error when I call SecKeyCreateSignature, without even prompting for a PIN.
I believe the difference is that kSecAttrCanSign is true for slot 9a but false for slot 9d. The value makes some sense for day-to-day usage because this identity is usually not used for signing, but if we are to occasionally sign a CSR for this key an exception would need to be made.
Is there any way to basically force this exception with the Security framework? Again the actual private key material is not available so the only access as far as I'm aware is via the enumerated SecKey reference. Is there any way to SecKeyCreateWithData a secondary reference to the same underlying (but unexportable!) key but with allowed-usage attributes of my own choosing?
Post not yet marked as solved
Hello,
I made a mechanism that shows my custom user interface in the lock screen of MacOS by using the example in https://developer.apple.com/library/archive/samplecode/NameAndPassword/
The UI is being displayed as required and working perfectly. But it will automatically gets removed form display when there is no input from user for 30 seconds.
I need to prolong that time as I need to support multiple factor verifications such as push notification(where user need to accept push notification in mobile device rather than in mac), security key(where user needs to insert and tap a security device without needing to give any input in keyboard or trackpad).
Please suggest me any solution regarding the ways to achieve this. Any information is appreciated.
Thank you.
Post not yet marked as solved
Has anyone managed to ui test an authorization plugin that is based on SFAuthorizationPluginView?
I have searched on the internet and nothing shows up. I know that if we open separate windows in a mechanism that's not based on SFAuthorizationPluginView we can create a standalone app for those windows and ui test them, but it would be great if we could UI test whole flows, beginning with SFAuthorizationPluginView / built in login window and then continue on our own windows in further mechanisms.
What I tried:
XCUITest needs an XCUIApplication to oparete on. But what is the application here? I'd assume it's SecurityAgentHelper-x86_64 (based on accessibility inspector that is the root ancestor of my window: SecurityAgentHelper-x86_64 > Login (window) > [my text field]). But that is an XPC process, which brings me to my next point:
I don't think xpc processes can be the target application in XCUIApplication's init.
The
init(bundleIdentifier: "com.apple.SecurityAgentHelper.x86_64")
call crashes with app not found, while the
init(url: URL(string: "/System/Library/Frameworks/Security.framework/Versions/Current/MachServices/SecurityAgent.bundle/Contents/XPCServices/SecurityAgentHelper-x86_64.xpc")!)
call simply hangs forever, then times out. Based on the Accessibility Inspector hierarchy this app is the host application which should be opened.
Without a main XCUIApplication it is impossible to start querying UI elements for UI tests, so I am stuck here.
Post not yet marked as solved
Hi,
I have experienced undocumented changes in the behavior of SFAuthorizationPluginView and Authorization Plug-ins while testing our Auth Plugin under macOS Sonoma Beta 3 (latest seed as of today).
Prerequisites:
macOS Sonoma Beta 3
Settings > Lock Screen > Login window shows: List of Users
Note: it is visible the login screen changed in behavior, this can be noticed even without the installation of any authorization plugin. There is now a default selected user with the password field always visible. Up until Ventura, a user had to be picked manually first to then open up their login password textfield.
After logout I noticed that the order of delegate methods have changed.
Previously, until macOS Ventura the order of methods seemed to be:
displayView() --> viewForType() --> view.viewDidLoad() --> willActivateWithUser() --> firstResponder --> didActivate()
where view is my custom NSViewController.view embedded in the SFAuthorizationPluginView. viewDidLoad is called because my implementation of viewForType returns view - which in turn should call loadView() based on documentation for NSViewController.view:
If this property’s value is not already set when you access it, the view controller invokes the loadView() method.
Now it seems that the order has changed:
displayView() --> didActivate() --> firstResponder
This means that viewForType(), willActivateWithUser() are not called. And then my console application crash log shows that the application crashed at firstResponder, probably because view.viewDidLoad() is not called for my view due to viewForType() not being called either.
Has anyone met a similar issue? This really seems like an undocumented change.
macOS Ventura 13.3, plugin built with XCode 14.3.1 -> our app works
macOS Sonoma 14.0 Beta3, plugin built with XCode 14.3.1 -> our app does not work
macOS Sonoma 14.0 Beta3, plugin built with XCode 15.0 Beta4 -> our app does not work
P.S.: I do see methods new in macOS Sonoma appeared for NSViewController, like loadViewIfNeeded - but sadly these new methods have zero documentation attached.
P.S #2: I have checked with a minimal repro example, and the order has indeed changed. When the view does not have to be loaded via an NSViewController, i can see the full new order:
displayView() --> didActivate() --> firstResponder --> viewForType() --> willActivateWithUser() --> didActivate() (called twice??) --> firstResponder --> firstResponder
This above order of calls is without a single user interaction, just logging out (or using security authorize -u system.login.console from the terminal)
Michael_L_Cozad.
