search

trilemma-dev / SecureXPC

A simple and secure XPC framework for Swift
MIT License
75 stars 15 forks source link

Adds `XPCRequestContext` which exposes client info to the server #73

Closed jakaplan closed 2 years ago

jakaplan commented 2 years ago

The core addition here is the introduction of the entirely optional XPCRequestContext which has static properties that are accessible within the execution context of a closure called by XPCServer.

The motivation behind this PR is that there are times where I need to differ the behavior of the server based on the caller. Since I trust all of my clients I could have them explicitly provide this information, but it seemed more robust to have this be determined server side.

The design is a bit "magic" so I'm torn on it. I considered three different approaches and ultimately settled on this one. The other two considered were:

  1. Closures registered with the server must have XPCRequestContext as a parameter.
  2. Closures registered with the server may have XPCRequestContext as a parameter.

Approach 1 felt far too heavy handed as I don't think the average user of SecureXPC will need to make use of XPCRequestContext. Approach 2 would require doubling the number of handler registration functions from 8 to 16 along with all of the associated boiler plate. Additionally it'd make XPCRequestContext more prominent in the API and that's undesirable as again I think it'll be needed in a small minority of cases.

jakaplan commented 2 years ago

@amomchilov would appreciate your feedback on this, both at a code level as well as the overall approach. I think this is reasonable design, but I'm not entirely convinced it's the best one.

jakaplan commented 2 years ago

So far we called the incoming thing a "message", not a "request", is that right? So perhaps XPCMessageContext would make sense in that context (heh).

Terminology is hard! My intention, which I may not have consistently succeeded at, is that "message" refers to the object being sent via the client to the server. This means there are two route types which have no message, but they still result in a server handler being called. Hence I chose "request" instead of "message", but it's true this introduces yet another noun. I also considered XPCClientContext as it's describing the client, but I thought that was somewhat confusing and could be confused as something that is accessible on/to the client.

amomchilov commented 2 years ago

is that "message" refers to the object being sent via the client to the server. This means there are two route types which have no message, but they still result in a server handler being called.

I think it would make more sense if the terminology such that all 4 route types send a request, and some of them have a message attached.

Then XPCRequestContext would make perfect sense as a name for this