Grules supports groups that can represent different types of parameters. Each type is defined in a separate section marked by the appropriate label. For example, for web applications grules predefines six groups: GET, POST, COOKIES, HEADER, URL_PATH, and a PARAMETERS group, which combines both GET and POST parameters (the last group should be used only when a list of allowed request methods is explicitly set, see a Grails controller class for an example).

Here is a rules script for a login form that uses groups:

GET:
id toNaturalInt

POST:
username isAlnum
password isPasswordFor(username)

COOKIES:
sessionid isSessionIdFor(username)

HEADER:
referer isUrl

Most likely, you will need the HEADER section only on occasion, but if you do use any header parameters, make sure they are validated properly as these values can be easily modified by a malicious user. For example, an attacker can modify the referer HTTP header field which contains the URL of the web page from which the request originated, or set the Content-length header to some unduly big value.

You can have more than one section of each type to satisfy cyclic dependencies between groups, for example:

POST:
user isAlnum

GET: 
page !empty(POST.user) && (eq(PageNames.HOME) || eq(PageNames.ADMIN))

POST:
if (GET.page == PageNames.ADMIN) password isPasswordFor(username)

By default, the rule engine looks for the referenced parameter only in the current section. To access other parameters use the section name prefix followed by a dot, for example:

COOKIES:
lastUsername eq(GET.username) // GET.$username for a raw value

A developer can also define custom sections:

TOUR_INFO:
country isCountry >> toISOCountry
city isAlnum
...

PERSONAL_DATA:
name isAlnum
surname isAlnum
...