To prevent unwanted access and control to RR jobs, RR has implemented different authorization levels.
By default, the rrServer does NOT check for a valid user if you connect to the rrServer.
You can enable user authorization to even connect to the rrServer
If authorization is enabled:
If you connect to the rrServer, then it checks if you are a valid user.
The user name is either taken from rrControl or if you use the external module libpyRR2, then from tcp.setLogin("TestUser", "Password")
If the login fails, then the server adds an entry to the file [RR]/sub/log/server_...._AuthFail.txt
SEND: Name:CustomMachineName TimeZone:02:00 app:Script
AUTH: User:UserName rrUserID:-1 PW:d41d8cd98f0b24e980998ecf8427e
DATA: JobCommandSend 1 60040 60040 0
Note: The "PW" is not the password in clear text. It is only a checksum.
Even if you are valid to change your jobs, your company might have decided that you cannot view or change jobs of other projects.
Job commands just require the ID number to send commands.
Therefore the user you use for tcp.setLogin has the right to change jobs via remote/script.
Set this user right in rrConfig, tab rrLogins.
If your user does not exist or if you do not specify a user name, then you have to give Anonymous the right to change jobs. (in combination with the Whitelist as described above)
RR will never send any passwords.
A second layer of TCP encryption (e.g. ssh) is not required.
If you send a command to the rrServer, then RR sends the MD5 checksum of the password you entered.
Data from the rrServer
If the rrServer sends data back to you (e.g. a job list), then this data is encrypted with your password.
The rrServer knows your password as you have entered it into rrConfig tab logins.
The data is send to you and your local RR module decodes the data with the password you have entered/given on your machine/script (e.g. tcp.setLogin() ).
Only if the passwords match, you can decode the data.
Man in the middle:
Someone analyzing RR packets and sniffing your TCP data can get: