Public/b2b pages

Introduction

Regular pages will be restricted with the erply back-office sessions, this means that the pages cannot be viewed without a valid erply user session.

We can use the b2b/public sessions to set pages to no use the back-office session. For that we have 2 options:

  1. Public session - these sessions are completely public and do not require a user to log in at all.
  2. Protected session (app user) - pages that can only be viewed by logged in app user. App users are special users that are managed in the application itself.

Permission

Public pages are protected by 3 different methods.

  1. Erply user group permissions - on installation a user group is created goerp-app-users-group, all data fetches to erply api’s will use the rights of this group.
  2. Dynamic api request whitelist - a list of calls that are allowed with the dynamic api feature.
  3. Parameter whitelist - a list of parameters that we allow to be used.

Dynamic api request whitelist

The whitelist is under the ‘Publish settings’ tab in the editor view.

Publish settings Publish settings

When enabled the dynamic requests would need to be added to the page

Request whitelist Request whitelist

Parameters whitelist

The following error is given when on public pages we send a parameter that is not added to the whitelist.

Parameter whitelist error Parameter whitelist error

The whitelist can be accessed under the ‘Publish settings’ in the editor view. The parameter whitelist counts in presets and request the whitelist (when used) so the values there do not need to be duplicated here.

Publish settings Publish settings

When enabled the used parameters need to be filled to the list of the page.

Parameter whitelist Parameter whitelist

If the permissions were previously set to the aliases then we can also use the ‘Import from alias’ button to automatically fill them based on the alias settings.

As of 1.234.5+ disabling of these features is not recommended and will be disabled for new templates.

Pattern matching rules for parameter whitelist

The whitelist supports pattern matching for the parameters. That would be very helpful when working with the json that contains or generates arrays. At the moment pattern matching is supported for digits <%d%> and string <%s%>.

To define a placeholder just put a <%d%> in the place where actual parameter name may have a number. Can be defined as many placeholders per parameter as needed.

For example, this rule:

KvsApi.Api.Json.saveData.string.entries.<%d%>.value.products.<%d%>.code

will much any of the following parameters:

KvsApi.Api.Json.saveData.string.entries.1.value.products.1.code
KvsApi.Api.Json.saveData.string.entries.2.value.products.1.code
KvsApi.Api.Json.saveData.string.entries.1.value.products.2.code
KvsApi.Api.Json.saveData.string.entries.2.value.products.2.code