[GitHub] qpid-dispatch pull request #343: DISPATCH-1067 - updates to policy doc (upda...

2018-08-06 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/qpid-dispatch/pull/343


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[GitHub] qpid-dispatch pull request #343: DISPATCH-1067 - updates to policy doc (upda...

2018-07-17 Thread bhardesty
Github user bhardesty commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/343#discussion_r203176550
  
--- Diff: docs/books/user-guide/understand-router-configuration.adoc ---
@@ -51,6 +51,133 @@ sectionName {
 }
 
 
+[id='methods-for-using-pattern-matching']
+== Methods for Using Pattern Matching and Wildcards
+
+The router configuration file supports pattern matching and wildcards to 
enable you to match multiple values for certain attributes. However, the syntax 
varies based on the type of entity that you are configuring. 
+
+[id='router-address-pattern-matching']
+=== Pattern Matching for Addresses
+
+In some router configuration scenarios, you may need to use pattern 
matching to match a range of addresses rather than a single, literal address. 
Address patterns match any address that corresponds to the pattern.
+
+An address pattern is a sequence of tokens (typically words) that are 
delimited by either `.` or `/` characters. They also may contain special 
wildcard characters that represent words:
--- End diff --

Changed to "can"


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[GitHub] qpid-dispatch pull request #343: DISPATCH-1067 - updates to policy doc (upda...

2018-07-17 Thread bhardesty
Github user bhardesty commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/343#discussion_r203175947
  
--- Diff: docs/books/user-guide/configuration-security.adoc ---
@@ -442,290 +442,367 @@ For more information about these attributes, see 
xref:adding-sasl-authentication
 
 == Authorizing Access to Messaging Resources
 
-You can restrict the number of user connections, and control access to 
AMQP messaging resources by configuring _policies_.
+You can configure _policies_ to secure messaging resources in your 
messaging environment. Policies ensure that only authorized users can access 
messaging endpoints through the router network, and that the resources on those 
endpoints are used in an authorized way.
 
-=== Types of Policies
-
-You can configure two different types of policies: _global policies_ and 
_vhost policies_.
+{RouterName} provides the following types of policies:
 
 Global policies::
-Settings for the router. A global policy defines the maximum number of 
incoming user connections for the router (across all vhost policies), and 
defines how the router should use vhost policies.
+Settings for the router. A global policy defines the maximum number of 
incoming user connections for the router (across all messaging endpoints), and 
defines how the router should use vhost policies.
 
 Vhost policies::
-Connection and AMQP resource limits for a messaging endpoint (called an 
AMQP virtual host, or _vhost_). A vhost policy defines what a client can access 
on a messaging endpoint over a particular connection.
-+
-[NOTE]
-
-A vhost is typically the name of the host to which the client connection 
is directed. For example, if a client application opens a connection to the 
`amqp://mybroker.example.com:5672/queue01` URL, the vhost would be 
`mybroker.example.com`.
-
+Connection and AMQP resource limits for a messaging endpoint (called an 
AMQP virtual host, or vhost). A vhost policy defines what a client can access 
on a messaging endpoint over a particular connection.
 
 The resource limits defined in global and vhost policies are applied to 
user connections only. The limits do not affect inter-router connections or 
router connections that are outbound to waypoints.
 
-=== How {RouterName} Applies Policies
+=== How {RouterName} Enforces Connection and Resource Limits
 
-{RouterName} uses both global and vhost policies to determine whether to 
permit a connection, and if it is permitted, to apply the appropriate resource 
limits.
+{RouterName} uses policies to determine whether to permit a connection, 
and if it is permitted, to apply the appropriate resource limits.
 
 When a client creates a connection to the router, the router first 
determines whether to allow or deny the connection. This decision is based on 
the following criteria:
 
-* Whether the connection will exceed the router's global connection limit 
(defined in the global policy)
-* Whether the connection will exceed the vhost's connection limits 
(defined in the vhost policy that matches the host to which the connection is 
directed)
+* Whether the connection will exceed the router’s global connection 
limit (defined in the global policy)
 
-If the connection is allowed, the router assigns the user (the 
authenticated user name from the connection) to a user group, and enforces the 
user group's resource limits for the lifetime of the connection.
+* Whether the connection will exceed the vhost’s connection limits 
(defined in the vhost policy that matches the host to which the connection is 
directed)
 
-=== Configuring Global Policies
+If the connection is allowed, the router assigns the user (the 
authenticated user name from the connection) to a user group, and enforces the 
user group’s resource limits for the lifetime of the connection.
 
-You can set the incoming connection limit for the router and define how it 
should use vhost policies by configuring a global policy.
+=== Setting Global Connection Limits
+
+You can set the incoming connection limit for the router. This limit 
defines the total number of concurrent client connections that can be open for 
this router.
 
 .Procedure
 
-* In the router configuration file, add a `policy` section.
+* In the router configuration file, add a `policy` section and set the 
`maxConnections`.
 +
 --
 [options="nowrap",subs="+quotes"]
 
-policy = {
-maxConnections: 1  // <1>
-enableVhostPolicy: true  // <2>
-policyDir: /etc/qpid-dispatch/policies/  // <3>
-defaultVhost: $default  // <4>
+policy {
+maxConnections: 1
 }
 
-<1> The maximum number of concurrent client connections allowed for this 
router. This limit is always 

[GitHub] qpid-dispatch pull request #343: DISPATCH-1067 - updates to policy doc (upda...

2018-07-17 Thread bhardesty
Github user bhardesty commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/343#discussion_r203176226
  
--- Diff: docs/books/user-guide/understand-router-configuration.adoc ---
@@ -51,6 +51,133 @@ sectionName {
 }
 
 
+[id='methods-for-using-pattern-matching']
+== Methods for Using Pattern Matching and Wildcards
+
+The router configuration file supports pattern matching and wildcards to 
enable you to match multiple values for certain attributes. However, the syntax 
varies based on the type of entity that you are configuring. 
+
+[id='router-address-pattern-matching']
+=== Pattern Matching for Addresses
+
+In some router configuration scenarios, you may need to use pattern 
matching to match a range of addresses rather than a single, literal address. 
Address patterns match any address that corresponds to the pattern.
--- End diff --

Done.


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[GitHub] qpid-dispatch pull request #343: DISPATCH-1067 - updates to policy doc (upda...

2018-07-17 Thread jenmalloy
Github user jenmalloy commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/343#discussion_r203152559
  
--- Diff: docs/books/user-guide/configuration-security.adoc ---
@@ -442,290 +442,367 @@ For more information about these attributes, see 
xref:adding-sasl-authentication
 
 == Authorizing Access to Messaging Resources
 
-You can restrict the number of user connections, and control access to 
AMQP messaging resources by configuring _policies_.
+You can configure _policies_ to secure messaging resources in your 
messaging environment. Policies ensure that only authorized users can access 
messaging endpoints through the router network, and that the resources on those 
endpoints are used in an authorized way.
 
-=== Types of Policies
-
-You can configure two different types of policies: _global policies_ and 
_vhost policies_.
+{RouterName} provides the following types of policies:
 
 Global policies::
-Settings for the router. A global policy defines the maximum number of 
incoming user connections for the router (across all vhost policies), and 
defines how the router should use vhost policies.
+Settings for the router. A global policy defines the maximum number of 
incoming user connections for the router (across all messaging endpoints), and 
defines how the router should use vhost policies.
 
 Vhost policies::
-Connection and AMQP resource limits for a messaging endpoint (called an 
AMQP virtual host, or _vhost_). A vhost policy defines what a client can access 
on a messaging endpoint over a particular connection.
-+
-[NOTE]
-
-A vhost is typically the name of the host to which the client connection 
is directed. For example, if a client application opens a connection to the 
`amqp://mybroker.example.com:5672/queue01` URL, the vhost would be 
`mybroker.example.com`.
-
+Connection and AMQP resource limits for a messaging endpoint (called an 
AMQP virtual host, or vhost). A vhost policy defines what a client can access 
on a messaging endpoint over a particular connection.
 
 The resource limits defined in global and vhost policies are applied to 
user connections only. The limits do not affect inter-router connections or 
router connections that are outbound to waypoints.
 
-=== How {RouterName} Applies Policies
+=== How {RouterName} Enforces Connection and Resource Limits
 
-{RouterName} uses both global and vhost policies to determine whether to 
permit a connection, and if it is permitted, to apply the appropriate resource 
limits.
+{RouterName} uses policies to determine whether to permit a connection, 
and if it is permitted, to apply the appropriate resource limits.
 
 When a client creates a connection to the router, the router first 
determines whether to allow or deny the connection. This decision is based on 
the following criteria:
 
-* Whether the connection will exceed the router's global connection limit 
(defined in the global policy)
-* Whether the connection will exceed the vhost's connection limits 
(defined in the vhost policy that matches the host to which the connection is 
directed)
+* Whether the connection will exceed the router’s global connection 
limit (defined in the global policy)
 
-If the connection is allowed, the router assigns the user (the 
authenticated user name from the connection) to a user group, and enforces the 
user group's resource limits for the lifetime of the connection.
+* Whether the connection will exceed the vhost’s connection limits 
(defined in the vhost policy that matches the host to which the connection is 
directed)
 
-=== Configuring Global Policies
+If the connection is allowed, the router assigns the user (the 
authenticated user name from the connection) to a user group, and enforces the 
user group’s resource limits for the lifetime of the connection.
 
-You can set the incoming connection limit for the router and define how it 
should use vhost policies by configuring a global policy.
+=== Setting Global Connection Limits
+
+You can set the incoming connection limit for the router. This limit 
defines the total number of concurrent client connections that can be open for 
this router.
 
 .Procedure
 
-* In the router configuration file, add a `policy` section.
+* In the router configuration file, add a `policy` section and set the 
`maxConnections`.
 +
 --
 [options="nowrap",subs="+quotes"]
 
-policy = {
-maxConnections: 1  // <1>
-enableVhostPolicy: true  // <2>
-policyDir: /etc/qpid-dispatch/policies/  // <3>
-defaultVhost: $default  // <4>
+policy {
+maxConnections: 1
 }
 
-<1> The maximum number of concurrent client connections allowed for this 
router. This limit is always 

[GitHub] qpid-dispatch pull request #343: DISPATCH-1067 - updates to policy doc (upda...

2018-07-17 Thread jenmalloy
Github user jenmalloy commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/343#discussion_r20316
  
--- Diff: docs/books/user-guide/understand-router-configuration.adoc ---
@@ -51,6 +51,133 @@ sectionName {
 }
 
 
+[id='methods-for-using-pattern-matching']
+== Methods for Using Pattern Matching and Wildcards
+
+The router configuration file supports pattern matching and wildcards to 
enable you to match multiple values for certain attributes. However, the syntax 
varies based on the type of entity that you are configuring. 
+
+[id='router-address-pattern-matching']
+=== Pattern Matching for Addresses
+
+In some router configuration scenarios, you may need to use pattern 
matching to match a range of addresses rather than a single, literal address. 
Address patterns match any address that corresponds to the pattern.
--- End diff --

Change "may" to "might"


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[GitHub] qpid-dispatch pull request #343: DISPATCH-1067 - updates to policy doc (upda...

2018-07-17 Thread jenmalloy
Github user jenmalloy commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/343#discussion_r203164612
  
--- Diff: docs/books/user-guide/understand-router-configuration.adoc ---
@@ -51,6 +51,133 @@ sectionName {
 }
 
 
+[id='methods-for-using-pattern-matching']
+== Methods for Using Pattern Matching and Wildcards
+
+The router configuration file supports pattern matching and wildcards to 
enable you to match multiple values for certain attributes. However, the syntax 
varies based on the type of entity that you are configuring. 
+
+[id='router-address-pattern-matching']
+=== Pattern Matching for Addresses
+
+In some router configuration scenarios, you may need to use pattern 
matching to match a range of addresses rather than a single, literal address. 
Address patterns match any address that corresponds to the pattern.
+
+An address pattern is a sequence of tokens (typically words) that are 
delimited by either `.` or `/` characters. They also may contain special 
wildcard characters that represent words:
--- End diff --

Change "may" to "might"


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[GitHub] qpid-dispatch pull request #343: DISPATCH-1067 - updates to policy doc (upda...

2018-07-16 Thread fgiorgetti
Github user fgiorgetti commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/343#discussion_r202810977
  
--- Diff: docs/books/user-guide/configuration-security.adoc ---
@@ -442,290 +442,367 @@ For more information about these attributes, see 
xref:adding-sasl-authentication
 
 == Authorizing Access to Messaging Resources
 
-You can restrict the number of user connections, and control access to 
AMQP messaging resources by configuring _policies_.
+You can configure _policies_ to secure messaging resources in your 
messaging environment. Policies ensure that only authorized users can access 
messaging endpoints through the router network, and that the resources on those 
endpoints are used in an authorized way.
 
-=== Types of Policies
-
-You can configure two different types of policies: _global policies_ and 
_vhost policies_.
+{RouterName} provides the following types of policies:
 
 Global policies::
-Settings for the router. A global policy defines the maximum number of 
incoming user connections for the router (across all vhost policies), and 
defines how the router should use vhost policies.
+Settings for the router. A global policy defines the maximum number of 
incoming user connections for the router (across all messaging endpoints), and 
defines how the router should use vhost policies.
 
 Vhost policies::
-Connection and AMQP resource limits for a messaging endpoint (called an 
AMQP virtual host, or _vhost_). A vhost policy defines what a client can access 
on a messaging endpoint over a particular connection.
-+
-[NOTE]
-
-A vhost is typically the name of the host to which the client connection 
is directed. For example, if a client application opens a connection to the 
`amqp://mybroker.example.com:5672/queue01` URL, the vhost would be 
`mybroker.example.com`.
-
+Connection and AMQP resource limits for a messaging endpoint (called an 
AMQP virtual host, or vhost). A vhost policy defines what a client can access 
on a messaging endpoint over a particular connection.
 
 The resource limits defined in global and vhost policies are applied to 
user connections only. The limits do not affect inter-router connections or 
router connections that are outbound to waypoints.
 
-=== How {RouterName} Applies Policies
+=== How {RouterName} Enforces Connection and Resource Limits
 
-{RouterName} uses both global and vhost policies to determine whether to 
permit a connection, and if it is permitted, to apply the appropriate resource 
limits.
+{RouterName} uses policies to determine whether to permit a connection, 
and if it is permitted, to apply the appropriate resource limits.
 
 When a client creates a connection to the router, the router first 
determines whether to allow or deny the connection. This decision is based on 
the following criteria:
 
-* Whether the connection will exceed the router's global connection limit 
(defined in the global policy)
-* Whether the connection will exceed the vhost's connection limits 
(defined in the vhost policy that matches the host to which the connection is 
directed)
+* Whether the connection will exceed the router’s global connection 
limit (defined in the global policy)
 
-If the connection is allowed, the router assigns the user (the 
authenticated user name from the connection) to a user group, and enforces the 
user group's resource limits for the lifetime of the connection.
+* Whether the connection will exceed the vhost’s connection limits 
(defined in the vhost policy that matches the host to which the connection is 
directed)
 
-=== Configuring Global Policies
+If the connection is allowed, the router assigns the user (the 
authenticated user name from the connection) to a user group, and enforces the 
user group’s resource limits for the lifetime of the connection.
 
-You can set the incoming connection limit for the router and define how it 
should use vhost policies by configuring a global policy.
+=== Setting Global Connection Limits
+
+You can set the incoming connection limit for the router. This limit 
defines the total number of concurrent client connections that can be open for 
this router.
 
 .Procedure
 
-* In the router configuration file, add a `policy` section.
+* In the router configuration file, add a `policy` section and set the 
`maxConnections`.
 +
 --
 [options="nowrap",subs="+quotes"]
 
-policy = {
-maxConnections: 1  // <1>
-enableVhostPolicy: true  // <2>
-policyDir: /etc/qpid-dispatch/policies/  // <3>
-defaultVhost: $default  // <4>
+policy {
+maxConnections: 1
 }
 
-<1> The maximum number of concurrent client connections allowed for this 
router. This limit is always 

[GitHub] qpid-dispatch pull request #343: DISPATCH-1067 - updates to policy doc (upda...

2018-07-16 Thread fgiorgetti
Github user fgiorgetti commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/343#discussion_r202826844
  
--- Diff: docs/books/user-guide/configuration-security.adoc ---
@@ -734,57 +811,57 @@ vhost {
 
 <3> Any user can connect to this vhost. Users that are not part of the 
`admin` group are assigned to the `$default` group.
 
-<4> If the `admin-01` or `admin-02` user connects to the vhost, they are 
assigned to the `admin` user group.
+<4> If the `admin1` or `admin2` user connects to the vhost, they are 
assigned to the `admin` user group.
 
 <5> Users in the `admin` user group must connect from localhost. If the 
admin user attempts to connect from any other host, the connection will be 
denied.
 
-<6> Users in the admin user group can send and receive from any address 
offered by the vhost.
+<6> Users in the admin user group can send to any address offered by the 
vhost.
 
-<7> Any non-admin user is permitted to connect from any host.
+<7> Users in the admin user group can receive from any address offered by 
the vhost.
--- End diff --

s/receive from/send to


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[GitHub] qpid-dispatch pull request #343: DISPATCH-1067 - updates to policy doc (upda...

2018-07-16 Thread fgiorgetti
Github user fgiorgetti commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/343#discussion_r202826788
  
--- Diff: docs/books/user-guide/configuration-security.adoc ---
@@ -734,57 +811,57 @@ vhost {
 
 <3> Any user can connect to this vhost. Users that are not part of the 
`admin` group are assigned to the `$default` group.
 
-<4> If the `admin-01` or `admin-02` user connects to the vhost, they are 
assigned to the `admin` user group.
+<4> If the `admin1` or `admin2` user connects to the vhost, they are 
assigned to the `admin` user group.
 
 <5> Users in the `admin` user group must connect from localhost. If the 
admin user attempts to connect from any other host, the connection will be 
denied.
 
-<6> Users in the admin user group can send and receive from any address 
offered by the vhost.
+<6> Users in the admin user group can send to any address offered by the 
vhost.
--- End diff --

s/send to/receive from


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[GitHub] qpid-dispatch pull request #343: DISPATCH-1067 - updates to policy doc (upda...

2018-07-16 Thread bhardesty
GitHub user bhardesty opened a pull request:

https://github.com/apache/qpid-dispatch/pull/343

DISPATCH-1067 - updates to policy doc (updated)



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bhardesty/qpid-dispatch 
dispatch-1067-policy-doc-updates

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-dispatch/pull/343.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #343


commit 24e0df30ab71179a41d4f4d75379f5992df5a3cb
Author: Ben Hardesty 
Date:   2018-07-10T20:18:14Z

Update JSON map examples in the policy doc

commit aa0b7643ef3468aa61407527113c0a2c34c7f8d2
Author: Ben Hardesty 
Date:   2018-07-10T21:29:29Z

Add doc for configuring vhost policies in router config file

commit b28eace9332488d194c12490b06ddafbdc43db4d
Author: Ben Hardesty 
Date:   2018-07-12T18:05:57Z

Reorganize policy doc

commit 7afce1adc020251c5a3be8bbe20416fbe4a2a5ce
Author: Ben Hardesty 
Date:   2018-07-12T20:20:46Z

Add section on vhost hostname policy pattern matching for dispatch-990

commit 73873ed6d6f332124763b400bfb35a580b79180d
Author: Ben Hardesty 
Date:   2018-07-13T16:58:09Z

Update policy doc for dispatch-976

commit 20de09b8f17f30ca3510fea31d73571d3c5061a5
Author: Ben Hardesty 
Date:   2018-07-13T18:56:59Z

Update user-specific address patterns for dispatch-1011

commit c51513df20fe1fc6194b7f37fa27c8bf7a779464
Author: Ben Hardesty 
Date:   2018-07-16T18:15:42Z

Updates from sme review




---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org