Not checking User Permissions with Mixing Station?

Forums Forums SQ Forums SQ general discussions Not checking User Permissions with Mixing Station?

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #124067
    Profile photo of Simon2Simon2
    Participant

    Hi,

    on my SQ6 i activated a user with limited permissions (e.g. no access to AUX8) and it worked as intended on the console (access to AUX8 prohibited).
    But when logging in via the app Mixing Station with the same user the access was granted (could change AUX8).

    There are only 2 users on my console: Admin (with PW) and Std (without PW).
    I am sure the Mixing Station didn’t log on as Admin because
    a) no PW was demanded at log in and
    b) after deactivating Std (on the console) a PW WAS asked for in the app.

    Is this a bug?

    Bye

    Simon

    #124075
    Profile photo of BrianBrian
    Participant

    This is a limitation of the app Mixing Station. David is aware of it and I believe he is trying to make user logins work/be binding, but there is no telling if/when this will occur. You’ll get a better answer/response if you use the various Mixing Station support methods.

    #124082
    Profile photo of Simon2Simon2
    Participant

    Thanks for the answer.

    But i would expect the console (server) to handle the access permissions and not leave it to the clients.
    It baffles me that it apparently isn’t the case. :-O :-O

    #124092
    Profile photo of KeithJ A&HKeithJ A&H
    Moderator

    Hi Simon,

    User Permissions are not a security setting – they are applied at the console itself or within the app.
    It is not the control of the functions which is blocked, but access to those controls.
    This means for example, you can have a user logged in at the console and a different user logged into an app instance, both with different permissions.
    Mixing Station is a third party app which we do not support, so this would be something you would need to contact them about.

    Thanks,
    Keith.

    #124097
    Profile photo of Simon2Simon2
    Participant

    Hi Keith,

    thanks for the answer.
    But I honestly do not understand how your definition (“… access to the controls…”) is different from mine or how it justifies that the access (to that special control) is not blocked by the console when connecting via app.

    That’s a design flaw in my eyes (and one that should be cautioned about prominently – inexperienced users could do a lot of damage unnoticed by anybody).

    Our console stands in our church and is used by a lot of people. Limiting access to the network and andling with passwords is rather impractical. Also insisting on using the MixPad-App (which we can’t enforce by techical measures anyway) is an massive burden (some of our technicians use different consoles).

    #124101
    Profile photo of KeithJ A&HKeithJ A&H
    Moderator

    @Simon2

    When used in a supported setup (i.e. via the mixer itself or with the CQ-MixPad app), the user permissions will prevent changes being made to the controls *before* they send messages to the core to actually make the changes. We’re preventing the sending of messages, not the reception of them.
    If you bypass the user permissions by using an unsupported connection method (like a 3rd party app), then it’s a bit like hotwiring a car and bypassing the use of the ignition key.

    “Limiting access to the network and handling with passwords is rather impractical” – we always recommend the mixer is on it’s own network and that the network is secure.
    As mentioned, the User Permissions are not a security feature, they’re to prevent inadvertent changes by inexperienced users.

    Thanks,
    Keith.

    #124102
    Profile photo of SQuserSQuser
    Participant

    @Simon2
    The developer David from Mixing Station cannot implement the desired function because his app is simply not supported by A&H.
    The topic has been on his list for a longer time:
    https://mixingstation.app/tasks/T2858

    #124134
    Profile photo of Simon2Simon2
    Participant

    @KeithJ A&H: That’s why those things are usually implemented in the core/kernel and not left for the UI. It opens a can of worms of ‘Don’t do this with your network’, ‘Take care of doing that with your app’, ‘We recommend to users to …’, …
    But OK – that’s the way it’s implemented and it won’t change by me smartassing on the internet. 😉 😉

    Thanks for all your time.


    @SQUser
    : Interesting fact.
    (in contrast, hashing the PW on the client is a good idea securitywise)
    I think, hiding the hash mechanism is one of the above mentioned ‘worm’ and could by a way for us to prevent anyone from using Mixing Station.

    #124135
    Profile photo of SQuserSQuser
    Participant

    > Our console stands in our church and is used by a lot of people. Limiting access to the network and andling with passwords is rather impractical.
    Regardless of the fact that a cooperation between A&H and Mixing Station would be a symbiosis that would benefit both – I admire and thank David for how he worked everything out himself (!) – but on the other hand:
    Well, nothing bad should be able to happen in a church because there is someone who watches over everything and everyone.
    But in the life outside honestly I would never trust the control of my equipment to an open, unprotected network.

Viewing 9 posts - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.