I found out that AuthenticationServices doesn't like an attestation object in the "packed" format, but it accepts only one with the "none" format....
ampm
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
From
Burlington, MA, United States
Post
Replies
Boosts
Views
Activity
Hi Quinn,
what is the purpose of this setting? When I use it, the background of the user desktop behind the application windows turns white (instead of showing the wallpaper) and if I click on it all the windows are moved out of the visible space.
Thanks,
Alberto
Chiming in late, but I too filed FB12566615 on Jul 10 against Beta 3, and confirmed it was still present when I was asked if it was still a valid bug in the RC. I hope it gets fixed in the 14.1 release, even if the beta doesn't....
Alberto
I had already filed in 2022 as FB10755765
I updated to Beta9 today, and FB8711128 “UI derived from SFAuthorizationViewPlugin isn’t displayed properly” is fixed; however, custom UI cannot cycle property between credential and identity views, so I filed FB8758186.
The other feedback I filed, FB8710105 “Login window never advances past custom authorization plugin written in Objective-C”, still crashes because it attempts to invoke the viewForType method (as if the custom plugin created an UI, but it didn't)
I checked with Beta 7 today, and the issues are still present, so I filed them: FB8710105 “Login window never advances past custom authorization plugin written in Objective-C”
FB8711128 “UI derived from SFAuthorizationViewPlugin isn’t displayed properly”
Thanks
We too see several problems with the authorization plugin:
1) a custom UI deriving from SFAuthorizationPluginView doesn't resize, but is constrained to stay in the 31 pixels that are normally used by the password field shown by the loginwindow
2) when the plugin uses SetResult to make the authentication process advance, nothing happens; I also made an experiment with a custom plugin that immediately calls SetResult in the MechanismInvoke, and the boot is left stuck at 25%. The syslog shows a message "loginwindow[120] <Notice>: There is still an active connection" that hints that the boot thinks something is still working.