Page 1 of 2

[Dev-Change] Extensions New ACP/UCP/MCP Module Auth

Posted: Sun Jan 19, 2014 2:30 am
by VSE
When an Extension adds a settings "Module" to the Admin Control Panel, User Control Panel, or Moderator Control Panel, it should use the new module/auth acl variable created for Extensions.

In phpBB 3.0.X when MODs added a module for their settings to the Admin/User/Moderator Control Panel, a module/auth variable such as 'auth' => 'acl_a_board' was typically used. These were usually set in acp info files (and sometimes in the database install scripts).

In phpBB 3.1, because Extensions can be disabled, they now set and use their own unique module/auth variable as well.

You should now use something like: 'auth' => 'ext_vendor/foobar' for an extension located at ext/vendor/foobar in your ACP module's info files (and migration files if necessary).

Example of an ACP foobar_info.php file:

Code: Select all

class foobar_info
{
    function module()
    {
        return array(
                'filename'    => '\vendor\foobar\acp\foobar_module',
                'title'        => 'ACP_FOOBAR',
                'modes'        => array(
                    'view'    => array(
                        'title' => 'ACP_FOOBAR',
                        'auth' => 'ext_vendor/foobar && acl_a_board',
                        'cat' => array('ACP_CAT_DATABASE')
                    ),
                ),
        );
    }
} 
Example of same module being installed the "manual way" by a migration file:

Code: Select all

public function update_data()
{
    return array(
        array('module.add', array(
                'acp',
                'ACP_CAT_DATABASE',
                array(
                    'module_basename'    => '\vendor\foobar\acp\foobar_module',
                    'module_langname'    => 'ACP_FOOBAR',
                    'module_mode'        => 'view',
                    'module_auth'        => 'ext_vendor/foobar && acl_a_board',
                )
        )),
    );
} 

Re: [INFO] Extensions New ACP Module Auth

Posted: Tue Mar 04, 2014 9:53 pm
by John P
When an extension has permission of acl_a_board for example then it should not be necessary to ad a new permission I believe. Why can't you use the already existing permission then?

Re: [INFO] Extensions New ACP Module Auth

Posted: Wed Mar 05, 2014 2:08 am
by tbackoff
I'm curious as to the reasoning for this? The migration files remove the acl_a_xxx permission when an extension is disabled and the data removed.

Re: [INFO] Extensions New ACP Module Auth

Posted: Wed Mar 05, 2014 4:35 am
by VSE
t_backoff wrote:I'm curious as to the reasoning for this? The migration files remove the acl_a_xxx permission when an extension is disabled and the data removed.
If you disable a MOD, all the database changes remain in place (including the db settings of the acl_a_xxx permissions). With the old auth variables, that meant that if your extension had any ACP modules, and you went to load that module page, you'd get a PHP failure, because your extensions module settings are still active in the DB, and it still has permission to load, but everything else (PHP-wise) is disabled.

So imagine now, you have a couple extensions on your forum, and they all have ACP modules under the .MODs tab. But for some reason you disable the extension that comes first on the .MODs tab page. Now you can't access any of your other enabled extensions settings on that page because the disabled extension is breaking the entire .MODs page.

The above change resolves all of this. Now when an extension is disabled, it also loses its permission to display any of its ACP/UCP/MCP modules, so no more breakage.

Remember that migration files are not run during disable... Only during Enable and Delete Data.

Re: [INFO] Extensions New ACP Module Auth

Posted: Wed Mar 05, 2014 7:00 am
by John P
Interesting, never tried to start a disabled extension because I disabled it but it shows different problems.

Once disabled the language is broken in ACP menu. When started it shows it can't find the language and gives notice's. Doesn't matter if the acl is used common or a unique one.

Think there is some more work at the extension manager.
I believe once a extension is disabled it should not be possible anymore to start it and also removed from the acp menu.

Re: [INFO] Extensions New ACP Module Auth

Posted: Wed Mar 05, 2014 12:36 pm
by tbackoff
VSE wrote:If you disable a MOD, all the database changes remain in place (including the db settings of the acl_a_xxx permissions).
[snip]
Remember that migration files are not run during disable... Only during Enable and Delete Data.
That's what I said:
t_backoff wrote:I'm curious as to the reasoning for this? The migration files remove the acl_a_xxx permission when an extension is disabled and the data removed.
I'm a little confused by this part though:
VSE wrote:You should now use something like: 'auth' => 'ext_vendor/foobar' for an extension located at ext/vendor/foobar in your ACP module's info files (and migration files if necessary).
Wouldn't it be 'auth' => 'ext/vendor/foobar' instaead for an extension located at ext/vendor/foobar? If not, why not? So if it have an extension at ext/phpbb/boardrules, my auth would be ext_phpbb/boardrules?

Re: [INFO] Extensions New ACP Module Auth

Posted: Wed Mar 05, 2014 4:24 pm
by VSE
John P wrote:Interesting, never tried to start a disabled extension because I disabled it but it shows different problems.

Once disabled the language is broken in ACP menu. When started it shows it can't find the language and gives notice's. Doesn't matter if the acl is used common or a unique one.

Think there is some more work at the extension manager.
I believe once a extension is disabled it should not be possible anymore to start it and also removed from the acp menu.
That's not right. If an ext correctly installs ACP modules anywhere in the ACP, and uses the new auth method unique to the extension, then when the extension is disabled, it will disappear from the ACP, and that also means no broken language variables left behind (that only happens now if the extension still uses the old acl_a_xxx auths).

If you are still seeing broken lang vars when an extension is disabled, you probably have other problems going on as what you describe is not reproducible (are you using the latest build of the dev branch, for example).
t_backoff wrote:I'm a little confused by this part though:
VSE wrote:You should now use something like: 'auth' => 'ext_vendor/foobar' for an extension located at ext/vendor/foobar in your ACP module's info files (and migration files if necessary).
Wouldn't it be 'auth' => 'ext/vendor/foobar' instaead for an extension located at ext/vendor/foobar? If not, why not?
Because that's the way they designed it to be. ;)
t_backoff wrote:So if it have an extension at ext/phpbb/boardrules, my auth would be ext_phpbb/boardrules?
Yes

Re: [INFO] Extensions New ACP Module Auth

Posted: Wed Mar 05, 2014 4:33 pm
by tbackoff
So what do we do for multiple auths? For example, if my extension requires a_kb_manage and a_kb_settings (same for u_ and m_ authts)? Also, what would it look like in a migration file? Currently, I have this:

Code: Select all

array('permission.add', array('u_kb_delete')),
array('permission.add', array('u_kb_edit')),
array('permission.add', array('u_kb_post')),

array('permission.add', array('m_kb_approve')),
array('permission.add', array('m_kb_delete')),
array('permission.add', array('m_kb_deny')),
array('permission.add', array('m_kb_disapprove')),
array('permission.add', array('m_kb_edit')),

array('permission.add', array('a_kb_manage')),
array('permission.add', array('a_kb_settings')),

Re: [INFO] Extensions New ACP Module Auth

Posted: Wed Mar 05, 2014 5:45 pm
by VSE
t_backoff wrote:So what do we do for multiple auths? For example, if my extension requires a_kb_manage and a_kb_settings (same for u_ and m_ authts)? Also, what would it look like in a migration file?
This has nothing to do with user, admin and moderator permissions.

This is only for acl_auths (ACP/MCP/UCP module authorizations) that are defined in your acp_info file (or mcp_info or ucp_info files)... i.e.:

Code: Select all

class dbtool_info
{
    function module()
    {
        return array(
            'filename'    => '\vse\dbtool\acp\dbtool_module',
            'title'        => 'ACP_OPTIMIZE_REPAIR',
            'version'    => '1.1.0',
            'modes'        => array(
                'view'    => array('title' => 'ACP_OPTIMIZE_REPAIR', 'auth' => 'ext_vse/dbtool', 'cat' => array('ACP_CAT_DATABASE')),
            ),
        );
    }
} 
Note the 'auth' value defined on the 'view' line

As mentioned above, this is only about preventing extension modules (ACP, MCP, or UCP) from displaying when their extension has been disabled (but not deleted).

FYI, if installing the same module the "manual" way via migration file (see 'module_auth' value):

Code: Select all

public function update_data()
{
    return array(
        array('module.add', array(
            'acp',
            'ACP_CAT_DATABASE',
            array(
                'module_basename'    => '\vse\dbtool\acp\dbtool_module',
                'module_langname'    => 'ACP_OPTIMIZE_REPAIR',
                'module_mode'        => 'view',
                'module_auth'        => 'ext_vse/dbtool',
                'after'                => 'ACP_RESTORE', // Will be placed after ACP_RESTORE
            )
        )),
    );

Re: [INFO] Extensions New ACP Module Auth

Posted: Thu Mar 06, 2014 12:06 am
by John P
VSE wrote:
John P wrote:Interesting, never tried to start a disabled extension because I disabled it but it shows different problems.

Once disabled the language is broken in ACP menu. When started it shows it can't find the language and gives notice's. Doesn't matter if the acl is used common or a unique one.

Think there is some more work at the extension manager.
I believe once a extension is disabled it should not be possible anymore to start it and also removed from the acp menu.
That's not right. If an ext correctly installs ACP modules anywhere in the ACP, and uses the new auth method unique to the extension, then when the extension is disabled, it will disappear from the ACP, and that also means no broken language variables left behind (that only happens now if the extension still uses the old acl_a_xxx auths).
So finally you are telling me an extension can not use a permission which already exists because once disabled it will go wrong?

Re: [INFO] Extensions New ACP Module Auth

Posted: Thu Mar 06, 2014 5:01 am
by VSE
John P wrote:So finally you are telling me an extension can not use a permission which already exists because once disabled it will go wrong?
First EVERYBODY STOP SAYING PERMISSIONS! :? This has nothing to do with permissions. This has only to do with MODULE management. All MODULES have an authorization parameter (stored in the modules table module_auth) that allows that ACP, MCP or UCP module to be displayed when said module is enabled.

Every extension MUST provide its own unique module auth variable, if it has any modules it will be installing in the ACP, MCP or UCP. And the format for it is ext_vendor/extensionname. Stop relying on using existing acl_a_xxx module auth values reserved for the core system modules.

This was a major/blocker bug and the resolution is to do as described in the first post above:
http://tracker.phpbb.com/browse/PHPBB3-12006
http://tracker.phpbb.com/browse/PHPBB3-12044

So the bottom line is all extensions need to have their own unique module auth value so when the extension is disabled, the module management system will also recognize any modules belonging to that extension are also disabled.

Re: [INFO] Extensions New ACP Module Auth

Posted: Thu Mar 06, 2014 5:16 am
by Pico88
As I remember, we can use multiple auth, so try ext_vendor/extensionname && a_

Re: [INFO] Extensions New ACP Module Auth

Posted: Thu Mar 06, 2014 7:17 am
by John P
I tried this this morning, module_auth has a unique name ext_forumhulp/get_stuff, the extension isn't visible in ACP.
Permission set ext_forumhulp/get_stuff, extension is working but once disabled languageproblems and notices

Module_auth ext_forumhulp/get_stuff || acl_a_board, extension is visible and working, once disabled languageproblems and notices


The problems comes from the disable extension function, it only updates the extension table and not the module table. So either set module_enabled to false when disabling or look also at the extension table for ext_active in module management.

Re: [INFO] Extensions New ACP Module Auth

Posted: Thu Mar 06, 2014 12:41 pm
by tbackoff
VSE wrote:First EVERYBODY STOP SAYING PERMISSIONS! :? This has nothing to do with permissions.
This has everything to do with permissions. "Auth" is short for authorization, which by definition means you do or do not have permission to do something.
VSE wrote:the format for it is ext_vendor/extensionname. Stop relying on using existing acl_a_xxx module auth values reserved for the core system modules.
I just tested this on 3.1-a3. I changed the auth parameter in my info file to the proper format. Extension enables and disables fine, but we're still missing a core part of functionality - how does one restrict access to a module. I stated above, if I have a "management" mode and a "settings" mode for my extension, using the format you've given permits access to both modes, regardless of whether the permission is set to NO or not. Please explain how you restrict access in this scenario.

Otherwise, this is a serious bug and I'll report it if there is no clear way of achieving what I've stated above.

Re: [INFO] Extensions New ACP Module Auth

Posted: Thu Mar 06, 2014 4:21 pm
by VSE
t_backoff wrote:I just tested this on 3.1-a3. I changed the auth parameter in my info file to the proper format. Extension enables and disables fine, but we're still missing a core part of functionality - how does one restrict access to a module. I stated above, if I have a "management" mode and a "settings" mode for my extension, using the format you've given permits access to both modes, regardless of whether the permission is set to NO or not. Please explain how you restrict access in this scenario.

Otherwise, this is a serious bug and I'll report it if there is no clear way of achieving what I've stated above.
Just as Pico88 suggested, this is easy to do. You can still tie your module to an existing acl_option by doing something like:

auth => 'ext_vendor/foobar && acl_a_backup'

This would give your module the same access privileges as the ACP Database Backup and Restore module.

Or you could define your own permissions: a_my_foobar_manage and a_my_foobar_settings.

Then in your _info file:

Code: Select all

'settings'    => array('title' => 'FOOBAR',
   'auth' => 'ext_vendor/foobar && acl_a_my_foobar_settings',
   'cat' => array('FOOBAR')),

'manage'    => array('title' => 'FOOBAR',
   'auth' => 'ext_vendor/foobar && acl_a_my_foobar_manage',
   'cat' => array('FOOBAR')),
This way, the logic says: if my module is enabled and the admin has permissions, display it.

I've updated the first post to reflect this.