DSP-551 Migrate sanitization pipes from BEOL

[mdelez]

closes https://dasch.myjetbrains.com/youtrack/issue/DSP-551

uses js-lib v1.0.0-rc.9 & dsp-api rc.12

[mdelez]

@flavens I've migrated the pipes but I have some questions:

1. Why are these considered "sanitizing" pipes when they do the opposite by using bypassSecurityTrustResourceUrl and bypassSecurityTrustResourceHtml?
2. Since the pipes are very similar, I would recommend combining them into one pipe and rename it to "Safe". Similar to this https://gist.github.com/SwarnaKishore/5479ed132509247f16702f1f0be5b941#file-safe-pipe-ts

[flavens]

@flavens I've migrated the pipes but I have some questions:

1. Why are these considered "sanitizing" pipes when they do the opposite by using bypassSecurityTrustResourceUrl and bypassSecurityTrustResourceHtml?
2. Since the pipes are very similar, I would recommend combining them into one pipe and rename it to "Safe". Similar to this https://gist.github.com/SwarnaKishore/5479ed132509247f16702f1f0be5b941#file-safe-pipe-ts

Good point. @SepidehAlassi created them. She should answer you because she knows how to use them.

[SepidehAlassi]

@flavens I've migrated the pipes but I have some questions:

1. Why are these considered "sanitizing" pipes when they do the opposite by using bypassSecurityTrustResourceUrl and bypassSecurityTrustResourceHtml?
2. Since the pipes are very similar, I would recommend combining them into one pipe and rename it to "Safe". Similar to this https://gist.github.com/SwarnaKishore/5479ed132509247f16702f1f0be5b941#file-safe-pipe-ts

Good point. @SepidehAlassi created them. She should answer you because she knows how to use them.

1. They are considered sanitizers because they implement DomSanitizer to sanitize HTMLs harvested from other servers like The Newton Project and Briefportal Leibniz to be safe to use in BEOL.
2. That would be fine with me.

[mdelez]

@flavens I've migrated the pipes but I have some questions:

1. Why are these considered "sanitizing" pipes when they do the opposite by using bypassSecurityTrustResourceUrl and bypassSecurityTrustResourceHtml?
2. Since the pipes are very similar, I would recommend combining them into one pipe and rename it to "Safe". Similar to this https://gist.github.com/SwarnaKishore/5479ed132509247f16702f1f0be5b941#file-safe-pipe-ts

Good point. @SepidehAlassi created them. She should answer you because she knows how to use them.

1. They are considered sanitizers because they implement DomSanitizer to sanitize HTMLs harvested from other servers like The Newton Project and Briefportal Leibniz to be safe to use in BEOL.
2. That would be fine with me.

Regarding the first point, to me, "sanitize" means to remove potentially harmful code from the provided string but in the case of these pipes, they're used to tell Angular "don't sanitize these strings, they're fine". Unless I'm missing something, these pipes are used to bypass Angular's built-in sanitization which is also stated in the documentation you linked:

"In specific situations, it might be necessary to disable sanitization, for example if the application genuinely needs to produce a javascript: style link with a dynamic value in it. Users can bypass security by constructing a value with one of the bypassSecurityTrust... methods, and then binding to that value from the template."

For the second point, I will combine the two

[SepidehAlassi]

@flavens I've migrated the pipes but I have some questions:

1. Why are these considered "sanitizing" pipes when they do the opposite by using bypassSecurityTrustResourceUrl and bypassSecurityTrustResourceHtml?
2. Since the pipes are very similar, I would recommend combining them into one pipe and rename it to "Safe". Similar to this https://gist.github.com/SwarnaKishore/5479ed132509247f16702f1f0be5b941#file-safe-pipe-ts

Good point. @SepidehAlassi created them. She should answer you because she knows how to use them.

1. They are considered sanitizers because they implement DomSanitizer to sanitize HTMLs harvested from other servers like The Newton Project and Briefportal Leibniz to be safe to use in BEOL.
2. That would be fine with me.

Regarding the first point, to me, "sanitize" means to remove potentially harmful code from the provided string but in the case of these pipes, they're used to tell Angular "don't sanitize these strings, they're fine". Unless I'm missing something, these pipes are used to bypass Angular's built-in sanitization which is also stated in the documentation you linked:

"In specific situations, it might be necessary to disable sanitization, for example if the application genuinely needs to produce a javascript: style link with a dynamic value in it. Users can bypass security by constructing a value with one of the bypassSecurityTrust... methods, and then binding to that value from the template."

For the second point, I will combine the two

Honestly, it does not make any difference for me what its name is. Please choose whatever you think is better. The important thing for me is that they are correctly used later in BEOL.

[mdelez]

@flavens I know this PR isn't really a priority but should we try to merge it during sprint 15 so we can close this? There's just a simple merge conflict to fix.

[flavens]

@flavens I know this PR isn't really a priority but should we try to merge it during sprint 15 so we can close this? There's just a simple merge conflict to fix.

yes it is ready, we have to merge it soon

[mpro7]

Wanted to help by resolving easy conflict in Action Module. However I've messed up a bit, managed to fix it and seems all back to green now. I also see that in the module exist imports of deprecated pipes: ReversePipe and SortByPipe. Should be those also removed or you keep them for some reason?

[flavens]

Wanted to help by resolving easy conflict in Action Module. However I've messed up a bit, managed to fix it and seems all back to green now. I also see that in the module exist imports of deprecated pipes: ReversePipe and SortByPipe. Should be those also removed or you keep them for some reason?

We have decided to keep deprecated methods/pipes/directives for some time in order to avoid breaking changes.