> For the complete documentation index, see [llms.txt](https://coldbox-security.ortusbooks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://coldbox-security.ortusbooks.com/master-4/untitled-1/sample-xml-rules.md). # Sample XML Rules ```markup <-- < Declare as many rule elements as you want, order is important Remember that the securelist can contain a list of regular expressions if you want ex: All events in the user handler user\..* ex: All events .* ex: All events that start with admin ^admin If you are not using regular expressions, just write the text that can be found in an event. --> event user\.login,user\.logout,^main.* ^user\..*, ^admin admin read,write user.login event ^moderator admin,moderator read user.login url /secured.* admin,paid_subscriber user.pay ``` > **IMPORTANT** Please remember to white list your main events (implicit), login and logout events if you will be securing the entire application. ## First Rule Analysis As you can see from the sample, the first rule has the following elements ``` event ``` So it will match the incoming event. ``` user\.login,user\.logout,^main.* ``` This means that the following events will not be verified for security: user.login, user.logout and any event that starts with main will be let through, if they match the secure list pattern. ``` ^user\..*, ^admin ``` This means that any event that starts with the word user will be secured and anything that starts with the word admin will also be secured, unless the incoming event matches a pattern in the whitelist element. ``` admin ``` This means that only a user with admin role will be allowed to visit the securelist events. ``` read,write ``` This probably means that I am doing my own security validation and apart from having the user have a role of admin, he/she must also have the read and write permissions. My own validator will validate this logic. ``` user.login ``` Then if it does not validate it will use this redirect element to relocate via `setNextEvent()` ## Second Rule Analysis The second rule has the following elements: ``` event ``` So it will match the incoming event. ``` ``` No white listed events are defined. ``` ^moderator ``` This means that any event that starts with the word moderator will be secured and validated against the user's credentials. ``` admin,moderator ``` This means that users with roles of admin and moderator can execute events that are in the securelist. ``` read ``` This probably means that I am doing my own security validation and apart from having the user have a role of admin or moderator, he/she must also have the read permission. My own validator will validate this logic. ``` user.login ``` Then if it does not validate it will use this redirect element to relocate via `setNextEvent()` ## Third Rule Analysis The third rule has the following elements: ``` URL ``` So it will match the incoming URL pattern after the domain name and application location. ``` ``` No white listed events are defined. ``` /secured.* ``` It will secure any incoming URI that starts with /secured ``` admin,paid_subscriber ``` This means that users with roles of admin and paid\_subscriber can visit URLs with /secured in them ``` ``` No permissions ``` user.pay ``` Then if it does not validate it will use this redirect element to relocate via `setNextEvent()` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://coldbox-security.ortusbooks.com/master-4/untitled-1/sample-xml-rules.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.