[ExHook] EMQX Still Perform Publish Even When the Authorize Hook Returns False

[TxMat]

What happened?

When using ex hooks the publish handler is called event when the authorize hooks return false.

What did you expect to happen?

When the authorize hooks return false, drop the current message and continue the execution without trying to route the message to save resources

How can we reproduce it (as minimally and precisely as possible)?

using the following on_client_authorize handler

pub async fn on_client_authorize_handler(request: Request<ClientAuthorizeRequest>) -> Result<Response<ValuedResponse>, Status> {
    let request = request.into_inner();
    trace!("Got a request: {:?}", request);
    let client_info = request.clientinfo.as_ref().unwrap();
    trace!("rtype: {:?}", request.r#type);

    let authorise_response: Result<Response<ValuedResponse>, Status> = Ok(Response::new(ValuedResponse {
        r#type: emqx::exhook::v2::valued_response::ResponsedType::Continue as i32,
        value: Some(Value::BoolResult(true)),
    }));

    let unauthorised_response: Result<Response<ValuedResponse>, Status> = Ok(Response::new(ValuedResponse {
        r#type: emqx::exhook::v2::valued_response::ResponsedType::Continue as i32,
        value: Some(Value::BoolResult(false)),
    }));

// snip

   return unauthorised_response;

using the following on_message_publish handler

pub async fn on_message_publish_handler(request: Request<MessagePublishRequest>) -> Result<Response<ValuedResponse>, Status> {
    info!("Got a request: {:?}", request.get_ref());

you can see the request being forwarded to the on_message_publish handler even if the authorize hook returned false

Anything else we need to know?

No response

EMQX version

$ ./bin/emqx_ctl broker

sysdescr  : EMQX
version   : 5.3.1
datetime  : 2023-11-30T16:24:31.441778248+01:00
uptime    : 7 hours, 21 minutes, 3 seconds

OS version

# On Linux:
$ cat /etc/os-release

NAME="Fedora Linux"
VERSION="39 (Workstation Edition)"
ID=fedora
VERSION_ID=39
VERSION_CODENAME=""
PLATFORM_ID="platform:f39"
PRETTY_NAME="Fedora Linux 39 (Workstation Edition)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:39"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f39/system-administrators-guide/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=39
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=39
SUPPORT_END=2024-11-12
VARIANT="Workstation Edition"
VARIANT_ID=workstation


$ uname -a

Linux Host-001 6.5.12-300.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Nov 20 22:44:24 UTC 2023 x86_64 GNU/Linux

Log files

[SergeTupchiy]

Hi @TxMat ,

I assume you have the default EMQX file authorization enabled, which ends with {allow, all}. rule.
As this is matched (before calling exhook), external on_client_authorize is not even called and message processing continues, triggering on_message_publish ex hook.
If my assumption is correct, please try disabling File authorization in EMQX dashboard and repeat the experiment.

[TxMat]

Hi @SergeTupchiy

Thanks for the quick response, unfortunately I do not have the emqx file authorization enabled as well as any other auth/authorization option enabled. Everything pass though exhooks, and my client authorize hook is called as it prints to stdout and does some work on my back end.

Also when returning false it successfully blocks any unauthorized subscribe request

Only the publish hook seem to be called even after a failure of the authorization

Is this expected behaviour?

[SergeTupchiy]

@TxMat,
It's not expected. Can you check what happens on EMQX side when you publish a message?
Does it log a warning like:

2023-12-01T11:34:41.542812+02:00 [warning] msg: cannot_publish_to_topic, mfa: emqx_channel:process_publish/2(641), peername: 127.0.0.1:56052, clientid: mqttx-cli-pub, topic: t/test, reason: not_authorized

?

[TxMat]

I unfortunately was unable to replicate the bug Friday and today at work so i'll close the issue. If it shows up again i'll reopen it and provide you the logs of the broker.