Practice Guide
Security Practice Guide
Note that there is no absolute security. If the environment allows, try to deploy Spug in the intranet and prohibit public network access. If you must access the public network, try to limit access to specified IP through firewall and other means.
Spug provides the function of automatically disabling the account after three consecutive incorrect passwords to avoid the possibility of being brute-force cracked. In the Token security policy, the security policy based on the access source IP is provided. When the access source IP of the same Token changes, the Token will automatically become invalid and force a re-login (after v3.0.2, you can turn off this feature through the system settings).
Token security policy relies on the HTTP header X-Real-IP and X-Forwarded-For forwarded by Nginx when forwarding requests (v2.3.12+), so please make sure that Spug can get the real IP of the user instead of the proxy IP of the upper level. If you use the recommended Docker deployment method, these jobs have been done by default. If you want to add a reverse proxy layer on the 80 port exposed by the Docker container, please configure X-Forwarded-For correctly, for example, add proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; to Nginx.
When it is impossible to verify the real IP of the visitor (the IP obtained by Spug is the internal network IP), a warning message will pop up when logging in. If Spug is deployed in the intranet and used only in the intranet (access Spug through the intranet address), you can turn off this feature in v2.3.14 and later by System Management / system Setup / Security Settings / Access IP Verification.
Different operations on different hosts during the release process
For example, an application needs to be deployed to three different hosts, but the deployment needs to execute some operations such as updating the database on the host, which can only be executed once and cannot be repeated. In this case, you can consider using the global variables SPUG_HOST_ID or SPUG_HOST_NAME provided by Spug to specify that these operations are only executed on a certain host, for example:
if [ "$SPUG_HOST_NAME" = "192.168.10.100" ]; then
echo "exec sql"
fi
Default PATH environment variable causes command not found problem
Default PATH variable may not be complete. If you encounter some command not found errors, you can use the following method to solve this problem:
# Add jdk to PATH variable
PATH=$PATH:/usr/local/jdk1.8.0_231/bin
java -jar xxx.jar
Persistent storage of project data
The Project will generate some data that needs to be persisted during the running process, such as the images uploaded by the user or the log files that need to be retained. When using the conventional release, each version is a new directory, and by default these files will not be visible in the new version. In this case, you can consider placing these dynamically generated and persistent data outside the release directory and linking them to the project through the soft link, so that the actual file is stored in a common place. Each time you update, you only need to do an extra soft link mapping to solve the problem.
Command error handling in execution
Since Spug v3, Spug removes the set -e feature, keeping the same behavior as the default execution script. If you are sensitive to command errors during execution, such as expecting any command to fail and interrupt the subsequent commands, you can add set -e to the beginning of the command you write.
Use su to switch identity
By default, using the su command directly will cause the command to hang and cannot continue to execute. You can use su as follows to make it work normally:
su - ubuntu << EOF
echo 'By ubuntu user execution'
EOF