Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Special characters in container configs doesn't work as expected #207

Open
realies opened this issue Nov 17, 2017 · 3 comments
Open

Special characters in container configs doesn't work as expected #207

realies opened this issue Nov 17, 2017 · 3 comments

Comments

@realies
Copy link
Contributor

realies commented Nov 17, 2017

After installing a mariadb instance with special characters (ampersand) in the root password field I've noticed the Warning: SimpleXMLElement::addChild(): unterminated entity reference ... in /usr/local/emhttp/plugins/dynamix.docker.manager/include/CreateDocker.php on line 219.

On my installation (6.4.0-rc9f) this is the line $config = $xml->addChild('Config', $post['confValue'][$i]);

Looking in the XML template created, the ampersand has been converted to & which is something you do not want for a password field. Escaping instead of converting to safe html characters should be the way to go in terms of preserving the data. It is then up to the rendering component of the webGui to do its job to the display data safely.

Since escaping < and > is not possible between opening and closing XML tags, please consider switching to JSON, where escaping of quotes is possible with \ or SQLite where no escaping should be required.

PS: The escaped password value that was generated within the XML does not show up when updating the container, instead the default value populates the input.

@Squidly271
Copy link
Contributor

Switching the templates over to JSON would be a serious nightmare as there's roughly 400 templates available that would all need to be redone. (And XML is more human readable for those app maintainers who manually adjust the templates)
Another option would be for you to modify the resulting template and change the entry to be enclosed in a CDATA where there are no limitations on what's there.

@realies
Copy link
Contributor Author

realies commented Nov 26, 2017

Shouldn't then all entries that could be interpreted as XML enclose their content in CDATA?

@eschultz
Copy link
Contributor

This shouldn't be an issue with 6.4.0 since we're properly encoding values written to XML with:
htmlspecialchars($string, ENT_XML1, 'UTF-8')

and then decoding values from XML with:
strval(html_entity_decode($string, ENT_XML1, 'UTF-8'))

no need for even the CDATA markers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants