Hide Forgot
Description of problem: name tag accepts special characters without complaining. As this might not be a problem yet, the names should be restricted to a-zA-Z0-9 and _. Version-Release number of selected component (if applicable): RHEV 3.6 How reproducible: always Steps to Reproduce: 1. Create a new macpool with e.g. newlines and Spaces in the name, (not using curl, but e.g. RestClient for Firefox): <mac_pool> <name>Testpool with somes special characters</name> <description>Some other special Characters</description> <allow_duplicates>false</allow_duplicates> <default_pool>false</default_pool> <ranges> <range> <from>00:1a:4b:01:00:00</from> <to>00:1a:4c:ff:ff:ff</to> </range> </ranges> </mac_pool> 2. Check the results: curl -s -k -u 'admin@internal:password' https://<url>/ovirt-engine/api/macpools/<?xml version="1.0" encoding="UTF-8" standalone="yes"?> Actual results: The special characters are accepted and also returned after querying Expected results: The special characters should either get stripped, or the request for creating the macpool should fail with an appropriate error message. Additional info:
I wonder if we should have some kind of filter to most fields, to filter where we should not accept extended chars.
We do have unicode support in most places. Why would we want to do that?
(In reply to Michal Skrivanek from comment #2) > We do have unicode support in most places. Why would we want to do that? I see absolutely no point in supporting Unicode in the MAC pool name, that's all.
It's working, we've it on many other places, we do support Unicode for other languages, even in ticket is no explanation why this shouldn't be allowed. Closed as NOTABZ? (otherwise - where else we should block it? Cluster/Quota/everywhere?)
Personally I think as the name is usually also printed in a single line in the WebUI, and names currently only support the abovbe mentioned characterset (at least from WebUI), there could arise some problems in at least accepting newline. In case we do not see any issues with UTF-8 encoding in <name> tags, I am fine with closing NOTABUG. Cheers, MArtin
My worries comes from creating exceptions for specific areas as those could affect the other behaviour. Thus I'd rather see unified approaches in the system.
(In reply to Michal Skrivanek from comment #7) > (In reply to Yaniv Kaul from comment #3) > > (In reply to Michal Skrivanek from comment #2) > > > We do have unicode support in most places. Why would we want to do that? > > > > I see absolutely no point in supporting Unicode in the MAC pool name, that's > > all. > > localization? We have complaints about Blank and None being non-translated > at random places, and we have people with chinese and cyrillic VM names...so > why not a mac pool, that's a virtual engine-only entity. For user supplied input, I think there are two categories of fields we need to look at: 1. Those that only admins will use and see (example: the MAC pool names). I see no reason to use anything but English there. I also have always a greater suspicion those may at some point be used by other lower layers (who know, maybe some day the MAC pool will be passed to a network provider for some reason - do they support Unicode?) 2. Those that are more user facing, commonly can be in non-ASCII chars - and we have to work hard to ensure end-to-end it's OK to have them in Unicode or so - such as VM names.
Coming back to the original bug, Pavel, (In reply to Martin Tessun from comment #5) > Personally I think as the name is usually also printed in a single line in > the WebUI, and names currently only support the abovbe mentioned > characterset (at least from WebUI), there could arise some problems in at > least accepting newline. > > In case we do not see any issues with UTF-8 encoding in <name> tags, I am > fine with closing NOTABUG. > > Cheers, > MArtin Pavel - can this be tested so that we know whether we can close that or not?
(In reply to Oved Ourfali from comment #9) > Coming back to the original bug, Pavel, (In reply to Martin Tessun from > comment #5) > > Personally I think as the name is usually also printed in a single line in > > the WebUI, and names currently only support the abovbe mentioned > > characterset (at least from WebUI), there could arise some problems in at > > least accepting newline. > > > > In case we do not see any issues with UTF-8 encoding in <name> tags, I am > > fine with closing NOTABUG. > > > > Cheers, > > MArtin > > Pavel - can this be tested so that we know whether we can close that or not? Regarding to new-lines and similar whitespaces, CSS in Webadmin does not override the "white-space" property, which means they are rendered according to this rule: "Sequences of whitespace will collapse into a single whitespace. Text will wrap when necessary. This is default" I.e., whitespaces are represented in browser as a space.
I'm trying to understand what action items are required on this bug. Pavel S. - can you elaborate?
Based on all comments + discussion offline with Pavel, closing as NOTABUG. If relevant, please reopen.