Broker and protections
To apply the IP address of a broker user’s workstation against the
protections table, prepend the string proxy- to the
workstation’s IP address.
Before you prepend the string proxy- to the
workstation’s IP address, make sure that a broker or proxy is in place.
Consider an organization with a remote development site
with workstations on a subnet of 192.168.10.0/24. The
organization also has a central office where local development takes
place; the central office exists on the 10.0.0.0/8 subnet. A
Perforce
service resides in the 10.0.0.0/8 subnet, and a broker
resides in the 192.168.10.0/24 subnet. Users at the remote
site belong to the group remotedev, and occasionally visit
the central office. Each subnet also has a corresponding set of IPv6
addresses.
To ensure that members of the remotedev group use the
broker while working at the remote site, but do not use the broker when
visiting the local site, add the following lines to your protections
table:
list group remotedev 192.168.10.0/24 -//... list group remotedev [2001:db8:16:81::]/48 -//... write group remotedev proxy-192.168.10.0/24 //... write group remotedev proxy-[2001:db8:16:81::]/48 //... list group remotedev proxy-10.0.0.0/8 -//... list group remotedev proxy-[2001:db8:1008::]/32 -//... write group remotedev 10.0.0.0/8 //... write group remotedev [2001:db8:1008::]/32 //...
The first line denies list access to all users in the
remotedev group if they attempt to access
Helix Server
without using the broker from their workstations in the
192.168.10.0/24 subnet. The second line denies access in
identical fashion when access is attempted from the IPV6
[2001:db8:16:81::]/48 subnet.
The third line grants write access to all users in the
remotedev group if they are using the broker and are working
from the 192.168.10.0/24 subnet. Users of workstations at
the remote site must use the broker. (The broker itself does not have to
be in this subnet, for example, it could be at
192.168.20.0.) The fourth line grants access in identical
fashion when access is attempted from the IPV6
[2001:db8:16:81::]/48 subnet.
Similarly, the fifth and sixth lines deny list access to
remotedev users when they attempt to use the broker from
workstations on the central office’s subnets (10.0.0.0/8 and
[2001:db8:1008::]/32). The seventh and eighth lines grant
write access to remotedev users who access the
Helix Server directly from workstations on the central office’s subnets. When
visiting the local site, users from the remotedev group must
access the
Helix Server
directly.
When the
Perforce
service evaluates protections table entries, the
dm.proxy.protects configurable is also evaluated.
dm.proxy.protects defaults to 1, which causes
the proxy- prefix to be prepended to all client host
addresses that connect via an intermediary (proxy, broker, broker, or
edge server), indicating that the connection is not direct.
Setting dm.proxy.protects to 0 removes the
proxy- prefix and allows you to write a single set of
protection entries that apply both to directly-connected clients as well
as to those that connect via an intermediary. This is more convenient but
less secure if it matters that a connection is made using an
intermediary. If you use this setting, all intermediaries must be at
release 2012.1 or higher.
