Ignore HTML tags?

[tomer953]

Hey,

a little background, I have a simple chat application,
right now I support only native emojis, because I save the user input in the db as: "text: string",
then I show in the chat:
<div> {{ message.text }} </div>

now, if I want to support all the different emojis set, I believe I need to save the message not as a simple string but as html,
or generate some unique pattern like "hello world {{emojiId:set:tone:size}}...." then use regex to replace.

I find it a bit confusing, then I saw your pipe - it seems to solve my problem, but it cause a new problem:
now my input is capable of sending html tags, so users can abuse it (ie, use styles and font-size 100px etc)

Do you have idea, how to:

1. use the picker to add emojis to the text area (I dont care to add them as native, but save+render them correctly
2. save the textarea as textonly (no styles and html allowed, so if you type html code, it will send it as a string)

[lentschi]

Hi @tomer953 !
utf8EmojisToImages internally uses bypassSecurityTrustHtml.

Do you have idea, how to:

1. use the picker to add emojis to the text area (I dont care to add them as native, but save+render them correctly

If you don't care to add them as native, just use event.emoji.native.

2. save the textarea as textonly (no styles and html allowed, so if you type html code, it will send it as a string)

If you just use a textarea and not some kind of richt text editor, your text contents will always be text only, so I'm not sure, what you're getting at there...? 🤔

But of course when displaying them, you will have to escape html before passing it on to utf8EmojisToImages to be sure the user hasn't maliciously typed in html manually. (The pipe intentionally doesn't include the escaping logic as some people will want to store and render html. Those will have to ensure HTML validity and security on the server side when the text is stored.)

[tomer953]

Thanks,

I will try to explain the flow again, the components are:

1. mart emoji picker (you can choose whatever set you want)
2. simple text box to insert your message
3. a server (with db) which your messages are saved
4. the main chat window where the messages appears

now I try to solve the following problem:
How to allow users to send whatever emojis they want, render them somehow while they type, and show to the rest of the users the correct output.

the actual challenge is what is the best solution to save the message in the db, so you can render it correctly to other users.

I'm trying to think about a good flow to do so, maybe:

1. user types 'Hello world' in the text box
2. user pick emoji from the picker, lets says Santa from google set.
3. now we do two things :

• insert the native santa into the text box (since we have the limitation to insert only text to textbox element)
• save the html of the rendered emoji with your pipe somehow
  so actually I will have two variable - "simpleText" to bind with the textbox ngmodel,
  and the actualHTML, which will be saved into the db

4. finally, I will render the message with the innerHTML property, with the saved html in the msg
   however, as I said I need to escape all the html tags since I don't want xss or html abusing, except of the emojis,
   I also need to support multiple emojis (maybe from multiple sets?)

OR, maybe just use rich-text-editor instead of the textbox, and directly store the innerHTML ?
It would be great If you have some advise for me,

[lentschi]

Hm... Well its seems like this is still more of a question of what you want to provide for your audience (or - if there's a customer - what they requested). 🤔

Editing part (When creating/editing texts containing emojis):

Do you want/need to 1. display sprites or are 2. you satisfied using native emojis?

in case of 1) You'll need the user to type in a contenteditable instead of in your aforementioned textarea / "simple textbox", but not necessarily a full-on rich-text-editor. (That you would only need if you'd want to provide additional editing tools like making your text bold/italic etc.) You should find plenty samples for that on the internet - my first Google result: https://stackblitz.com/edit/pt-ngx-emojimart-example
in case of 2) The easier option (no contenteditable or conversion logic required), the downside being that without sprites, emojis will be rendered differently across browsers/OSes and more complex emojis might not be rendered at all (or at least not recognizably).

In neither case can I think of a use case where you'd want to use the utf8EmojisToImages pipe for this part! (Just since you seem to think that. Only when editing existing texts you may want to directly call Utf8EmojisToImagesPipe.emojisToImages to convert unicode emojis from the DB back to sprites, but you don't need the pipe anywhere in the template code.)

Storing part (When transmitting the data to the server and serializing it):

Option 1
If you want your stored texts to be future-proof, I suggest storing them using unicode emojis instead of the sprite html code.

Why?: When rendering them, you might want to change their layout/sprite set at some point in the future without having to create a complex DB migration that needs to alter the contained html itself. (If you - to provide a stupid example - have something like Text <img src="apple_emoji_smile.png"> Some other text in your DB, it will be hard to rewrite that to Text <img src="facebook_emoji_smile.png"> Some other text later on. Of course you could make the sprite html a lot more generic to facilitate refactoring, but I believe the most generic you can get, is by using unicode.)

The second advantage of course is, that you'd also be able to display a text-only (no-sprites) version of your text later on, should you ever need to.

To convert sprites to unicode (If you have chosen 1 in the "editing part") you need to generate sprites that retain the unicode representation in the html (e.g. as hidden text content - see this code for example), so you can replace the sprite html with the unicode emoji when transmitting the data to the backend.

Option2
Save them as sprites. (Not future-proof, but a lot easier; only makes sense, if you chose 1 at the "editing part" of course)

Displaying part (When showing texts including emojis, that were stored in the DB in the frontend):

1. If you have unicode emojis in the DB and want them to display as unicode, there's nothing to do here. (Apart from the usual HTML rendering, should you have used a rich-text-editor in the "editing part")
2. If you have sprite emojis in the DB: same as 1.
3. If you have unicode emojis in the DB but want to display them as sprites - Use the utf8EmojisToImages pipe to do the conversion (only then!). Plus - like I said earlier - ensure any HTML is either escaped before even passing it to the pipe (without rich-text-editor in the "editing" part) or validated by the backend on create/update and sanitized by the frontend (with rich-text-editor in the "editing" part).