Interface and Operations / System Settings

DataFlux Func supports various customized configurations. Users can modify these configuration items in "System Settings".

If a configuration item is configured in the configuration file config.yaml, the UI will display "This setting has been specified in the configuration file", and it cannot be modified through the UI.

Custom Website Title / Favicon / Logo

Users can modify DataFlux Func's web page title, web page icon, and Logo.

When you use DataFlux Func to implement functional requirements and deliver them to customers, you can modify these configuration items to make DataFlux Func better match the customer's specifications.

Top Notice Bar

When you have deployed multiple DataFlux Func instances, you can use the top notice bar to indicate the purpose of the current DataFlux Func.

Navigation Bar Documentation Link

If you do not want to display the official documentation link in the navigation bar, or want to change the address it points to, you can modify this item.

Local Function Task Records

If you do not want DataFlux Func to record function task records locally, you can disable this option.

After disabling this configuration item, the system will clear all function task record data.

Self-Monitor Data Reporting

Function running logs and other information of DataFlux Func can be reported to the data platform.

Simply fill in the DataWay / OpenWay address in this item. The format is as follows:

DataWayDataKit

http://openway.ip-or-domain?token=tkn_xxxxx

http://datakit.ip-or-domain:9529

You can also fill in a site name, which will be added to the tags.site_name tag of the Self-Monitor Data.

Reduce data storage pressure

Generally speaking, after configuring Self-Monitor Data Reporting, you can consider disabling Local Function Task Records to reduce the load on local services.

For information about the reported data content, please refer to Deployment and Maintenance / Reporting Self-Monitor Data

Custom HTTP Response Headers

New in version 7.3.7

After configuration, all HTTP response headers of DataFlux Func will contain the specified content.

When fixed response headers are configured in the configuration file config.yaml, the UI will display these items in "Fixed Items".

The default values are as follows:

X-Content-Type-Options: nosniff

Cross-Origin Resource Sharing (CORS)

New in version 7.3.7

Cross-Origin Origin rule list

When fixed CORS rules are configured in the configuration file config.yaml, the UI will display these rules in "Fixed Items".

One rule per line. The web service will match rules in order after receiving a request, and process according to the first matching rule.

By default, once a rule matches, cross-origin access is allowed. Adding "!" at the beginning of a rule means that once a rule matches, cross-origin access is not allowed. If no rule matches, cross-origin access is denied by default, for example:

/api/v1/func-api/**
!*

The available rules and their syntax are as follows:

Rule	Example	Description
Any	"*"	A rule that always matches; it can be written as the last rule and used as the default rule
Origin Match	"http://other.site.domain"	Controls a specific source Origin.
URL Match	"http://other.site.domain/api/v1" "http://other.site.domain/api/*" "http://other.site.domain/api/v*" "http://other.site.domain/api/**"	Controls a specific source Origin, and only when the request is for a specific path Path supports * wildcards
Path Match	"/api/v1" "/api/*" "/api/v*" "/api/**"	Controls CORS only when the request is for a specific path Path supports * wildcards
Host Match	"other.site.domain"	Controls only when the Host part of the source Origin matches i.e., the HTTP protocol type is ignored
Host + Path Match	"other.site.domain/api/v1" "other.site.domain/api/*" "other.site.domain/api/v*" "other.site.domain/api/**"	Controls only when the Host part of the source Origin matches, and only when the request is for a specific path Path supports * wildcards

The default configuration is as follows:

/api/v1/func-api/**
/api/v1/cron/*
/api/v1/func-api-list
/api/v1/auth/integration/sign-in
/api/v1/fs/**
/api/v1/sync/**
/api/v1/async/**
/api/v1/al/**
/api/v1/bat/**

IP Address Filtering

New in version 7.3.7

IP Address Filtering Rules

Once enabled, the UI will display the local service IP, the current visitor IP, and the rule matching result for the current IP, including allowing access, allowing access to only some APIs, or denying access.

When fixed IP address filtering rules are configured in the configuration file config.yaml, the UI will display these rules in "Fixed Items".

One rule per line. The web service will match rules in order after receiving a request, and process according to the first matching rule.

By default, once a rule matches, access is allowed. Adding "!" at the beginning of a rule means that once a rule matches, access is not allowed. If no rule matches, access is denied by default, for example:

10.0.0.1
!0.0.0.0/0

The available rules and their syntax are as follows:

Rule	Example	Description
Single IP Address	"10.0.0.1"	Controls a specified single IP address
Address Range	"0.0.0.0/0"	Controls a specified IP address range

The default configuration is as follows:

0.0.0.0/0

Hidden Script Set

By default, built-in Script Sets are hidden to avoid accidental operations.

In the UI, you can separately configure whether to hide pre-installed Script Sets, built-in Script Sets, and blueprints. When you need to view them, turn off the corresponding hiding options.

Advanced Settings

Some configuration items related to the underlying logic of DataFlux Func and the interaction logic with the data platform are located in 'Advanced Configuration'. Under normal circumstances, do not modify these items.

DataFlux Func ID

'DataFlux Func ID' is a unique identifier used to distinguish different DataFlux Func deployments when DataFlux Func interacts with the data platform.

The DataFlux Func ID must start with DFF, and it cannot be just DFF.

If a user's DataFlux Func is deployed through full cloning (for example, via an Alibaba Cloud image), then the data platform will not be able to distinguish between old and new DataFlux Func instances.

In this case, modify the DataFlux Func ID to a different value.