Re: Updating localised auth-prompt strings
Oops, sorry! I'm using Objective-C, targeting macOS 10.10+ > On 15 Jun 2020, at 9:41 pm, Alex Zavatone wrote: > > Platform? > >> On Jun 15, 2020, at 9:51 AM, Mark Allan via Cocoa-dev >> wrote: >> >> Hi folks, >> >> I have an app which communicates with a privileged helper tool, and I used >> the AuthorizationRightSet API to add the rights, requirements, and prompt >> strings to the authorizationdb - as per Apple's documentation. As expected, >> this initial call to "AuthorizationRightSet" does not prompt for >> authentication to add the rights to the DB. >> >> Some of my app's functions require presenting an authentication prompt to >> the user, and these prompts have been localised. >> >> Calling 'sudo security authorizationdb read' in the Terminal shows the rule, >> the default prompt, and all the localised versions of the prompt string. >> >> All fine so far, but I've recently reworded some of the authentication >> prompt strings, so it (and all the localisations) now need to be updated. >> >> How do I do this? Naively I thought I could just update the respective >> localizable.strings file, and it would just work, but as the translated text >> is hard-coded into the authorizationdb, this doesn't seem possible. >> >> Using AuthorizationRightSet again will cause an authentication prompt to >> appear as soon as my app is launched. As does AuthorizationRightRemove. >> >> Now, I know I could remove all my rights from the authorizationdb by calling >> "sudo security authorizationdb remove XYZ" for each of my app's rights, but >> I obviously can't expect users to do this. Neither do I want them to be >> presented with an auth prompt purely to update some strings. >> >> I could also just change the auth right name so that the app proceeds as if >> that particular right had never been in the database in the first place, but >> that seems like a nasty hacky way to do it. >> >> so, where does this leave me? I can't be the only person who's come up >> against this issue, but web searches and StackOverflow aren't giving me much >> to go on. >> >> Many thanks >> Mark ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Updating localised auth-prompt strings
Platform? > On Jun 15, 2020, at 9:51 AM, Mark Allan via Cocoa-dev > wrote: > > Hi folks, > > I have an app which communicates with a privileged helper tool, and I used > the AuthorizationRightSet API to add the rights, requirements, and prompt > strings to the authorizationdb - as per Apple's documentation. As expected, > this initial call to "AuthorizationRightSet" does not prompt for > authentication to add the rights to the DB. > > Some of my app's functions require presenting an authentication prompt to the > user, and these prompts have been localised. > > Calling 'sudo security authorizationdb read' in the Terminal shows the rule, > the default prompt, and all the localised versions of the prompt string. > > All fine so far, but I've recently reworded some of the authentication prompt > strings, so it (and all the localisations) now need to be updated. > > How do I do this? Naively I thought I could just update the respective > localizable.strings file, and it would just work, but as the translated text > is hard-coded into the authorizationdb, this doesn't seem possible. > > Using AuthorizationRightSet again will cause an authentication prompt to > appear as soon as my app is launched. As does AuthorizationRightRemove. > > Now, I know I could remove all my rights from the authorizationdb by calling > "sudo security authorizationdb remove XYZ" for each of my app's rights, but I > obviously can't expect users to do this. Neither do I want them to be > presented with an auth prompt purely to update some strings. > > I could also just change the auth right name so that the app proceeds as if > that particular right had never been in the database in the first place, but > that seems like a nasty hacky way to do it. > > so, where does this leave me? I can't be the only person who's come up > against this issue, but web searches and StackOverflow aren't giving me much > to go on. > > Many thanks > Mark > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com > > This email sent to z...@mac.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Launching another app from mine
Mac, iOS, WatchOS, iPadOS? TRS-80 Basic? Which platform? > On Jun 15, 2020, at 1:30 PM, Gabriel Zachmann via Cocoa-dev > wrote: > > I would like to launch application B from my application A using Swift. > Both applications are created, compiled, signed, and notarized by me. > Challenge: no user intervention should be necessary when launching B from A. > > Is that possible? > > Best regards, Gabriel > > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com > > This email sent to z...@mac.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Launching another app from mine
On Jun 15, 2020, at 2:30 PM, Gabriel Zachmann via Cocoa-dev wrote: > > I would like to launch application B from my application A using Swift. > Both applications are created, compiled, signed, and notarized by me. > Challenge: no user intervention should be necessary when launching B from A. > > Is that possible? NSWorkspace does this. Look at the launchApplication method. You can get the app name from the bundle identifier using the NSWorkSpace URLForApplicationWithBundleIdentifier method. Jim Crate ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Launching another app from mine
Deep link? URL scheme. If the app being linked to isn’t installed, I think it’s a silent “error”. (sent from my iPhone) From: Gabriel Zachmann via Cocoa-dev Sent: Monday, June 15, 2020 2:30:55 PM To: cocoa-dev@lists.apple.com Subject: Launching another app from mine I would like to launch application B from my application A using Swift. Both applications are created, compiled, signed, and notarized by me. Challenge: no user intervention should be necessary when launching B from A. Is that possible? Best regards, Gabriel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Launching another app from mine
I would like to launch application B from my application A using Swift. Both applications are created, compiled, signed, and notarized by me. Challenge: no user intervention should be necessary when launching B from A. Is that possible? Best regards, Gabriel smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Updating localised auth-prompt strings
Hi folks, I have an app which communicates with a privileged helper tool, and I used the AuthorizationRightSet API to add the rights, requirements, and prompt strings to the authorizationdb - as per Apple's documentation. As expected, this initial call to "AuthorizationRightSet" does not prompt for authentication to add the rights to the DB. Some of my app's functions require presenting an authentication prompt to the user, and these prompts have been localised. Calling 'sudo security authorizationdb read' in the Terminal shows the rule, the default prompt, and all the localised versions of the prompt string. All fine so far, but I've recently reworded some of the authentication prompt strings, so it (and all the localisations) now need to be updated. How do I do this? Naively I thought I could just update the respective localizable.strings file, and it would just work, but as the translated text is hard-coded into the authorizationdb, this doesn't seem possible. Using AuthorizationRightSet again will cause an authentication prompt to appear as soon as my app is launched. As does AuthorizationRightRemove. Now, I know I could remove all my rights from the authorizationdb by calling "sudo security authorizationdb remove XYZ" for each of my app's rights, but I obviously can't expect users to do this. Neither do I want them to be presented with an auth prompt purely to update some strings. I could also just change the auth right name so that the app proceeds as if that particular right had never been in the database in the first place, but that seems like a nasty hacky way to do it. so, where does this leave me? I can't be the only person who's come up against this issue, but web searches and StackOverflow aren't giving me much to go on. Many thanks Mark ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
