Discussion about allowing HTML

[Foxandxss]

I want to discuss here of what should we do about trusting html.

I saw various ways, and I am not sure of any of them:

As today, you can add html onto it, $sce will trust your html but I am unsure how it works vs XSS. Using ngSanitize is also an option, but it doesn't allow to use form items on the toast.

The problem with $sce is that you can't put directives into the trusted HTML (that is intended). That doesn't mean I can create a directive where you can put any kind of html on your toast (even forms that will work with your scope), but that is highly insecure.

I want to discuss what are your thoughts about this.

[sroe]

So {{something}} is not working inside message because of $sce correct?

[Foxandxss]

Allowing HTML is problematic, there is no perfect solution.

There are various options and I decided for one. Allowing basic html on it, but that doesn't support angular directives and to do that, I need to make the toasts really insecure.

I think that since it is just to popup information, it doesn't need complex stuff on it.

So for now, I want to wait to see how people use it and then act.

[sroe]

I understand you decision. Our use-case is to display a countdown in a popup message or something to show the user that he is getting logged out by inactivity. So we decided to use a non blocking toast message for that. But without angular binding there is only the option to show multiple toasts every x seconds/minutes etc. to give the desired behavior.
Having a insecure toast is no problem in our case, so we may deactivate sce for our site, but we must discuss it again as the site could get online on some day (its an intranet website). Then we would maybe use a modal or just a countdown in one part of the layout.

[sukrosono]

i got $sce warning with

1. AngularJS v1.5.7
2. toastr 2.1.1 (not validate)

my intention enabling html just using

it work on http success callback with toastr.success

and it's throw $sce error on fail callback when interact with responseError.status, even with no html
and it work fine when not interact with responseError.status