0

Roughly speaking a HTTP SESSION is a kind of secret that the server sends to the client (ex browser) after user's credentials is checked. This secret is passed trough all subsequents HTTP requests and will identify the user. This is important because HTTP are stateless - source.

Now I have a scenario where there is a communication between a machine and a MQTT broker inside the AWS-IoT core. The machine displays some screens. The first screen is the login and password.

The idea here is that after the first screen, IF the credentials are validated, the server should generate a "session" and we should send this "session" across the screen pages. The machine should send this "SESSION" in all subsequent messages and the server must to validate this string before any action. This is a request created by an electrical engineering team.

Me, in the software development side it seems that make no sense since all machines to be connected in the AWS IoT-Core broker (MQTT) must to use a certificate - with is the validation already.

Beside of that, the MQTT broker offers the SESSION persistence capabilities. I know that the SESSIONs (QoS 0/1) in the broker side are related to idea of confidence of delivery and reception of a message.

That being said is it possible to use session persistence in MQTT to behavior like a sessions in HTTP in order to identify users across screens in devices? If yes how?

IgorAlves
  • 5,086
  • 10
  • 52
  • 83
  • 1
    Hi @IgorAlves. I encountered same problem. Did you solve this problem? My problem is related to control user authentication over mqtt broker. – whitefang Sep 08 '22 at 13:59
  • Hi @whitefang, the electrical eng team decided to move forward with this idea and now they are facing a big issue. The best option is to use polices to control with topic a specific machine can pub/sub to. You will find that using polices you will face some limitations as well because the json cant go beyond 2Mb of instructions. You need to investigate special topics provided by AWS to link with the thing Id. – IgorAlves Sep 09 '22 at 19:44
  • Example - { "accessControl": { "aws.greengrass.ipc.mqttproxy": { "com.example.MyIoTCorePubSubComponent:mqttproxy:1": { "policyDescription": "Allows access to publish/subscribe to factory 1 topics.", "operations": [ "aws.greengrass#PublishToIoTCore", "aws.greengrass#SubscribeToIoTCore" ], "resources": [ "factory/1/actions", "factory/1/events" ] } } } } – IgorAlves Sep 10 '22 at 17:02
  • The previous example authorization policy allows a component to publish and subscribe to two topics named factory/1/events and factory/1/actions. https://docs.aws.amazon.com/greengrass/v2/developerguide/ipc-iot-core-mqtt.html – IgorAlves Sep 10 '22 at 17:03

1 Answers1

1

No, HTTP Session concept is not in any way similar to the MQTT session. The only thing held in a MQTT clients session is the list of subscribed topics, a HTTP session can hold arbitrary data.

Also MQTT messages hold NO information about the user or even the client that published the message when it is delivered to the subscriber, the ONLY information present is the message payload and the topic it was published to.

While MQTTv5 adds the option to include more metadata, trying to add the concept of users sessions is like trying to make a square peg fit in round hole.

If you want to implement something as part of the message payload then that is entirely up to you, but it is nothing to do with the transport protocol.

hardillb
  • 54,545
  • 11
  • 67
  • 105