Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Some macros support Parameter Restrictions, offering a means to apply more granular restrictions. The Macro Security Managed Macros page details which macros support Parameter Restrictions and the parameters that are available.

For instance, the SQL macro supports the following Parameter Restrictions in addition to the "sql =" Use Restriction.

  • sql.datasource
  • sql.limit
  • sql.disableAntiXss
  • sql.querytimeout
You would need to look at the to understand

explains what each of these parameters accomplishes, but the syntax within the properties file is similar to what is

shown above under Of the above Parameter Restrictions, per

described on the Using Use Restrictions  page.

There are some special caveats about Parameter Restrictions:

  1. A Parameter Restriction only applies when the user tries to change the parameter value to something different than the default.
  2. If a Parameter Restriction is defined for the limit parameter (available on the SQL, SQL File and SQL Query macros),  it is only put into effect if the user provides a parameter value that is greater than the Limit Rows Processed setting that an administrator sets in the SQL add-on's configuration.

Parameters that are "By Value"

Div
stylepadding-left: 40px;

Some of the Parameter Restrictions documented on the Macro Security Managed Macros page are noted as being "(by value)". This allows even more specificity about how the Parameter Restriction is to be applied.

For the SQL macro, only the

"sql.

datasource

"

parameter is

noted as

"

(

by value

)

."

.

This means that you can add ".*" to the end of the parameter to have it apply to all names (of datasources, in this example) or you can add entries for one or more specific datasource names.

Parameter RestrictionWhat It Means...
sql.datasource.* = confluence-administrators

Only members of the confluence-administrators group can use the SQL macro with its datasource parameter set to datasources of any name.

sql.datasource.exampledb = confluence-administrators
sql.datasource.hr = hr-managers
Only members of the confluence-administrators group can use the SQL macro with its datasource parameter set to "exampledb" and only members of the hr-managers group can use the SQL macro with its datasource parameter set to "hr."
panel

 

bgColor#efefef

On this page:

Table of Contents
maxLevel3

 

How Parameter Restrictions Work with Use Restrictions


Divstyle


padding-left: 40px;

The Parameter Restrictions are applied "on top" of the Use Restriction for that macro. In other words, unless space-based Macro Security is being used, an "edit" page restriction must match (only) whatever userids and/or group names are referenced in both the Use Restriction condition and the Parameter Restriction.

The following table provides some examples of correct and incorrect combinations

:

. In these examples, assume that userid "bswift" is not a member of any of the named groups.

Table plus
columnTypesI,S,S,E
columnAttributes,width: 200px,,
 
Properties File
"edit" Page Restriction(s)
on page using the SQL macro
Result
((tick)=Valid, (error)=Invalid)
1
sql = *ANY
sql.limit = confluence-administrators
  1. confluence-administrators
(tick)
2

sql = *ANY
sql.limit = confluence-administrators

  1. bswift
  2. confluence-administrators
(error)
because userid "bswift" isn't listed in the SQL entries in the properties file nor is that user a member of the confluence-administrators group
3

sql = *ANY
sql.datasource.exampledb = confluence-administrators

sql.datasource.hr = hr-managers

  1. confluence-administrators
  2. hr-managers

The 1st edit restriction must be present if the "exampledb" datasource is used. The 2nd edit restriction must be present if the "hr" datasource is used. You could have both of these edit restrictions in place as well.

Note too that the Use Restriction (sql = *ANY in this example) must be one of the following in order to support the 2 sql.datasource Parameter Restrictions listed:

  • sql = *ANY
  • sql = confluece-administrators, hr-managers
 (tick)
4sql-query = *ANY
sql-query.datasource.* = confluence-administrators
sql-query.datasource.hr = hr-managers
sql-query.datasource.finance = finance-managers
  1. confluence-administrators
  2. hr-managers
  3. finance-managers

The 1st edit restriction must be present if a datasource other than "hr" and "finance" is used. The 2nd edit restriction must be present if the "hr" datasource is used. The 3rd edit restriction must be present if the finance" datasource is used. You could have all of these edit restrictions in place as well.

This example shows how to give access to all datasources to confluence-administrators and also give specific datasource access to different groups.

(tick)
5
sql = confluence-administrators, trusted-users-sql
sql.limit = confluence-administrators
 
  1. confluence-administrators
  2. trusted-users-sql
(tick)
 6

sql = confluence-administrators, space:DEMO 

If page is in the DEMO space:

  1. "edit" page restrictions are not necessary.
  2. Space-level permissions should ensure only trusted users and groups can edit pages, blog posts and comments in that space, however this is not validated by Macro Security.
(tick)
 7

sql = confluence-administrators, space:DEMO 

If page is in the DEMO space:

  1. bswift
(tick)
 8

sql = confluence-administrators, space:DEMO 

If page is not in the DEMO space:

  1. confluence-administrators
(tick)
 9

sql = confluence-administrators, space:DEMO 

If page is not in the DEMO space:

  1. no "edit" page restrictions
    OR
  2. bswift
(error)
because confluence-administrators is not referenced in "edit" page restrictions