NSService (aka. Bonjour) outside local network

[Gerriet M. Denkmann]

Is it possible to create an NSService (OS X 10.11.45) which is discoverable 
(via NSServiceBrowser) outside of the local WiFi network?
What should be used for domain in this case?
If not: what is the use of domain ≠ “local.” , e.g. domain = “” ?

Also: I noticed that includesPeerToPeer = YES makes the kernel_task, which 
usually takes about 1% of my Cpu, go up to 11%. Back to 1% one minute after the 
app with NSService quits.

Is this normal and to be expected?

Gerriet.


___

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: NSArrayController - error inserting object at arranged object index N

[Jonathan Mitchell]

> On 23 Jun 2016, at 23:03, Quincey Morris 
>  wrote:
> 
> On Jun 23, 2016, at 13:39 , Jonathan Mitchell  > wrote:
>> 
>> Do you mean something like this?
>> NSMutableArray *proxy = [NSArrayController 
>> mutableArrayValueForKey:@"content"];
> 
> That wasn’t what I had in mind. I meant that you would make the array a 
> property of a real model object, and update *that* property, without 
> referring to the array controller directly at all. If you do a KVO compliant 
> update under those circumstances, the array controller will get a KVO 
> notification and update its internal state automatically. You shouldn’t need 
> to re-filter manually.
> 
Okay. I see what you mean now.
Yes - I think that would work.

The downside would be having to implement the compliant accessor methods in the 
real model object (in my case the array is a constructed property of an 
NSViewController subclass which obtains its array data from a non native Obj-C 
model)
This would be beneficial if the array property was also being observed 
externally.

My usage case scenario is mainly bindings based and so the NSArrayController 
provides an effective and concise means of providing a KVO compliant to-many 
property to the likes of NSTableView etc. I think this is the essence point you 
were making about using NSArrayControllers in code previously. I find them 
hugely useful for UI related bindings. Outside of that their utility is less 
obvious.

Thanks for taking the time and effort to respond to this - i definitely 
improved my knowledge by thinking about your points.
KVO compliance for to-many properties was always something I was a bit wooly 
about and I suspect that many others will be too,
IMHO getting to grips with this is one of the most difficult aspects of AppKit.

J
___

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: NSArrayController - error inserting object at arranged object index N

[Quincey Morris]

On Jun 24, 2016, at 03:12 , Jonathan Mitchell  wrote:
> 
> The downside would be having to implement the compliant accessor methods in 
> the real model object (in my case the array is a constructed property of an 
> NSViewController subclass which obtains its array data from a non native 
> Obj-C model)

It’s not much of a downside once you get to this point. You can do it either 
the easy way or the good way:

a. If you have a NSMutableArray instance variable with the name of the property 
(with or without a leading underscore), the ‘mutableValueForKey:’ mechanism 
will access it automatically, and you don’t have to write any code. This 
supposes that you did not set ‘accessInstanceVariablesDirectly’ to NO for the 
class that has the array property.

b. You can write just the ‘insert…’ and ‘remove…’ accessor methods. The trick 
is to define the @property first, and then use autocomplete (typing ‘insert’ 
and ‘remove’) to get the correct method signature written for you — I can never 
remember it without looking it up otherwise. The method implementations can be 
as short as 1 line.

For case (b), I also tend to provide an extra piece that hides the 
‘mutableValueForKey:’ part. I declare the property this way:

@property (readonly) NSArray* myProperty;
@property (readonly) NSMutableArray* mutableMyProperty; // <— simply 
returns ‘[self mutableArrayValueForKey: @“myProperty”]'

Note that these are both readonly, to avoid giving client code accidental 
readwrite access to the instance variable that backs the property. However, you 
don’t really need this is the access mechanism is via KVC (e.g. bindings). It’s 
more of a convenience for client code.

___

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

How to pre-select a file in NSOpenPanel -- specifically, a .app bundle?

[Andy Lee]

How do I present an NSOpenPanel with a particular file pre-selected?

I can pre-select a *directory* by setting openPanel.directoryURL.  Since the 
file I want to select is actually a .app bundle, which is really a directory, 
you might think I'm in luck, but not quite.

Here's the code I tried:

NSOpenPanel *openPanel = [NSOpenPanel openPanel];
openPanel.treatsFilePackagesAsDirectories = NO;
openPanel.allowsMultipleSelection = NO;
openPanel.canChooseDirectories = NO;
openPanel.canChooseFiles = YES;
openPanel.resolvesAliases = YES;
openPanel.allowedFileTypes = @[@"app"];
openPanel.allowsOtherFileTypes = NO;

NSString *appBundlePath = @"/Applications/TextEdit.app";
openPanel.directoryURL = [NSURL fileURLWithPath:appBundlePath];
[openPanel beginSheetModalForWindow:self.window
  completionHandler:^(NSInteger result) {
  NSLog(@"Result is %zd", result);
  }];

When I run this, the good news is that TextEdit.app gets selected.  The bad 
news is that it is treated as a regular directory, and its "Contents" 
subdirectory is exposed in the file browser:



If I click away, then click back on TextEdit, I get what I wanted in the first 
place:



I've tried workarounds that Google turned up.  One was to use URLWithString: 
rather than fileURLWithPath:.  Another was to go ahead and call a deprecated 
method like beginSheetForDirectory.  These may have worked once upon a time, 
but they don't for me on 10.11.5.

It almost looks like the ability to pre-select a file was deliberately removed 
from the NSOpenPanel API.  Could that be the case?

--Andy


___

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: NSService (aka. Bonjour) outside local network

[Kyle Sluder]

On Fri, Jun 24, 2016, at 02:11 AM, Gerriet M. Denkmann wrote:
> Is it possible to create an NSService (OS X 10.11.45) which is
> discoverable (via NSServiceBrowser) outside of the local WiFi network?

Only if your machine is configured for Wide-area Bonjour. Regular
Bonjour is restricted to the local subnet.

> What should be used for domain in this case?

Whatever WAB domain(s) are configured on the machine.

The macnetworkprog list might be a better resource.

--Kyle Sluder

> If not: what is the use of domain ≠ “local.” , e.g. domain = “” ?
> 
> Also: I noticed that includesPeerToPeer = YES makes the kernel_task,
> which usually takes about 1% of my Cpu, go up to 11%. Back to 1% one
> minute after the app with NSService quits.
> 
> Is this normal and to be expected?
> 
> Gerriet.

___

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: How to pre-select a file in NSOpenPanel -- specifically, a .app bundle?

[Quincey Morris]

On Jun 24, 2016, at 13:31 , Andy Lee  wrote:
> 
> It almost looks like the ability to pre-select a file was deliberately 
> removed from the NSOpenPanel API.  Could that be the case?

I don’t know, but I can think of three possible rational explanations:

1. [Security] Being able to select an arbitrary file programmatically might 
lead to spearphishing exploits, where the user is tricked into opening a file 
that is otherwise inaccessible from code in the sandbox.

2. [Security] It might be argued that due to sandboxing, the app doesn’t know 
of the existence of files except those that it already knows the existence of. 
That is, selecting arbitrary files might lead indirectly to arbitrary directory 
enumeration.

3. [UI] The “directoryURL” property description in the header says that the 
selection is asynchronous, and the actual selection may happen “later”. It 
seems possible that the user experience if a file was selected “later” was 
judged to be unacceptable.

___

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: How to pre-select a file in NSOpenPanel -- specifically, a .app bundle?

[Martin Wierschin]

>> It almost looks like the ability to pre-select a file was deliberately 
>> removed from the NSOpenPanel API.


Whatever the reason for removing this feature from NSOpenPanel, it’s a nuisance 
for users. There are many good reasons for wanting to pre-select a particular 
file when presenting an open dialog to the user. Without this feature the user 
has to scroll though a potentially large file list looking for the right entry, 
one whose name may not be familiar to the user.

If this change was made in the interest of security and sandboxing, how about 
just exposing an API that allows an app to select a file for which the app 
already has security-scoped bookmark data? That doesn’t cover all the use 
cases, but it would at least improve the user experience when the user needs to 
validate or change an existing preference.

I filed a radar on this issue forever ago and naturally it was closed as a 
duplicate. As everyone says, maybe file your own radar report to register a 
vote with Apple. Though considering how long this functionality has gone 
missing, I doubt we’ll see any changes– especially if Apple considers this any 
kind of security risk.

~Martin Wierschin


___

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: How to pre-select a file in NSOpenPanel -- specifically, a .app bundle?

[Charles Srstka]

> On Jun 24, 2016, at 3:54 PM, Quincey Morris 
>  wrote:
> 
> 1. [Security] Being able to select an arbitrary file programmatically might 
> lead to spearphishing exploits, where the user is tricked into opening a file 
> that is otherwise inaccessible from code in the sandbox.

How could this be a security threat, when a malicious program could just set 
canChooseDirectories to true, open the panel to the app’s parent directory, and 
spearphish the user into clicking OK on that?

Making it not work with app bundles doesn’t seem to introduce any loopholes 
that aren’t there already.

Charles

___

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: How to pre-select a file in NSOpenPanel -- specifically, a .app bundle?

[Charles Srstka]

> On Jun 24, 2016, at 6:24 PM, Charles Srstka  wrote:
> 
> Making it not work with app bundles doesn’t seem to introduce any loopholes 
> that aren’t there already.

*Making it work
___

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: How to pre-select a file in NSOpenPanel -- specifically, a .app bundle?

[Quincey Morris]

On Jun 24, 2016, at 16:24 , Charles Srstka  wrote:
> 
> How could this be a security threat, when a malicious program could just set 
> canChooseDirectories to true, open the panel to the app’s parent directory, 
> and spearphish the user into clicking OK on that?

(I wasn’t referring to opening apps, but to files generally.)

Clicking OK won’t do anything until the user selects something, and the app 
can’t preset or change the selection. Maybe my logic is incorrect, but this 
seems to me to prevent attempts to fool the user into choosing something 
unintended.

___

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: How to pre-select a file in NSOpenPanel -- specifically, a .app bundle?

[Charles Srstka]

> On Jun 24, 2016, at 7:47 PM, Quincey Morris 
>  wrote:
> 
> On Jun 24, 2016, at 16:24 , Charles Srstka  wrote:
>> 
>> How could this be a security threat, when a malicious program could just set 
>> canChooseDirectories to true, open the panel to the app’s parent directory, 
>> and spearphish the user into clicking OK on that?
> 
> (I wasn’t referring to opening apps, but to files generally.)
> 
> Clicking OK won’t do anything until the user selects something, and the app 
> can’t preset or change the selection. Maybe my logic is incorrect, but this 
> seems to me to prevent attempts to fool the user into choosing something 
> unintended.

func readTheFile(url: NSURL) {
do {
let data = try NSData(contentsOfURL: url, options: [])
guard let string = String(data: data, encoding: NSUTF8StringEncoding) 
else {
throw NSCocoaError.FileReadCorruptFileError
}

print("Contents of file: \(string)")
} catch {
print("Error occurred: \(error)")
}
}

let url = NSURL(fileURLWithPath: "/path/to/MyGreatFile.txt")

print("First attempt:")
readTheFile(url)

let dirURL: NSURL = {
while true {
let openPanel = NSOpenPanel()

openPanel.canChooseDirectories = true
openPanel.directoryURL = url.URLByDeletingLastPathComponent
openPanel.prompt = "OK"
openPanel.message = "Please click OK"

let answer = openPanel.runModal()

if answer == NSFileHandlingPanelOKButton, let openPanelURL = 
openPanel.URL where openPanelURL == url.URLByDeletingLastPathComponent {
return openPanelURL
} else {
let alert = NSAlert()

alert.messageText = "Hey buddy, click the OK button when I tell you 
to, okay?"

alert.runModal()
}
}
}()

print("Second attempt:")

dirURL.startAccessingSecurityScopedResource()
readTheFile(url)
dirURL.stopAccessingSecurityScopedResource()

--

After clicking OK when asked, this outputs:

First attempt:
Error occurred: Error Domain=NSCocoaErrorDomain Code=257 "The file 
“MyGreatFile.txt” couldn’t be opened because you don’t have permission to view 
it." UserInfo={NSFilePath=/path/to/MyGreatFile.txt, 
NSUnderlyingError=0x60046750 {Error Domain=NSPOSIXErrorDomain Code=1 
"Operation not permitted"}}
Second attempt:
Contents of file: This is my great file!

Charles


___

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: How to pre-select a file in NSOpenPanel -- specifically, a .app bundle?

[Andy Lee]

Interesting.

I should mention I hadn't turned on sandboxing in this project.  When I turn it 
on, and I set the "User Selected File" entitlement to "Read Only", I get the 
same behavior as before: TextEdit.app is selected in the panel's column view, 
and it's treated like a regular (non-bundle) directory, with "Contents" exposed 
in the next column.  The same happens, by the way, with other package types 
like .playground and .rtfd, so it isn't specific to .app.  I will file a Radar 
for this, as the NSOpenPanel is clearly not respecting its own 
treatsFilePackagesAsDirectories property when it is initially displayed, though 
it does thereafter.

Given that Apple seemingly does not want NSOpenPanel to pre-select "files" 
(including packages that we pretend are not directories), I would say it's also 
a bug that my NSOpenPanel was able to pre-select TextEdit.app.  I mean "bug" in 
the sense of "not working as Apple intended", as opposed to what my druthers 
would be.

--Andy

On Jun 24, 2016, at 11:31 PM, Charles Srstka  wrote:
> 
>> On Jun 24, 2016, at 7:47 PM, Quincey Morris 
>>  wrote:
>> 
>> On Jun 24, 2016, at 16:24 , Charles Srstka  wrote:
>>> 
>>> How could this be a security threat, when a malicious program could just 
>>> set canChooseDirectories to true, open the panel to the app’s parent 
>>> directory, and spearphish the user into clicking OK on that?
>> 
>> (I wasn’t referring to opening apps, but to files generally.)
>> 
>> Clicking OK won’t do anything until the user selects something, and the app 
>> can’t preset or change the selection. Maybe my logic is incorrect, but this 
>> seems to me to prevent attempts to fool the user into choosing something 
>> unintended.
> 
> func readTheFile(url: NSURL) {
>do {
>let data = try NSData(contentsOfURL: url, options: [])
>guard let string = String(data: data, encoding: NSUTF8StringEncoding) 
> else {
>throw NSCocoaError.FileReadCorruptFileError
>}
> 
>print("Contents of file: \(string)")
>} catch {
>print("Error occurred: \(error)")
>}
> }
> 
> let url = NSURL(fileURLWithPath: "/path/to/MyGreatFile.txt")
> 
> print("First attempt:")
> readTheFile(url)
> 
> let dirURL: NSURL = {
>while true {
>let openPanel = NSOpenPanel()
> 
>openPanel.canChooseDirectories = true
>openPanel.directoryURL = url.URLByDeletingLastPathComponent
>openPanel.prompt = "OK"
>openPanel.message = "Please click OK"
> 
>let answer = openPanel.runModal()
> 
>if answer == NSFileHandlingPanelOKButton, let openPanelURL = 
> openPanel.URL where openPanelURL == url.URLByDeletingLastPathComponent {
>return openPanelURL
>} else {
>let alert = NSAlert()
> 
>alert.messageText = "Hey buddy, click the OK button when I tell 
> you to, okay?"
> 
>alert.runModal()
>}
>}
> }()
> 
> print("Second attempt:")
> 
> dirURL.startAccessingSecurityScopedResource()
> readTheFile(url)
> dirURL.stopAccessingSecurityScopedResource()
> 
> --
> 
> After clicking OK when asked, this outputs:
> 
> First attempt:
> Error occurred: Error Domain=NSCocoaErrorDomain Code=257 "The file 
> “MyGreatFile.txt” couldn’t be opened because you don’t have permission to 
> view it." UserInfo={NSFilePath=/path/to/MyGreatFile.txt, 
> NSUnderlyingError=0x60046750 {Error Domain=NSPOSIXErrorDomain Code=1 
> "Operation not permitted"}}
> Second attempt:
> Contents of file: This is my great file!
> 
> Charles
> 


___

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: How to pre-select a file in NSOpenPanel -- specifically, a .app bundle?

[Andy Lee]

Whoops, meant for this to go to the list:

On Jun 24, 2016, at 6:22 PM, Martin Wierschin  wrote:
> 
>>> It almost looks like the ability to pre-select a file was deliberately 
>>> removed from the NSOpenPanel API.
> 
> 
> Whatever the reason for removing this feature from NSOpenPanel, it’s a 
> nuisance for users. There are many good reasons for wanting to pre-select a 
> particular file when presenting an open dialog to the user. Without this 
> feature the user has to scroll though a potentially large file list looking 
> for the right entry, one whose name may not be familiar to the user.
> 
> If this change was made in the interest of security and sandboxing, how about 
> just exposing an API that allows an app to select a file for which the app 
> already has security-scoped bookmark data? That doesn’t cover all the use 
> cases, but it would at least improve the user experience when the user needs 
> to validate or change an existing preference.

Indeed, the reason I want to pre-select is to highlight an existing preference.

Earlier I was trying to remember the last time I saw an app pre-select a file.  
Your mention of the user preference use case jogged my memory.  I can think of 
a couple of apps that *don't* pre-select a file that was previously specified 
as a user preference.  I was surprised, because the apps are otherwise very 
well thought out.  Now I see the reason must be this limitation of NSOpenPanel.

> I filed a radar on this issue forever ago and naturally it was closed as a 
> duplicate. As everyone says, maybe file your own radar report to register a 
> vote with Apple. Though considering how long this functionality has gone 
> missing, I doubt we’ll see any changes– especially if Apple considers this 
> any kind of security risk.

I'm pessimistic too, but if I ever get around to filing a radar I'll let you 
know.

--Andy


___

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