I am working my way into this one.
I noticed that the main change is that the port number is replaced the the identity file
go run simple-server.go -i httpServer.json
in this case.. you dont need to specify the port... unless you want to configure an intercept.. see below... as the port is defined by the port used to provide public access to the controller
ziti edge create service "${service_name}" --configs "${service_name}"-client-config,"${service_name}"-host.v1
I am starting to piece the puzzle together.. I would call this a 10,000 piece puzzle.. equal to one of the largest I have tackled to date
original
func main() {
http.HandleFunc("/hello", hello)
http.HandleFunc("/add", add)
if err := http.ListenAndServe(":8090", nil); err != nil {
panic(err)
}
}
zitified version
func main() {
http.HandleFunc("/hello", hello)
http.HandleFunc("/add", add)
if err := http.Serve(createZitiListener(), nil); err != nil {
panic(err)
}
}
Actually... now that I am preparing my scripts.. I have a question 
When you create the server identity.. you need to enrol it so that the token is passed in when you run the go server.
however... what happens when you want the client to be run on a mobile ziti app.
Do you still enroll it... and then email yourself the token.. so that you can configure the mobile ziti app..
this is the first time I am doing something like this
Once I do thisā¦ I will be setting up the mattermost, zitified ssh and scp toolings
Well you're doing a great job!
technically - you're ALSO replacing the "ip/interface to bind on". With Ziti you don't need to know either of those things which is "pretty cool" (speaking as a developer). The example shows ":8090" which I believe is the implicit convention for 0.0.0.0. It's just not shown.
1 Like
Depends on "how" you're doing it. If you make your own android/ios app - you (as the developer) need to figure out "the right way" to get the jwt to the mobile. NetFoundry chose to email the user the jwt. After you make an identity you can 'invite' that user to the network by sending them a jwt in email.
Or if you're using a Ziti Mobile Edge you can just send the user a jwt encoded as a QR code etc. That's really up to you.
Every device should be sent one (or more, some of us have 'n' identities on our mobile) identity jwt token and each identity sent should get enrolled by the target device.
Anything touching an OpenZiti network needs to have been enrolled. That's what generates the strong identity.
Thanksā¦ very helpfulā¦ which raises another question.
What happens when you have an IoT device as an end point. Say its a vehicleā¦ or a wind turbine etcā¦ that is a machineā¦ rather than a userā¦ so there is not real way to āenrollā the tokenā¦ as there is no real person to do it.
Does this mean that every endpoint needs to be manually configuredā¦ or is there a way to remotely enroll such identitiesā¦ so that it an be fully automatedā¦ though I am not sure how secure that would beā¦ or if its even possibleā¦
In such casesā¦ would you need to setup a provisioning networkā¦ to deploy the identity and enroll each deviceā¦ and then migrate to a production network once complete?
I am curious to know
thanks..this was a real selleys moment.. as I never fully understood the bind concept.. but got it now.. and that IP address that was blank did look funny to me.. but could not see it until you highlighted it
In short.. a bind.. creates the link back to an IP address and port number..
āClient sideā, if you use a tunneller app - yes but itās unlikely to be the same ip on every client machine (same port is guaranteed though). If the āclientā side is an app of your own writing - IP addresses and ports are totally a thing of the past for youā¦ Youād just ādial the serviceāā¦
a bind informs the overlay to send traffic to the application/identity doing the ābindingā.
1 Like