Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using Retained topics will always cause last access attempt to re-trigger any time anything (Re-)subs to this topic #128

Closed
PrimusNZ opened this issue Jul 18, 2018 · 3 comments
Labels

Comments

@PrimusNZ
Copy link

PrimusNZ commented Jul 18, 2018

https://github.com/omersiar/esp-rfid/blob/a7fa3eda05cde1c566ec172934ff38308385423a/src/main.cpp#L535
https://github.com/omersiar/esp-rfid/blob/a7fa3eda05cde1c566ec172934ff38308385423a/src/main.cpp#L597

Both of these lines are using the retain option as true, This is potentially bad idea - Should really be false, OR a configurable option in the UI, because if anything that subs to this topic drops off (Or is restarted) and re-subs to the topic, it will get the last scan information again because the information is retained.

I.e. if I access a locked door that requires a scan, I leave, locking manually or by some other means not using the RFID scanner, if the system responsible for controlling that door re-subs to the topic for any reason, the door will unlock

@PrimusNZ PrimusNZ changed the title Using Retained topics will always cause last access attempt to re-trigger any time anythign subs to this topic Using Retained topics will always cause last access attempt to re-trigger any time anything (Re-)subs to this topic Jul 18, 2018
@omersiar
Copy link
Collaborator

I do not know how this is possible, there is two function that triggers the Relay Pin, one is successful checking UID and the Permission and the other one is Websocket command "testrelay". This maybe caused by a non flushed memory.

Anyway the fix is easy:
https://github.com/marvinroger/async-mqtt-client/blob/master/docs/2.-API-reference.md#uint16_t-publishconst-char-topic-uint8_t-qos-bool-retain-const-char-payload--nullptr-size_t-length--0-bool-dup--false-uint16_t-message_id--0

@PrimusNZ
Copy link
Author

You're assuming that this device will be the scanner AND the locking mechanism - In my setup (And a few others that I know of), this is just being used as an RFID reader - thats it.

In a scenario of where its both reading the card AND triggering a relay, yes your solution works fine.
In a situation where its just acting as an RFID tag reader, this will cause authentication problems with MQTT devices at the other end subbed to the topic - using retain for any kind of authentication is bad

@omersiar omersiar added this to the 0.7.7 milestone Jul 18, 2018
@omersiar omersiar added the bug label Jul 18, 2018
@omersiar
Copy link
Collaborator

Oh, now it makes sense, also we are using MQTT as an extra information for brokers, not for the authentication. You should modify the work flow for your scenario, one may also craft an MQTT message to trigger your lock easily if it's depending on only MQTT messages.

Since MQTT library allows us to change retain flag, i will change it to not to retain publishes.

Thank you.

@omersiar omersiar closed this as completed Aug 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants