The Setup Table controls aspects that can be changed while the server is running, and is intended to contain both Moxie.Build specific values as well as application specific.

The built in Setup Table values that Moxie.Build needs to run all start with "Cnw." while application specific values should use their own app-specific prefix.

If a built in value is missing on startup, Moxie.Build will configure a backwards compatible value, which may be different than the default value configured in a new download of Moxie.Build.

The following is the current list of the built in Setup Table values available in the most recent version.

[This list is Under Construction and only contains the most recently added values at this time]

 

Cnw.AntiCsrfOverride

The field named anticsrf is automatically added to HtmlForm and other form related Html commands. If the Config value of AntiCsrf is set to Enforced, these values are automatically checked on submit by the webserver. If not matched, the request results in a 403 Forbidden, the user is logged out, and an Anti-CSRF entry is added to the log file.

When set to Enforced int he Config file, and a mismatch is found, the URL without parameters will be checked against this Setup table value. Setting this override to * will disable this check for all URLs and is the equivalent of turning off Enforced in the Config file. Setting this to one line per URL path will bypass the enforcement on those paths. Use of this is override is not recommended; it exists only as a temporary quick fix for compatibility issues.

In order to include the correct anticsrf token value in a custom built form (not using HtmlForm) use the AntiCsrf$ function to fetch the correct value. This same function should be used to test these values on submit when AntiCsrf is either not Enforced in the Config file, or a URL is in this Override list.

 

Cnw.URLParseFrom

Moxie.Build V5 come with this value set to Left and will be the standard going forwards. Older version of Moxie will have this value created on first run after upgrade and will be set to Right for backwards compatibility.

With Left processing, Posts must be attached to the Category referenced in the URL, and the Category must be the first item, and if a Post is to be loaded, it must be the second item. After a valid Category or Category/Post is found, any remaining path items are ignored and may be used programmatically as virtual sub-paths. The position of the Category and optional Post may be offset from the left by specifying a single number in the range of 1 to 8 after the word Left, such as a value of “Left 1” to allow a language specifier such as /en-ca/Category/Post to be used. The /en-ca/ example is just an example of the offset; it is not used by Moxie.Build to automatically control the language.

With Right processing, the last path item will first test for a Category, and if found the Category is used. If not found, the last item will be tests against a Post and if found the Post is used. If a Post is used, and if the previous item is a valid Category, that Category will be used as the parent for the Post. Any other items to the left of these are ignored and may be used programmatically as virtual prefix paths.