Mobile interface unavailable

Tom Elliott

No it does not as 1.5.0 is responsive in design

Fred53

Ok, so I can’t let teachers restore an image without giving them all access to the web interface. It’s a shame.

Tom Elliott

@fred53 it can be done but I’m not coding it.maintaining 2 separate elements is rough and often times one loses out over the other. So while it’s not native it is still possible. I’d recommend looking at hooks to allow/disallow logins. There was a post describing which hooks could be used.

Fred53

Is it this one ?
https://forums.fogproject.org/topic/4433/is-it-possible-to-remove-the-fog-quick-image-password

Tom Elliott

@fred53 no. I’ll find the link and post it.

Tom Elliott

https://forums.fogproject.org/topic/11444/deny-fog-webpage-login/8

Fred53

I don’t know what hooks are and where I can find USER_TYPE_HOOK and USER_TYPE_VALID.
Is it in the database ? (I only found a field named Type in the Users table which is equal to 0).

Sebastian Roth

@Fred53 You wanna take a look at the hooks directory, start with template.hook.php! We don’t have an example of how to use USER_TYPE_HOOK and USER_TYPE_VALID in particular but I am sure you get what this is about looking at the code.

Fred53

I understood that hooks are like plugins which can be added and activated with “public $active = true;” inside the php file.
I search for USER_TYPE in the sources files and only find them in these files :
/lib/plugins/ldap/hooks/ldappluginhook.hook.php

        self::$HookManager
            ->register(
                'USER_LOGGING_IN',
                array(
                    $this,
                    'checkAddUser'
                )
            )
            ->register(
                'USER_TYPE_HOOK',
                array(
                    $this,
                    'setLdapType'
                )
            )
            ->register(
                'USER_TYPES_FILTER',
                array(
                    $this,
                    'setTypeFilter'
                )
            )
            ->register(
                'USER_TYPE_VALID',
                array(
                    $this,
                    'isLdapType'
                )
            );

/lib/fog/user.class.php

        $type = $tmpUser->get('type');
        self::$HookManager
            ->processEvent(
                'USER_TYPE_HOOK',
                array(
                    'type' => &$type
                )
            );
        self::$HookManager
            ->processEvent(
                'USER_TYPE_VALID',
                array(
                    'type' => &$type,
                    'typeIsValid' => &$typeIsValid
                )
            );
        if ($typeIsValid && !in_array($type, array(0, 1))) {
            $typeIsValid = false;
        }

            if (self::$FOGUser->isValid()) {
                $type = self::$FOGUser->get('type');
                self::$HookManager
                    ->processEvent(
                        'USER_TYPE_HOOK',
                        array('type' => &$type)
                    );
                $this
                    ->set('id', self::$FOGUser->get('id'))
                    ->set('name', self::$FOGUser->get('name'))
                    ->set('password', '', true)
                    ->set('type', $type);
                if (!$this->_sessionID) {
                    $this->_sessionID = session_id();
                }

/lib/pages/processlogin.class.php

        $type = self::$FOGUser->get('type');
        self::$HookManager
            ->processEvent(
                'USER_TYPE_HOOK',
                array('type' => &$type)
            );

But I don’t really understand what this code do and what is the link with my aim (having a restricted web interface for a specific user).

The only lead I see is in the first file which talks about an unprivileged user account (with type=“991”)

            $access = $ldap->authLDAP($user, $pass);
            unset($ldap);
            switch ($access) {
            case 2:
                // This is an admin account, break the loop
                $tmpUser
                    ->set('name', $user)
                    ->set('password', $pass)
                    ->set('type', 990)
                    ->save();
                break 2;
            case 1:
                // This is an unprivileged user account.
                $tmpUser
                    ->set('name', $user)
                    ->set('password', $pass)
                    ->set('type', 991)
                    ->save();
                break;
            default:

Is type “991” the key ? or does it only concern ldap ?

Tom Elliott

@fred53 there are two types fog has used for a long time the 99x are specific for ldap accounts. 0 = admin, 1 = nonprivileged/mobile. Following suite 990 = ldap based fog admin, 991 = ldap based fog nonprivileged/mobile.

The way you’d want to use the hook is with user type and user logging in. Test user logging in with the type, disallow logging in for those with type 1. There, currently, isn’t a method to set the type anymore but you could use the names alone to figure out which users you would allow to login or not. I post a snippet of a method you could try.

Tom Elliott

<?php
/**
 * Template for others to work from.
 *
 * PHP version 5
 *
 * @category Template
 * @package  FOGProject
 * @author   Hook Author <hookemail@email.com>
 * @license  http://opensource.org/licenses/gpl-3.0 GPLv3
 * @link     https://fogproject.org
 */
/**
 * Template for others to work from.
 *
 * @category Template
 * @package  FOGProject
 * @author   Hook Author <hookemail@email.com>
 * @license  http://opensource.org/licenses/gpl-3.0 GPLv3
 * @link     https://fogproject.org
 */
class MobileUserNoLogin extends Hook
{
    /**
     * The name for this hook.
     *
     * @var string
     */
    public $name = 'Mobile User No Login';
    /**
     * The description for this hook.
     *
     * @var string
     */
    public $description = 'Do not allow certain users to login to GUI.';
    /**
     * If the hook is active or not.
     *
     * @var bool
     */
    public $active = true;
    /**
     * Initializes object.
     *
     * @return void
     */
    public function __construct()
    {
        parent::__construct();
        self::$HookManager->register(
            'USER_LOGGING_IN',
            [$this, 'userLoggingIn']
        );
    }
    /**
     * User Logging In
     *
     * @param mixed $arguments The data to alter, work with.
     *
     * @return void
     */
    public function userLoggingIn($arguments)
    {
        // Allowed usernames.
        $usernames = [
            'username1',
            'username2',
            'username3'
        ];
        $username = $arguments['username'];
        // If username is allowed return to continue process.
        if (in_array($username, $usernames)) {
            return;
        }
        // Otherwise blank out the username.
        $arguments['username'] = '';
    }
}

Now this is very minimal approach, but it is a way you can handle this. I’d recommend it this way as you don’t need to know if the user type is setup as 0 or 1 (and you can’t natively set it in 1.5.x anyway).

Ways to approach the use of deploying an image with the users you disallow GUI access would include checking the request uri, for example checking the uri for bootmenu during the userLoggingIn method and only allowing users there. (or disallowing if you must.) The method I gave would function on any element dealing with user login.

Changing the method around to do something like:

    public function userLoggingIn($arguments)
    {
        // If the script is not boot menu related, return.
        if (self::$scriptname != 'bootmenu.php') {
            return;
        }
        // Allowed usernames.
        $usernames = [
            'username1',
            'username2',
            'username3'
        ];
        $username = $arguments['username'];
        // If username is allowed return to continue process.
        if (in_array($username, $usernames)) {
            return;
        }
        // Otherwise blank out the username.
        $arguments['username'] = '';
    }

Hopefully this helps you out a little.

You can of course reverse the logic a little bit if you’re simply looking to restrict things. For example:

    public function userLoggingIn($arguments)
    {
        // If the script is not boot menu related, return.
        if (self::$scriptname != 'bootmenu.php') {
            return;
        }
        // Disallowed usernames.
        $usernames = [
            'username1',
            'username2',
            'username3'
        ];
        $username = $arguments['username'];
        // If username is allowed return to continue process.
        if (in_array($username, $usernames)) {
            $arguments['username'] = '';
        }
    }

Fred53

Thank you for these examples.
I created the file /var/www/fog/lib/hooks/mobileusernologin.hook.php and pasted your first code, then changed the userLogginIn function with your 2 other codes (and replacing “username1” by “fog”), but I didn’t see any difference in each case: when logging to http://…/fog/management/index.php whith either “fog” account or a “test” account, I still see all the menus.
What am I doing wrong ?

Mobile interface unavailable

206

12.1k

17.3k

155.3k