APP Architecture Question

Mon, 17 Sep 2018 19:43:31 +0000

As I see the lay of the land - APPS can be enabled on the server and installed by individual channels, but there is no "middle ground" that allows Apps to be installed on the server and only installable by SOME channels (based on either channel or account restrictions). (maybe I'm missing something... if so, I'd be grateful for a pointer)

I started working on some hooks to make it possible, but ran into an issue looking at the APP synchronization code that causes me to think a solution needs to be more widely discussed.  My work so far simply hides the ability for a user to install an app on on their channel by filtering what is/isn't allowed on the channel app install screen based on a field in the SERVICE_CLASS array.  It is thought to later expand this to a variable in pconfig so that the CART system could be used to allow paid access to specific apps.

I know it needs to go further, but I'm having trouble getting around how to deal with the scenario of a user cloning their channel on another instance and installing/enabling an app on the 2nd instance and having the app synchronization automatically enabling it on the original instance - which - if I read the code correctly - is the likely behavior if the hub itself has the app enabled even if the individual channel doesn't click the "install" button on their channel settings.

Then there's a second issue with regard to hooks.  As far as I can tell, there is no central "app enabled" setting on a per-channel basis that blocks an app's hooks and code from running if it's enabled hub wide even if the app isn't installed on a channel itself (I've run into the scenario of hooks triggering for channels where the app wasn't installed more a couple of times during development).

So far I've resorted to creating an "enable" (pconfig) setting for the app(s) I've created.  Any  hooked functions that are triggered from elsewhere in the system do a check against the pconfig variable to make sure the app is "enabled".  The problem is this solution seems wasteful (every hooked function must run the check every time it's triggered).  And, it doesn't lend itself to the possibility of a hub admin blocking/enabling an app on a per channel or per account basis (for example, from the SERVICE_CLASS settings or even being able to enforce some sort of subscription payment structure for apps) but still having it enabled server wide for use by other users unless the app is specifically coded to behave this way (i.e., the app itself checks SERVICE_CLASS or some setting set by the cart system or some other settable variable).

I admit, I may be entirely missing something obvious in the code - but I don't see the current code permitting these scenarios.  At the same time, I see an implicit intention to support such things.  Even if it is just me reading into the project my own thoughts and desires, it seems that these would certainly be features that would help immensely hub admins who want to more completely "hide" functionality from some users and open it up to more advanced users (or paying subscribers).

There is no "silver bullet" to fix all of these at once.  Any solution will lead to some level of change in the core beyond adding a hook or two or even a few.

Has anyone already thought through a potential solution?  I have some ideas, but I know there are others who know the code better than me.

I think it'd be helpful to have a similar system that allows the locking of certain features generally and default settings on an account (or preferably, both an account and a per-channel) basis - though, until we get to the end of the "appification" process, I think that should wait.

show all 6 Comments

Mon, 17 Sep 2018 20:43:25 +0000

Basically I think you're going about it wrong. An app is just a link. Nothing more. We don't try to protect the app. We protect the link. Paying for an app puts you in the ACL for the link. Anybody can copy and share the app. There are some access controls on the apps themselves so we only show them when installed and appropriate (there are checks available to enable the app only to logged in channels for instance as well as checking that a required plugin is installed). It would be easy to check service class restrictions with the caveat that there is no convention on service class names so you would probably have to check the actual limits you are interested in rather than rely on a particular service class name.

Mon, 17 Sep 2018 21:20:44 +0000 last edited: Mon, 17 Sep 2018 21:55:44 +0000

Based on your description, I see what you're getting at (I think) --- "apps" as "links" which may or may not reside on the local hub. I grok'd this at one point, but lost it between then and now somehow.

What I really meant was "addon"/"plugin" (as in hub-local discrete PHP unit that performs some desired function) not "app." (a pointer/link to a local or remote sub-application that performs a desired function).

So if you rewind what I said above and replace "app" in the OP with "addon" it's more correct.... I think.

What I'm looking for is a standardized way to enable/disable the running code related to individual addons on a per account/per channel basis without the need to code each individual addon with it's own service_class / pconfig / cart "enablement verification subroutines". I can imagine there will likely be some other ways that people will invent in the future to check whether or not a given addon should run for a given account/channel (like check some sort of verification token against a block chain licensing system). I'd like the decision as to whether or not it runs for a specific user to be determined and be configurable by the hub-admin and not determined by the plugin author.

As I see it, it would require some sort of checking of HOOKS to see if they should run (perhaps adding an "addon" field, or maybe just checking against the filename of the hook) - as well as some method to know if it should be considered a "linkable app" or not.

Or am I still thinking about something incorrectly?

Mon, 17 Sep 2018 23:09:38 +0000

I understand what you're getting at, but getting there from here is probably a bit of work and will need to be added to each addon. The problem (as you've correctly surmised) is hooks. Hooks run at the system level and don't know who is calling them. In order to (for instance) disable Diaspora functionality to anybody that didn't have the Diaspora protocol enabled, we needed to do the check inside many of the hook functions. Complicating this is the fact that some hooks run under "daemon" context and are acting on behalf of somebody, but there is no identity in the system we can use to figure out who that is. We need the information provided in the hook to determine who precisely is the person of interest.

Tue, 18 Sep 2018 01:04:48 +0000

At the hook level itself, we simply need a binary "yes/no" do or don't run this hook, right? So what about the following in call_hooks() right at the beginning of the foreach loop:

$checkhook = [
        'name'=>$name,
        'hook'=>$hook,
        'permit'=>true
        ]
if ($name != 'permit_hook') {  // avoid looping
        call_hooks('permit_hook',$checkhook);
        if (!$checkhook['permit']) {
                continue;
        }
}

I'm not sure the copy needed to include $data would be worth it - unless it's still true that variable copies aren't actually created until modification (cxref: http://php.net/manual/en/language.references.php#41114 ), in which case it's a no-brainer that you'd want to add it.

Then, from a "core" vantage point, how someone wants to implement hook permissions is out of our hands. For some addon's (probably the great majority of 3rd party developed apps), it would be an easy check because the needed state (channel references, observer references, etc) will be known before the hook gets triggered - If you want to exclude an addon wholesale, just check the filename of the hook:

if (strpos($checkhook['hook'][0],"addon/{$addonslug}/")) { 
        if ( {{ CUSTOM HOOK LOGIC }} ) {
                $checkhook['permit']=false; 
        }
}

return;

This won't catch hooks added by hook_insert(). But a similar if statement could be made to check the function name ( $checkhook['hook'][1] ) against a list of hooks (or class names) you want to exclude.

Of course, the majority of 3rd party addons can probably be handled using the module_loaded hook in \Zotlabs\Web\Router::__construct().

Users of these hooks would need to know the details of the modules they want to filter out - but that would be "their problem" to figure out.

Am I missing something?

Tue, 18 Sep 2018 02:01:00 +0000

That's fine if you just want to allow or prevent a hook. I was only mentioning that there isn't a lot of context. I don't know how you could allow the hook for one person (say due to their service class) and deny it to another per this statement(*) because the hooks themselves don't know who is accessing them.

(*)

What I'm looking for is a standardized way to enable/disable the running code related to individual addons on a per account/per channel basis

You may be able to get away with session information (local_channel(), remote_channel()) but this will only be applicable to a very small number of hooks which are invoked via web access. If you're ok with that limitation, fine.

Tue, 18 Sep 2018 02:26:10 +0000

Ah, I see what you're concern is. THAT is the ideal. Clearly we aren't there at this point - so a method customized by addon is the best I think we can do. I think the proposed solution provides the flexibility to facilitate a standardized solution in the future - while making the aim and goal possible (if a bit arduous) in the short term.

As for context on addons that need to at least BEGIN running before there is enough context to make a determination, I think this solution allows someone to build a traffic director that could gather that context as it goes. Of course, you'd have to study the hooks and the data structures for the plugin(s) you want to allow/prohibit and you'd only be able to make a determination after the hooks that build the context needed have triggered (basically you'd need to whitelist some hooks and then blacklist others if needed after you had enough info to do so). But I think this provides the flexibility to do so without admins needing to adjust the addons themselves.

And, with the structure there and the aims and goals in the open, maybe addon authors in the community would consider structuring their addons in a way that makes needed criteria easily available in a standardized way in the future.