To prevent unwanted access and control to RR jobs, RR has implemented different authorization levels.



Authorization - take network connection information


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 

  • Whitelist:
    You can tell the rrServer that it requires a valid user login if the connection is send from outside your network.
    e.g. A remote connection through your router.
    Add the start address of your IPs in your company network to the Whitelist in rrConfig, tab rrLogins, lower left.
    E.g.  192.168.0.
  • Required for all connections:
    You can enable that the rrServer requires a valid user login for all connections.
    The setting can be found in rrConfig, tab rrLogins, lower left "Authorization required for all connections".
    Note: This affects rrControl as well.



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

FROM: 192.168.0.24

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.


Authorization - user rights

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)

Passwords and encrypted data

RR will never send any passwords.

A second layer of TCP encryption (e.g. ssh) is not required.



rrServer requests:

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:

  • The MD5 hash of the password you use for RR.
  • Type of data/command send (e.g. "job command", "job information", "client list", "user change",..)
  • Amount of data send (how much bytes)