Opened 6 years ago

Closed 6 years ago

#17746 closed defect (fixed)

Add support for escaping the HTML that is inserted in Select option labels

Reported by: Kris Zyp Owned by: Kris Zyp <kriszyp@…>
Priority: undecided Milestone: 1.10
Component: Dijit - Form Version: 1.9.2
Keywords: Cc:
Blocked By: Blocking:

Description

The Select widget should support the same labelType property as FilteringSelect? and ComboBox?, to escape HTML, in case of user-originated data, to avoid script injection.

Change History (6)

comment:1 Changed 6 years ago by Kris Zyp <kriszyp@…>

Owner: set to Kris Zyp <kriszyp@…>
Resolution: fixed
Status: newclosed

In fe83f7b78b85b115abe9496e47b50f1489dd3e4e/dijit:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:2 Changed 6 years ago by Kris Zyp <kriszyp@…>

In 726cf930426dfab3e252f65cbd5d7626f1e93a25/dijit:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:3 Changed 6 years ago by bill

Resolution: fixed
Status: closedreopened

Kris, all features and bug fixes in dijit need automated tests.

comment:4 Changed 6 years ago by freddefisk

Hi! Maybe this is not the correct place to ask this, but I have a question about the plan for this labelType attribute. Will it be a general design for all widgets (like TitlePane?, etc.), only for form widgets or will it be a special thing that only exists for Select, FilteringSelect? and ComboBox??

My concern is that mixing escaping and non-escaping widgets might just be confusing to the developer and will in the end make it harder to write secure code.

comment:5 Changed 6 years ago by bill

@freddefisk - I agree things are messed up (i.e. inconsistent) now, but it's impossible to fix w/out breaking backwards compatibility. Too bad.

Although we could add a labelType property to all widgets, I think I'd prefer (for V2) that the label is always interpreted as text. If there's a need to specify a label as HTML then perhaps having two separate properties is better, same way normal Elements have both a textContent and an innerHTML property.

comment:6 Changed 6 years ago by bill

Milestone: tbd1.10
Resolution: fixed
Status: reopenedclosed

Kris added a test in a881dada00fd05ce943940486d9d2b64d86ddcce, closing this, thanks.

Note: See TracTickets for help on using tickets.