用python写访问http://api.sqhyw.net:90/api/logins,并把返回值token筛选出来
时间: 2023-08-05 18:06:40 浏览: 102
你可以使用 Python 中的 `requests` 库来发送 HTTP 请求并获取返回值。下面是一个使用 `requests` 库访问 `http://api.sqhyw.net:90/api/logins` 并筛选出返回值中的 `token` 的示例代码:
```python
import requests
url = 'http://api.sqhyw.net:90/api/logins'
response = requests.get(url)
data = response.json()
token = data['token']
print(token)
```
在这个示例中,我们使用 `requests.get()` 方法发送 GET 请求到指定的 URL。然后,我们使用 `.json()` 方法将返回的响应解析为 JSON 格式的数据。接下来,我们从解析后的数据中提取出 `token` 值,并打印出来。
请确保你已经安装了 `requests` 库,可以使用 `pip install requests` 命令进行安装。
希望这个示例能满足你的需求。如果你还有其他问题,请随时提问!
相关问题
centos配置审计规则 /etc/audit/rules.d/audit.rules 示例
以下是一个示例配置审计规则的 /etc/audit/rules.d/audit.rules 文件,你可以在此基础上进行修改:
# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.
# First rule - delete all
-D
# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 8192
# Set failure mode to syslog
-f 1
# Audit mount and umount syscall events
-a exit,always -F arch=b64 -S mount -F auid>=1000 -F auid!=unset -k mount
-a exit,always -F arch=b32 -S mount -F auid>=1000 -F auid!=unset -k mount
-a exit,always -F arch=b64 -S umount2 -F auid>=1000 -F auid!=unset -k umount
# Audit LXC events
-w /var/lib/lxc/ -p rwa -k lxc
# Audit cron jobs
-w /etc/cron.hourly/ -p rwa -k cron.hourly
-w /etc/cron.daily/ -p rwa -k cron.daily
-w /etc/cron.weekly/ -p rwa -k cron.weekly
-w /etc/cron.monthly/ -p rwa -k cron.monthly
# Audit user and group modifications
-w /etc/group -p wa -k usergroup
-w /etc/passwd -p wa -k usergroup
-w /etc/gshadow -p wa -k usergroup
-w /etc/shadow -p wa -k usergroup
# Audit package and yum operations
-w /etc/yum/ -p rwa -k yum
-w /usr/bin/rpm -a exit,always -F arch=b64 -S open -F perm=x -F auid>=1000 -F auid!=unset -k rpm
# Audit system calls
-a exit,always -F arch=b32 -S uname -k systemcalls
-a exit,always -F arch=b64 -S uname -k systemcalls
-a exit,always -F arch=b32 -S sethostname -k systemcalls
-a exit,always -F arch=b64 -S sethostname -k systemcalls
-a exit,always -F arch=b32 -S setdomainname -k systemcalls
-a exit,always -F arch=b64 -S setdomainname -k systemcalls
# Audit system logins
-w /var/log/lastlog -p wa -k logins
-w /var/log/wtmp -p wa -k logins
# Audit selinux changes
-w /etc/selinux/ -p rwa -k selinux
# Audit firewall changes
-w /etc/firewalld/ -p rwa -k firewalld
# Audit sudo operations
-w /var/log/sudo.log -p wa -k sudo
# Audit SSH sessions
-w /var/log/secure -p wa -k ssh
# Audit network socket operations
-a exit,always -F arch=b32 -S socketcall -k netsockets
-a exit,always -F arch=b64 -S socketcall -k netsockets
-a exit,always -F arch=b32 -S sendto -k netsockets
-a exit,always -F arch=b64 -S sendto -k netsockets
-a exit,always -F arch=b32 -S recvfrom -k netsockets
-a exit,always -F arch=b64 -S recvfrom -k netsockets
Failed to load resource: the server responded with a 9527/api/users/login:1 status of 500 (Internal Server Error)
The "Failed to load resource" error with a status of 500 (Internal Server Error) typically indicates that there is an issue on the server side. The server encountered an unexpected condition that prevented it from fulfilling the request.
In this specific case, it seems that there is an issue with the login functionality of the API endpoint "9527/api/users/login". The server is returning a 500 error, indicating that there might be a problem with the server-side code responsible for handling user logins.
To resolve this issue, you can try the following steps:
1. Check the server logs: The server logs might provide more specific information about the error. Look for any error messages or stack traces that can help identify the cause of the issue.
2. Review the server-side code: Inspect the code responsible for handling user logins (in this case, the login functionality at "9527/api/users/login"). Look for any syntax errors, logical issues, or missing dependencies that could be causing the server error.
3. Test with different inputs: Try different login credentials or scenarios to see if the issue is specific to certain inputs. This can help pinpoint any data-related issues that might be causing the internal server error.
4. Contact the server administrator or API provider: If you don't have access to the server code or logs, reach out to the administrator or API provider for assistance. Provide them with the specific error message and any relevant details to help them troubleshoot the issue.
Remember, this is a general troubleshooting approach, and the specific steps may vary depending on the server setup and codebase.