We Keep Coding

My ID's have been changed, how can i stop it?

I've been trying to do something simple, i think, let me explain:
I have an BPMS software where a send an e-mail at the end of the process, this e-mail is an HTML page that i created, inside the HTML page we have some identifying codes that get a field value from an previously form, some strings. The problem is, when i transfer that value to the HTML page, obviously the "Enter" key doesn't work like the "br" tag, so i made a simple javascript to replace the "enter" for the "br". It worked, but when i send the e-mail my ID is changed and they put an "x_" prefix, so there goes my question.
Can i stop it or there is some other way to do it?
The code is below:
<p id="informacoes">
TEST
TEST
</p>
<script>
var strMessege = document.getElementById('informacoes');
strMessege.innerHTML = strMessege.innerHTML.replace(/(?:\r\n|\r|\n)/g, '<br />');
</script>

It seems like your end goal here is to retain original line breaks present in the source code. I think your best bet would be to address this using CSS.
Take a look at the CSS property white-space, MDN: white-space property
By default, CSS collapses white space (e.g. multiple non-breaking ("regular") spaces, tabs, and newlines) into, effectively, a single regular space. In your example, the line breaks that you see in the source code are being collapsed and so they will not be rendered by the browser or email client.
Try using CSS to set a different white-space property, like
#informacoes {
white-space: pre-line;
/* depending on your use case,
a different value might work better */
}
Property values other than white-space: normal (which is the default) will change whether and how white space, including new lines, are collapsed when rendering from the source code to the screen.

jQuery Profanity filter not updating while typing

I would like to dynamically filter bad words using this profanity filter. The api will change "ass" to "***" in the given example, only if the text was there before page load. I would like it to change recognized bad words as they are typed, to prevent someone from sending a naughty messages through a my contact form.
Here is what i've got so far:
<div id="msg">
<textarea type="text" onkeypress="badFilter()" id="mess_box" name="cf_message" style="height:150px;" maxlength="500" placeholder="Message" ></textarea>
</div>
<script>
function badFilter() {
$typedText = $('#mess_box').val();
$typedText.profanityFilter({
customSwears: ['ass']
});
}
</script>
I would think that the 'onkeypress' attribute would force the script to check for updated textarea values, but that is not the case.
Help appreciated!

You are assigning the filtered value to a variable, and then you are not using it.
function badFilter() {
$typedText = $('#mess_box').val();
$typedText.profanityFilter({
customSwears: ['ass']
});
$('#mess_box').val($typedText);
}
the last line will apply text back to the input box.
The problem is that you are changing the value of the input element while the user is typing. This way, there will be glitches if the user types in the middle of the text (not at the end).
You could create a system of two input controls (one hidden, one visible) where user types into one (hidden) and censored text appears in the visible one. When user positions cursor in the visible control, you would position it on the same character in the invisible one. Updating the text of the visible control will not glitch while the user is writing.
This will work only if profanityFilter can work with string object.
If not, the correct way to initialise it would be
$('#mess_box').profanityFilter({
customSwears: ['ass']
});

I do not know how the plugin works, but
$typedText = $('#mess_box').val(); <-= reading the value, storing a string
$typedText.profanityFilter({ <-- expects jQuery object of an element, you have a string
customSwears: ['ass']
});
Should be
$('#mess_box').profanityFilter(...);

To clear up vagueness from my question, the Profanity filter i was using is this --> https://github.com/ChaseFlorell/jQuery.ProfanityFilter
And to my understanding (which isn't great), the plugin wasn't designed to filter out words dynamically as being typed, this might require Angularjs or more DOM manipulation.
Vinko Bradvica provided a good explanation and work around with this plugin in order to dynamically censor bad words as they are being typed.

The right way to handle it is like that:
Create a <p> tag in your html with style="visibility: hidden;"
Then add this code in your JS file:
$('#textarea').keyup(function () {
$('#textarea-filter').text($('#textarea').val());
$('#textarea-filter').profanityFilter({
customSwears: ['ass']
});
$('#textarea').val($('#textarea-filter').text());
});

JavaScript Escaping Form Values

I know there are a lot of JavaScript escaping questions, but nothing seemed to fit my needs.
I have textarea elements being dynamically displayed on a JSP. In the case of invalid form submits, I need to repopulate these fields with the values the user entered. I am doing this like so (note: simplified version):
var textareaBox = document.getElementById("myTextArea");
if (textareaBox) {
textareaBox.value = '${myForm.myValue}';
}
Everything works fine until the user enters a value in the box that contains special characters. I've tried using the escape and unescape JavaScript functions individually and combined to no avail.
Does anyone know how I can handle these special character values? Note that I obviously do not want the escaped text in the textarea as this would not look good to users.

Use JSTL's <c:out> tag to escape it and assign it as innerHTML of the text area:
textareaBox.innerHTML = '<c:out value="${myForm.myValue}" />';
But why don't you just display it in textarea's body directly without the need for JS?
<textarea id="myTextArea"><c:out value="${myForm.myValue}" /></textarea>
The <c:out> (and its EL function counterpart fn:escapeXml()) escapes XML special characters.
See also:
Not able to display special characters properly in a JSP page

Displaying <textarea> value as HTML

I have a form with several textarea elements. User enters data and submits the form. On the next page it shows submitted text as static text - in p tags. Obviously New Line and multiple paces get ignored and everything just shows in one line.
I can do some preprocessing like replacing New line characters with "br/" and spaces with . but I was wondering if there is a standard solution to that either on server side (C#) or client side (javascript)

Since the data is preformatted (and this isn't just a matter of presentation), the pre element would be suitable (you will still need to replace <, & and friends with the appropriate entities).

Apply CSS white-space: pre; on the <p> element. This way any whitespace inside the element will be preserved.

Actually, I ended up replacing new line symbol with [br/] and it works very well.

Quote in HTML attribute destroys layout

My site has user generated content. I noticed that if the user has quotes in some text and later I displayed that text in an HTML attribute, the layout would get screwed up in IE.
Hello
However, if I had generated the same anchor with Javascript (Prototype library), the layout would not be screwed up in IE:
$$('body').first().appendChild(
new Element(
'a', {
title: 'user "description" of link',
href: 'link.html'
}
).update('Hello')
);
Why is this so? The JS and the plain HTML versions both have the same intended result, but only the JS doesn't screw up IE. What's happening behind the scenes?
BTW, I do strip_tags() and clean XSS attacks from all user input, but I don't strip all HTML entities because I use a lot of form text input boxes to display back user generated text. Form elements literally display HTML entities, which looks ugly.

You need to escape all output that is user-specified (using entities). The DOM-methods do that automatically.

I don't know how you are processing the user generated content, but you could use a replace function to clean up the input something like string.replace("\"", "")

The answer to your question: 'Why is it so' is because in your JavaScript example set the title attribute with single quotes. So the double quotes in the user generated string are already escaped.
In you A tag example, single quotes around the text you use in the title attribute may be a way to solve the rendering problem.
However, Your HTML attributes should be in double quotes, so you would be better off using entities, as suggested by #elusive in his answer.