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

Topic prefix based on host name? #85

Closed
torntrousers opened this issue Jun 24, 2022 · 4 comments
Closed

Topic prefix based on host name? #85

torntrousers opened this issue Jun 24, 2022 · 4 comments
Labels
discussion Something to be discussed

Comments

@torntrousers
Copy link
Collaborator

Is there some way I could configure something so that I can set a root topic based on the host name that devices are connecting to the broker with?

What I mean is my server is available with a wildcard domain - *.myserver.com. Clients can then connect with eg foo.myserver.com or bar.myserver.com and publish / subscribe to topics, so is there some way if a client connects to foo.myserver.com and publishes to topic 'someTopic' that the server would make the actual topic "foo/someTopic"?

@mochi-co
Copy link
Collaborator

I think so! Have a look at the OnProcessMessage event hook.

https://github.com/mochi-co/mqtt/blob/master/server/events/events.go#L49
https://github.com/mochi-co/mqtt/blob/master/examples/events/main.go

And then you could do something like this...

server.Events.OnProcessMessage = func(cl events.Client, pk events.Packet) (pkx events.Packet, err error) {
  // Check if pk.TopicName is 'someTopic'
  pkx = pk  
  // Modify pkx.TopicName to new topic
  return pkx, nil
}

I'm not sure how you could determine the wildcard domain for the client though. Open to throwing some ideas around. We expose the connecting client address in events.Client.Remote if that's any use.

@torntrousers
Copy link
Collaborator Author

Thanks. Thinking about it properly though it would be better to not have a topic prefix but to have a whole seperate instance per sub-domain. So foo.myserver.com and bar.myserver.com are issolated and topic "someTopic" in one is not visible to the other. I guess that means a speperate instance of the Mochi MQTT server for each.

The way I have it presently uses the Go TLS Config GetConfigForClient to get the client hello which has the server name the mqtt client is calling and so from that I can find the subdomain.

type Server struct {
 . . .
	mqttBroker *mqtt.Server
}

. . .

	mqttTlsConfig := &tls.Config{
		GetConfigForClient: s.getConfigForMqttClient,
	}

	s.mqttBroker = mqtt.NewServer(nil)
	tcp := listeners.NewTCP("myMQTT", "localhost:8883")
	err := s.mqttBroker.AddListener(tcp, &listeners.Config{
		Auth:      new(auth.Allow),
		TLSConfig: mqttTlsConfig,
	})
	if err != nil {
		log.Fatal(err)
	}

	go s.mqttBroker.Serve()
	log.Println("MQTT Broker Started!")

. . . 

func (s *Server) getConfigForMqttClient(hi *tls.ClientHelloInfo) (*tls.Config, error) {
	log.Println("Server.getConfigForMqttClient hostName:", hi.ServerName)

	ctx, err := s.GetContext(hi.ServerName)
	if err != nil {
		return nil, err
	}

. . .

but i need some way for that to use multiple instances of Mochi mqtt.Server instead of just the one.

Probably too much for this Github issue and I need to work it out myself...

@mochi-co mochi-co added the discussion Something to be discussed label Jul 3, 2022
@mochi-co
Copy link
Collaborator

@torntrousers Very interested to hear updates if you made any progress on this.

@torntrousers
Copy link
Collaborator Author

We ended up implementing our own TLS listener which managed a collection of Mochi MQTT Servers and our listener called the Server EstablishConnection function on the appropriate Server. Seems to work ok.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Something to be discussed
Projects
None yet
Development

No branches or pull requests

2 participants