FreshJR
Very Senior Member
I have been poking around if there would be anyway to generate a file on the router from input on a page appended into the WebUI.
The answer I have come up with is no. The router is very locked down for security reasons.
1) upload.cgi / jffsupload.cgi /upload_cert_key.cgi /all the other relevent file *.cgi ARE able create files on the router locally from the WebUI.
2) apply.cgi is able to set nvram variables
--
Is there any trick I missed?
Can local file generation from WebUI be something to consider to extend functionality in future releases? More friendly scripts can be created as a result.
Security side, the generated config can stripped of any special characters / sanitized. The only special charterers needed would be a new line and any delimiter such as a comma.
Eg. I would like to create functionality so a user can add/delete/modify QoS rules within the WebUI.
Rules can be generated within a table and upon hitting submit a file would be generated. This generated file would be parsed by the QoS script which would apply the WebUI generated rules.
Rules can be generated within a table and upon hitting submit a file would be generated. This generated file would be parsed by the QoS script which would apply the WebUI generated rules.
The answer I have come up with is no. The router is very locked down for security reasons.
1) upload.cgi / jffsupload.cgi /upload_cert_key.cgi /all the other relevent file *.cgi ARE able create files on the router locally from the WebUI.
The issue is that I cannot extend their functionality to create a custom file of my choosing. The file generation functionality is very sanitized and hardcoded within "release/src/router/httpd/web.c"
2) apply.cgi is able to set nvram variables
I would perfer to generate a config file instead of wasting nvram, but the same issue applies. Setting nvram variables is also very sanitized so I cannot set a custom variable from the WebUI.--
Is there any trick I missed?
Can local file generation from WebUI be something to consider to extend functionality in future releases? More friendly scripts can be created as a result.
Security side, the generated config can stripped of any special characters / sanitized. The only special charterers needed would be a new line and any delimiter such as a comma.
Last edited: