Tag: Carbon

You see those pesky authorization dialogs every so often, right? "Finder requires that you type your password." "BBEdit requires that you type your password." This means the application involved is using the Security framework to perform an action with, say, administrative privileges that it wouldn’t normally have.

If you turn down the Details disclosure triangle in such a dialog, you see the name of the app and an arcane Requested Right string.

These rights should be added to what’s called the "policy database," stored in the file /etc/authorization, when the application that wants to use them is first installed. For a full explanation, see Performing Privileged Operations With Authorization Services, but for this post, I’m interested in the API you use to add those rights.

Here’s the example given in the AuthorizationDB.h header in the Security framework.

OSStatus status =
   AuthorizationRightSet(
      NULL, 
      "com.ifoo.ifax.send",
      CFSTR(kAuthorizationRuleIsAdmin),
      CFSTR("Authorize sending of a fax"),
      NULL,
      NULL);

Looks reasonable, right?

Bzzzt. Sorry! If you actually try to run this code, at least on Mac OS X 10.4 "Tiger," you get a −2147418108 error. What’s a −2147418108 error? No clue. But it’s not good.

The first parameter is of type AuthorizationRef. You get a valid authorization reference if the user types her password into one of those dialogs, but you don’t need special permission to add a new right to the policy database. Hence the null value in the example. But it doesn’t work.

Here’s what you need to do instead:

AuthorizationRef authorization = NULL;

OSStatus result =
   AuthorizationCreate(
      NULL, NULL,
      kAuthorizationFlagDefaults,
      &authorization);

if (result == noErr)
{
   result =
      AuthorizationRightSet(
         authorization,
         "com.ifoo.ifax.send",
         CFSTR(kAuthorizationRuleAuthenticateAsAdmin),
         CFSTR("Authorize sending of a fax"),
         NULL,
         NULL);

   AuthorizationFree(
      authorization,
      kAuthorizationFlagDefaults);
}

AuthorizationCreate() actually has a whole bunch of options you can use, but here I’m using it with minimal values to create a blank, good-for-nothing AuthorizationRef. Even so, that’s good enough for AuthorizationRightSet(). With this code, there’s no −2147418108 error.

So we’re done? Not yet!

You’ll notice above that I changed the third, "rule" parameter of AuthorizationRightSet() from the kAuthorizationRuleIsAdmin in the original sample to kAuthorizationRuleAuthenticateAsAdmin. With that rule, you are shown an authorization dialog when I use AuthorizationCreate() like so:

AuthorizationItem myItems =
   { "com.ifoo.ifax.send", 0, NULL, 0 };

AuthorizationRights myRights =
   { 0, &myItems };

AuthorizationFlags myFlags =
   kAuthorizationFlagInteractionAllowed |
   kAuthorizationFlagExtendRights;

AuthorizationRef authorization = NULL;

OSStatus result =
   AuthorizationCreate(&myRights, kAuthorizationEmptyEnvironment,
      myFlags, &authorization);

This call’s a lot more complicated, eh? But it boils down to trying to get a valid authorization for the right we added.

Here’s the dialog you see in response:

Oops! If you fill in the fourth, "description key" parameter of AuthorizationRightSet() with a string as shown in the header example, that "description key" is concatenated with the default system prompt in any authorization dialog that refers to that right.

Passing NULL for the "description key" parameter uses just the default system prompt, which works much better.

Now we’re done.

There’s no dedicated widget in Cocoa for specifying and displaying a file.

Both Cocoa and Carbon apps tend to cobble together custom UI for the task. A “Save” or “Open” button that triggers a Navigation Services dialog, plus a path text field, and sometimes an icon. Apps tend to be internally consistent – CodeWarrior uses the same aggregate widget everywhere, for instance – but none of them quite match each other.

Cocoa apps often do let you edit the path by hand. It seems to me that this reflects the greater NeXT reliance on the command line, and I can see the utility of it sometimes. But I dislike the potential to erase a path by hitting the delete key by mistake. It also seems to me that this sort of thing is better suited to developer apps, where the user can more safely be assumed to have command line expertise.

Carbon apps, with the old Toolbox deprecation of file paths, generally never allow users to type in the path of the file they want: you must use the Open or Save dialogs to specify the file, though the application might then show you the path afterward.

I can actually see something in-between: maybe in the Save/Open dialog, there is a text field, which reflects the full path of the file/folder you’ve currently chosen. You can type in it, and once a name matches, the Navigation Services portion of the dialog moves to that location specified by your typing. Maybe that’s overkill, but it is the kind of marriage of command-line and UI that I’d really like to see. Toss in tab-completion, and you’re all set!

I’m thinking about this because I’m thinking about how I would modify the UI of TADS Workbench for Macintosh if (more like when) I decide to take over its maintenance. I had my own widget in my Isthmus framework to specify and show a file – I even had a specialization of that widget to deal with special file paths, like the “{Compiler}” and “{Project}” paths in CodeWarrior. I will either have to redo that work for TADS Workbench, discard the concept completely, or – most likely – figure out a more scaled-down version. After all, it was trying to make things perfect that doomed Isthmus.