Mosquitto ACL -Configuring and Testing MQTT Topic Restrictions

mosquitto-broker-topic-restrictionsNot only can you restrict access to the Mosquitto MQTT broker using a username and password you can also restrict access to topics using an ACL (Access control list).

Unless you are running an open broker you will want to restrict access to topics so that only authorized users/clients can publish or subscribe to them.

Topic restrictions are configured on the Broker, and there is nothing to configure on the client.

Topic restriction is done in an access control list ( ACL ) file.

To enable topic restrictions you need to edit the mosquitto.conf file to use it.

Note: You should create a copy of the default file as a backup before you edit it.

You will find the setting in the Default authentication and topic access control section:

You need to add the following line (windows install example)

acl_file c:\mosquitto\aclfile.example

A default file ( aclfile.example ) is provided with the installation.

The contents of this file are shown below:


The default ACL file is very restrictive, and if implemented as is, would deny access to almost every topic to every user and client.

The general rule is that, by default, you are denied access unless explicitly allowed.

The file has effectively three sections:

  • General section
  • User specific section
  • Client or user ID section

General Section

Entries here start with the keyword topic and apply to all clients except if the client provides a user name.

If the client provides a username then entries in this section are ignored for that user.

The entry in the default file is

topic read $SYS/#

This gives read (subscribe) access to any client that doesn’t supply a username to the topic $SYS/#.

Any client trying to subscribe or publish to any other topics e.g. house/sensor1 would be denied.

User Section

This section uses the keyword user.

Each user can have topic entries that define access rights. The default file contains the following entry

user roger
topic foo/bar

This entry only apples if the client supplies a username otherwise it is ignored.

The entry means that a user named roger can publish and subscribe on the topic foo/bar.

No other user can publish or subscribe on any other topics.

Note: topic foo/bar is the same as topic readwrite foo/bar

Client or User ID Section

Every client will provide a client ID.

Entries in this section will only apply to the client with that Client ID.

The entry in the default file is

pattern write $SYS/broker/connection/%c/state

This means that a client with client name or ID of P1 can publish to the topic:


and a client with client ID of P2 can publish to the topic


Client P! cannot publish to :


However entries in the General section and User section will also need to be taken into consideration and could allow more access.

The user id is used in a similar fashion.

pattern readwrite phone/inbox/%u/#

Would give user roger publish and subscribe access to:


Detecting Access Control Restrictions

Unfortunately it is not easy to detect ACL restrictions as they aren’t notified to the client.

This means that if a client subscribes to a topic and is denied by the ACL then the client doesn’t know it has been denied as it receives a positive acknowledgement.

In addition if a client publishes to a topic and is denied, again the client doesn’t know it has been denied as it receives a positive acknowledgement. (This you will see in the examples below)

The only way you can really detect a problem is by subscribing and publishing to a topic, and detecting or not detecting the published message.

Access Control Examples -General Settings

In the detailed examples below we look at topic restrictions using the general settings.

Later we look at User and client settings and how they are used to control topic access.

In the examples below we will use a simple python script to subscribe and publish and examine the results on the python client and on the broker console.

In the examples below we will do the following:

  1. Subscribe and Publish to a topic with no ACL configured.
  2. Subscribe and Publish to a topic using the default ACL file.
  3. Edit the default ACL file to allow subscriptions and then Subscribe and Publish to a topic.
  4. Edit the default ACL file to allow subscriptions and publishing and then Subscribe and Publish to a topic.

In each case we look at the various return and error codes shown by the client script, and on the Mosquitto broker console.

For the examples I have enabled logging of all error messages on the broker.

Example 1-Subscribe and Publish to a topic with no ACL configured.

With no ACL being used then we are free to subscribe and publish to any topic.

The screen shots below show that the messages we publish are received.


Example 2- Subscribe and Publish to a topic with the default ACL configured.

With the default ACL being used then we are restricted to reading the #SYS topic.

In the example we subscribe to house/# and publish to house/sensor1

The screen shots below show that the messages we publish are not received which is as expected.

However notice that the subscribe return code and publish return code indicate success.

However the Mosquitto server console logs a published denied message.


Example 3- Subscribe and Publish to a topic with an Edited ACL .

This time we edit the default ACL to allow subscribing to topic house/#

The setting is

topic read house/#

Again,In the example we subscribe to house/# and publish to house/sensor1

The screen shots below show that the messages we publish are not received which is as expected.

However notice that the subscribe return and publish return codes indicate success.

However the Mosquitto server console logs a published denied message.


Example 4- Subscribe and Publish to a topic with an Edited ACL.

This time we edit the default ACL to allow anyone to subscribe and publish to topic house/# .

the setting is

topic readwrite house/#

Again,In the example we subscribe to house/# and publish to house/sensor1

The screen shots below show that the messages we publish are received, which is as expected.

This time the Mosquitto server console logs the message being sent back to the client.


User Restrictions

User restrictions are triggered when the client provides a username.

If a username is provided by the client then the ACL list is checked for that user.

Username restrictions will override General restrictions.

This means that if the General settings allow access to that topic, if the client provides a username, and that user name doesn’t have an entry in the ACL explicitly giving access to that topic, then they are denied.

Client Settings

Client settings usually use the client ID as part of a pattern match.

You normally see entries like:

pattern readwrite house/%c/#

This setting will allow a client with client id python1 to publish and subscribe to topic house/python1/#.

Client python1 will not be able to publish and subscribe to topic house/lights/#.

Client Settings and General Settings are additive. This means that if the client settings don’t allow, but the General settings do then, it is allowed.

Client Settings will override User Settings.

This means that if clients settings allow a client to publish/subscribe to a topic then they are allowed regardless of the user settings.

The Following table tries to summarize the General,User and Client Settings

General Settings

User Settings

Client sends Username




Blank Blank No Blank Denied
Configured Blank or configured No Blank Depends on General settings
Blank or configured Blank Yes Blank Denied
Blank or configured Configured Yes Blank Depends on User settings. General settings don’t apply
Blank or configured Blank or configured No Configured Combination of General and Client settings
Blank or configured Blank or configured Yes Configured Client Settings will override user settings and user settings make General settings irrelevant

Examples Settings

Here are some example settings to illustrate the above

Example 1 -User Settings

#General settings

readwrite topic #

#User settings

user Roger
topic readwrite house/#

#Client settings



Only user roger can publish and subscribe to topic house/#.

If the client doesn’t send a username then the client can publish and subscribe to all topics -entry readwrite topic # in General settings.

Example 2 -User and Client Settings

#General settings


#User settings

user Roger
topic readwrite house/P1/#

#Client settings

pattern readwrite house/%C/#


If the client name is Python 1 then that client can publish and subscribe to topic house/Python1/# regardless of the username sent.

However only user roger can publish and subscribe to topic house/P1/#..

Important Notes:

Topic names and usernames are case sensitive. User roger isn’t the same as user Roger.

Topic house/Python1/# isn’t the same as house/python1/#.

Common Questions and Answers

Q- How do I know if my published message has been denied by the broker or just lost?

A- You cannot tell from the client.

Q-Does the user in the ACL user section need to be added to the passwords file?

A- No, not for the ACL to work, but it does if you are also using username and password authentication.

Mosquitto v2-Mosquitto_ctrl

The Mosquitto_ctrl tool was introduced with mosquitto v2 and is used for dynamically making user and ACL changes on a mosquitto broker.

It effective replaces the password and ACL file and settings but is not enabled by default and is only likely to be used when an organisation has a large collection of brokers with many frequent changes. Using the Mosquitto_ctrl Tool


You can restrict access to a broker by configuring Access control.

Access control can be applied to users,client ids and topics.

From a client perspective it isn’t easy to know if access control is being applied as restrictions aren’t notified to the client in MQTT v3.1.1.

Was This Useful?

Mosquitto Configuration Tutorials

Related Tutorials and Resources

Please rate? And use Comments to let me know more


  1. Hi Steve,

    Thanks for this informative article.

    What is the difference between user id and client id?

    I would like to have the pattern match for each user instead of each MQTT client.

    For example, I have a user who logs into 2 MQTT clients, and I would like these 2 clients to be able to subscribe to the same topic which is constructed using the user information, such as username or user id, like: topic/{the user name of user id}/#

    Is it possible?

    1. The user id is the user name. yes you can do what you want there is an example in the tutorial

      pattern readwrite phone/inbox/%u/#

  2. I have a situation where in I have standard clients for example

    Client 1 can write to topic `test`
    Client 2 can only read from `test`.

    Is there any way to define such a rule in ACL?

    1. When you say client 1 etc are you using assigned client names? Are you using usernames/passwords?

  3. hello, i need to make for a school project a broker with the following thing: if you are an anonymous user you can only sub to project/widows/ram but not to other projects.
    How can i do that?

    Kind regards

  4. Hello Steve,

    I have problems to create an ACL file with the following function:
    – every client should only be able to receive and write topics starting with client id (e.g. CID/#)
    – one “master” client should be able to receive/write all topics.

    My ACL file looks like:
    topic readwrite %c/#
    user master
    pattern readwrite #

    With this file a client receives also topics which are not %c/# when it subscribes to “#”.

  5. Hey, First of all, thanks for the amazing blog.

    I have one question about the approach I want to implement, __The client is restricted to publishing only topics that are prefixed with its own client ID. __ For example, client123/temperature or client123/#.”

    How to do this in the Node js project, which is headless. For now, this makes sense in Angular, as the user will be logged in there, and can get the client Id on the basis of that. BTW I’m using, PHP as a back-end, for an angular project. I’m using Node js only to subscribe/publish topics and update the database.

    1. Not quite sure about the client id as it is usually a part of the client code or are you trying to get it dynamically.

  6. Hello Steve.
    How can a user be identified by an ID?
    You used %c But in the pwfile i can only set an user and a password (user:pwd).
    How can i know that the ID %c refers to roger?

    1. Hi
      It is not the user name but the name of the client. every client has a client is which must be unique. Does that make sense?

  7. Thanks for the great articles. I have spent hours here trying to fix a mosquitto 2.0.12 install that was accidently deployed in an unpinned docker-compose file (lesson learnt). I know I could just go back to mosquitto 1.6 but I thought I’d try and fix this. The v2 breaking changes indicate that an acl file is now required. I was previously only using a passwd file for clients.

    I generated the acl file below:

    user homeassistant
    topic #

    and changed my mosquitto.conf file:

    persistence true
    persistence_location /mosquitto/data/
    log_dest file /mosquitto/log/mosquitto.log
    log_timestamp true
    log_timestamp_format %Y-%m-%d|%H:%M:%S
    log_type error
    log_type notice
    #log_type information
    #log_type debug
    #log_type all
    #log_dest topic
    #log_type warning
    max_keepalive 10
    allow_anonymous false
    connection_messages true
    per_listener_settings false
    listener 1883
    password_file /mosquitto/config/passwd
    acl_file /mosquitto/config/aclfile

    I am testing with mqtt explorer and whilst I can authenticate I cant do anything because I get the error: “Connection refused: identifier rejected”

    The use is authenticating (verified by changing password), its the ACL part that is not working. From what I have read, that acl file above should give the user (homeassistant) readwrite access to all topics.

    The mosquitto logs:

    021-09-17|19:01:14: New connection from on port 1883.
    2021-09-17|19:01:14: New client connected from as mqtt-explorer-dc55337b (p2, c1, k60, u’homeassistant’).
    2021-09-17|19:01:14: Bad socket read/write on client mqtt-explorer-dc55337b: Invalid arguments provided.

    Not sure what else I can try, been at this for hours today.

  8. I wasn’t able to use the topic filter %u and/or %c when using the dynamic security plugin for the topic restrictions to the particular user based on the username and/or client id.
    my sample role JSON:
    “rolename”: “Role for Client”,
    “textname”: “.”,
    “textdescription”: “.”,
    “acls”: [{
    “acltype”: “publishClientSend”,
    “topic”: “%u/#”,
    “priority”: 0,
    “allow”: true
    }, {
    “acltype”: “publishClientReceive”,
    “topic”: “%u/#”,
    “priority”: 0,
    “allow”: true
    this would only allow to send and receive to the topic matching prefix “%u”.
    I wanted to publish and subscribe to topics such as usernameone/data, usernametwo/data, etc using the same role for multiple clients instead of having individual roles for doing so.
    Do you have any implementation to achieve the same?

    1. I haven’t had chance to do any tests but reading through it you may need to also use the subscribePattern
      mosquitto_ctrl -h -u steve dynsec addRoleACL role1 subscribePattern %u/# allow

      Update: I don’t think the %u notation is supported have you seen it anywhere in the docs?

      1. Yeah, I tried with all the four basic ACLtypes but it’s not working.
        No there is not any documentation for the use of client id and user id in the dynamic auth plugin. Maybe it’s not supported. Even though using both ACL files and the Dynamic Auth plugin I wasn’t able to achieve the desired goal. maybe the acltypes in the dynamic auth plugin override the client settings of the aclfile.

        1. I was trying it yesterday and I don’t think it is supported but the %u and %c functionality was very useful and so maybe it will be implemented in the future. As for using the two forms together I would think that it would cause confusion and surprised it is allowed.
          It is still early days with the plugin and it will make it much easier to setup ACLs. I will keep my eye on it for changes.

  9. Can we add this ACL dynamically through program or code ? Because here we are adding the list in config file staticaly right ? so how can we add or remove topics to this list while performing one operation? Like dynamically adding elements to list ? Can we do that ? Please reply..

  10. Dear Steve,

    CAN we create a dynamic ACL List while runnning the code.. I mean, when we edit the config file and add the list means, it is a static config file right ? ,Can we add those entries dynamically ?
    Kindly reply . Iam stuck with this…

    1. You can make change to the config file and reload it without a restart but not all changes are possible without restarting the broker you will need to check the documentation

  11. Hey steve,
    I want of restrict topic access at runtime(programmatically). i fond one way to do that is mosquitto_auth-plug. But when i tried then lots of error is coming and its not working. Please provide me some way to achieve that.

  12. Hi Steve,

    Great article, thanks!

    I’m just not sure if I got the “Client Settings will override User Settings.” statement right.
    In my test cases the behaviour was additive and I couldn’t see any “overriding”.

    So if I have

    user roger
    topic readwrite foo

    pattern read bar/%c

    roger would be able to both readwrite “foo” and read “bar/%c”.

    What am I not getting here?

    Thank you very much in advance,


    1. Hi
      I know its confusing.
      if we use these settings as they make more sense
      user roger
      topic readwrite foo/#

      pattern read foo/%c

      and assume 2 clients the first client users username (roger) and password and publishes to foo/bar and foo/bar1
      client 1 subscribes to foo/#
      client 2 subscribes to foo/bar and foo/bar1
      client1 id is bar
      client 2 has an id of bar1.
      Client 1 receives messages published on foo/bar and foo/bar1
      Client 2 receives message published on foo/bar1

      Now if we change the settings
      user roger
      topic read foo/#

      pattern readwrite foo/%c
      Now even though roger has only read access to foo/# he can read and write to foo/bar but not foo/bar1
      Hope that makes more sense.
      I think I need to expand the tutorial with more examples

  13. Hi Steve,
    Thanks for the wonderful resources. I am a newbie to MQTT and your tutorials helped me to build a successful running broker on Raspberry Pi.
    But I am stuck with ACL I am trying to use Rpi MQTT broker as an outdoor lighting controller and esp32 mqtt client on the light.

    – I am trying to establish a dynamic ACL list where the client when connecting, publishes their light specifications to the controller and controller will send back ACK message and makes the light available on the authorized devices list. Here we don’t have a specific number of lights as preset as users as light1. but they are an individual client that I needed to control individually
    Usecase: Ex: Light 1 ->> PING –> Controller; Controller –> PONG-ACK — Light 1

    – When controlling the intensity of a specific light or group of lights, I wanted to control them via publishing intensity via topic.

    Requesting to help me design a dynamic clients, where I can publish to the selected client or a group of clients.

    1. Hi
      It isn’t possible to create a dynamic ACL. Access would need to be controlled via the controller.
      I would need to know more about the lights and controller to help with the design. For example are the lights switched on/off by the controller?

  14. Hi, very good article!
    I have users defined and the authorization works fine.
    Then I’ve added a ACLFILE with a pattern and works fine:

    ACLFILE working fine:
    pattern readwrite %u/#

    Then I want to add a user with other permissions, and the user works fine, but the rest of users using the pattern broke and fail connection.

    ACLFILE fails for all user except the superuser, this user works fine :
    user superuser
    topic #

    pattern readwrite %u/#

    Any help? Thanks!

    1. Hi
      I’ve just tested it and it worked ok. When testing turn off authentication by allowing anonymous access that way you only test the acl restrictions.

  15. sir,
    can you please explain about the client setting section ?
    i want to restrict the topic based on client id .(eg) if i use device/client_id/num as my publish topic(i give publish client id in client_id section). what would be my sub topic ?

      1. my aclfile:
        # This affects access control for clients with no username.
        #topic readwrite $arc/#
        # This only affects clients with username “roger”.
        user roger
        topic dev/pub
        # This affects all clients.
        pattern readwrite dev/%c/pub
        #pattern write $SYS/broker/connection/%c/state

        my publish command:
        mosquitto_pub -i id_1 -h -t dev/id_1/pub -u roger -P chennai -m “hello” -d
        my subscribe command:
        mosquitto_sub -i id_1 -h -t dev/id_1/pub -u roger -P chennai

        when i provide client id for publish. message not received.

        1. Haven’t checked it on my broker but the topic for roger is dev/pub but you are sending and subscribing on dev/id_1/pub
          try change to dev/# or dev/id_1/#

          1. thanks for the replay.
            user roger topic dev/pub works fine.
            but i want to restrict the topic based on client id.
            can you please explain how to use this section:
            # This affects all clients.
            pattern readwrite dev/%c/pub

          2. Ok
            the pattern readwrite dev/%c/pub
            will only allow clientid of say python1 to subscribe and publish to the topic
            if you want others to read then use
            topic read dev/#
            You shouldn’t then supply a username. If you do then you need a user entry for all users.
            I haven’t had chance to try it. Let me know the exact requirements and whether or not usernames are being sent.

      2. my debug log:
        1583827375: New connection from on port 1883.
        1583827375: New client connected from as id_1 (p2, c1, k60, u’roger’).
        1583827375: No will message specified.
        1583827375: Sending CONNACK to id_1 (0, 0)
        1583827375: Received PUBLISH from id_1 (d0, q0, r0, m0, ‘dev/id_1/pub’, … (5 bytes))
        1583827375: Received DISCONNECT from id_1
        1583827375: Client id_1 disconnected.

        received publish from id_1 but not send to subscribe.

  16. Excuse me Steve,
    Can i limit topic’s message count?
    Example each client only can publish 100 messages in day or hour
    In my project,client can publish unlimit message to broker and it is unsafe for my server and broker
    Do you have idea?

    Thanks so much

        1. Hi
          Not as far as I can tell. I haven’t seen anything in the mosquitto.conf file that lets you restrict a use to so many messages/hour etc

          1. Yes i haven’s seen about this topic
            Finally i decided counter topic’s message and limit it runtime

  17. Hi Steve,

    I am running Mosquitto on Ubuntu, any time I try and enter a line in mosquitto.conf regarding “topic” or “pattern” and restart the service my client will no longer connect.

    If I try and point it to an “acl_file” I get the same problem. I have created a whole new build and get the same issue… Any idea where I might be going wrong?

    Really appreciate your work, have used it to guide many time, thank you!

    1. Hi
      Can you use the ask steve page and send me a copy of the mosquitto.conf file and the acl file and I’ll take a look.

  18. Hi Steve
    I have below ACL

    # This affects access control for clients with no username.
    user robot
    topic readwrite Location
    topic readwrite Status

    # This affects all clients.
    pattern write Location/%u
    pattern write Status/%u

    I need to robot can readwrite Location or Status topic
    And other users only can write to this topics
    Is my code correct?

    1. Hi
      Don’t think that will work as the user robot entry stops all access for anyone supplying a username.

      Does user robot require write access to other user locations or just read?

        1. Remove the user section
          user robot
          topic readwrite Location
          topic readwrite Status
          and replace it with
          topic read Location
          topic read Status
          in the general section

          1. What about write topic for user?
            topic read Location
            topic read Status
            pattern write Location/%u
            pattern write Status/%u

            Is it?

  19. Hello Steve,
    ty for the great mqtt-content.

    Is it possible to have multiple listeners, with each one having there own acl file?
    The first option in the mosquitto.conf file (per_listener_settings) indicates that, but Iยดm not sure how to assign multiple acl files to there listeners, any idea?

    1. It looks like the ACL is a broker wide configuration. You could always start multiple broker instances with there own ACL file

          1. Yes, I tested it and it works fine.
            I have two different ACL-files that give different restrictions. This is my mosquitto.conf file:

            # General configuration
            per_listener_settings true
            sys_interval 10
            #set_tcp_nodelay true

            # Default listener
            port 8883
            cafile certs/ca.cert.pem
            keyfile certs/ddc4kiot.key.pem
            certfile certs/ddc4kiot.cert.pem
            require_certificate true

            allow_anonymous true
            acl_file aclfileTLS.conf

            # Extra listeners
            listener 1883

            allow_anonymous true
            acl_file aclfile.conf

            In this case clients using the TLS connection are allowed to read/write to a specified topic, while clients using the not secured connection are only allowed to read.
            Tests approve this. I tested different variations aswell. All work as expected.

  20. Hi Steve,
    I’m trying to set the ACL with an admin user with access to all topics, and a pattern for normal users.
    I’ve tried the following in the acl_file:
    user admin
    topic readwrite house/#
    pattern readwrite house/%u/#

    In my password file, I have 2 users: admin and user1. I can connect fine using admin. However, as soon as I try to connect using user1, I get a socket error from the broker, and both admin and user1 gets disconnected.

    Help appreciated. Thanks

      1. Hi Steve,
        I checked, and sure enough the client_ids were the same. I generated a new client_id for user1, but user1 still can’t connect. The admin stays connected this time.

  21. Hello.
    Could you help me, please, to solve mqtt access problem?

    I have client’s authorization with certificates.
    And it works fine.

    But i also need to add one client’s authorization, as admin, to read all client’s topics.

    My ACL:
    pattern readwrite %u/#
    user admin
    topic readwrite #

    But in this way nobody has access to write/read topics.
    If i did in ACL only – pattern readwrite %u/# – work fine.

    How can i use certificates and user authorization in one ACL?

    1. Hi
      Can you try again I just tested it with:
      user admin
      topic readwrite house/#

      pattern readwrite houde/%u/#

      and it worked as expected.
      admin could access all topics under house/

      1. Hello, Steve.
        Thank you for your answer.
        But if i use the same contruction, nobody can connect (even with certificate).

        Could you show me your config, please?

        My config:

        allow_anonymous true
        password_file /etc/mosquitto/passwd

        listener 1883 localhost
        listener 8883
        cafile /etc/mosquitto/mqtt_ca.crt
        certfile /etc/mosquitto/cert.crt
        keyfile /etc/mosquitto/cert.key
        require_certificate true
        use_identity_as_username true
        acl_file /etc/mosquitto/mqtt.acl
        tls_version tlsv1.2

        1. My config doesn’t use certificates
          # Place your local configuration in /etc/mosquitto/conf.d/
          # A full description of the configuration file is at
          # /usr/share/doc/mosquitto/examples/mosquitto.conf.example

          pid_file /var/run/

          persistence true
          persistence_location /var/lib/mosquitto/

          #log_dest file /var/log/mosquitto/mosquitto.log

          include_dir /etc/mosquitto/conf.d
          port 1883
          log_type error
          log_type notice
          log_type information
          log_type debug
          log_type websockets

          connection_messages true

          log_type all
          log_dest stdout
          acl_file aclfile.example

          The acl_file is
          # This affects access control for clients with no username.
          #topic read $SYS/#
          #topic read +/r2
          #topic readwrite #

          # This only affects clients with username “roger”.

          user steve
          #topic read +/r1
          topic readwrite house/#

          # This affects all clients.
          #pattern write $SYS/broker/connection/%c/state
          #pattern write house/%C/#
          pattern readwrite house/%u/#

          I used steve not admin. With the above file all users will need a username.

          1. Glad to hear that. Would appreciate any tips on using auth-plugin as I haven’t tried it yet

  22. Hi,

    I am facing an issue while configuring the acl so that the client can subscribe to a specific subtopic. Actually I want that the client should subscribe to +/r1 and publish at +/r2.

    Following is my acl file content:
    user xyz
    topic read +/r1
    topic write +/r2

    But the issue is the client can read all the topics even r2, r3 or anything else.

    1. Hi
      The problem with your current acl is that only usere xyz can publish on +/r2 which works OK. However user xyz can subscribe to +/r1 which no one can publish on.
      When I test it I see the publish being denied on all topics except +/r2.
      To see what is being published use:

      user steve
      topic read +/r1
      topic readwrite +/r2

      or to the general section add
      topic read +/r2
      topic read #
      depending on how restrictive you want it.

  23. Hello!
    1) Can more than one user share the same topics in the ACL? Like:
    user Roger
    user Paul
    topic readwrite house/temperaturesettings
    topic readwrite house/doorlocks

    2) “Client Settings will override User Settings”. This sounds strange to me. It seems to me that any malicious user with a valid password can get access to any topic by just changing it’s client id to one with nice privilegies? Or did I miss something?

    1. Hi
      Its seems like the structure is
      user superuser
      topic readwrite #
      user steve
      topic readwrite #

      I tried putting users on one line with commas and it didn’t work
      You are correct that the client could use a client_id that had access but it would need to know these as they are not sent by the broker.

  24. Hi, i’ve been spelling and testing but I’m stuck… ๐Ÿ™

    I’ve got an x-number registered mqtt users. I use the pattern:
    pattern readwrite %u/#

    This does exactely what I want. The problem arrises if I want to add a ‘superuser’ who may see everything. If I add
    user superuser
    topic #

    All the other users are not allowed anymore. The only way i’m able to allow them is by adding them to the acl file.

    Do you have a generic way / pattern to add this superuser without having to specify the others?


    1. Hi
      I tried it and it worked as expected. Here is the file I used
      # This affects access control for clients with no username.
      topic read $SYS/#
      #topic read house/#
      #topic readwrite #

      # This only affects clients with username “roger”.
      user superuser
      topic readwrite #

      # This affects all clients.
      #pattern write $SYS/broker/connection/%c/state
      #pattern write house/%C/#
      pattern readwrite house/%u/#

      1. Hi Steve, turned out that the acl is only red at mosquitto start and not at user-connect. I wanted to implement a dynamic authorization via the acl-file . This would have been an easy solution. Now I must checkout how to use the auth_plugin. The problem is that from html direct to mosquitto you must provide user and password. This is unacceptable in my situation so I must find a way to do the checking on the server. For a moment I was thinking javascript websockets to php and bridge php to mqtt but this looks less performant than to use a plugin.

    2. Hi Felix, I am in the same error you described.
      Pattern works alone, but when I add a user, the patter stop working and only is valid the user.
      Could you fix your problem? How?

      ACLFILE working fine:
      pattern readwrite %u/#

      ACLFILE fails for all user except the superuser :
      user superuser
      topic #

      pattern readwrite %u/#

      Any help? Thanks!

  25. Hello Steve,

    I get following when i try to implement clientID pattern ‘Unknown configuration variable “pattern”‘, any help would be appreciated.

    1. I assume this is when you try to start mosquitto. Can you use the ask steve page and send me you conf file or paste the relevant lines in the comment box

  26. dear steve,

    when I should edit mosquitto.conf or /etc/conf.d/default.conf?

    I’m really in doubt bc I tought that default.conf is a substitute for mosquitto.conf…

    1. Hi
      You should edit the mosquitto.conf file. When testing I create a new conf file and use that as it is easier than editing the mosquitto.connf file as you need su permission.

  27. Hello Steve! When I put the acl_file entry on conf.d/default.conf, it stops all authentication: nothing can even connect to the broker. Why?

  28. Hi Steve,

    Great article, very informative. Is it possible to deny access by IP Addresses? Or to only allow access to specific IP Address?


    1. Glad you found the article useful. You cannot restrict access by IP address using the mosquitto.conf file. In a way it is not surprising as client IP addresses can change.
      If you needed to do that then you could use IPtables on Linux.

  29. Hello Steve,

    Thank you for the article. It is very imformative. I was wondering is there any way to use external service as acl data provider. I mean in this example broker loads file. But you have to reload it every time acl change a happens. Would it be possible to use database to check acl?

    1. Not as far as I know but the broker is being upgraded to support mqtt vs 5 and things might change then.
      Last time I checked it was supposed to be released in august but I haven’t heard anything. Here is a link to the blog

  30. Does the broker return anything that lets clients know whether their messages get denied?

  31. Hi
    My users are more than 1 million
    And I am needing user only subscribe in self userid
    So I have to add all user self topic in acl
    If acl contain 1 million user in file so mosquitto cannot load it
    Do you have idea for prevent sinscribe user in other topic for many users?

    1. You probably need to think of a different solution with so many users. I doubt if mosquitto would handle them.

Leave a Reply

Your email address will not be published. Required fields are marked *