i want to break a line and used \n but its not working. creating Lambda function.
callback(buildFulfilmentResult('Fulfilled',"Thanks, for using our services " +item.Name+ " Your Flight status is Confirmed \n Arrival city: " +item.Arrival_city));
how to do then?
we need more information about how the text is being displayed to give you a really good answer.
Handling line breaks is the responsibility of the entity handling the display, and so, what you need to send depends greatly on how the text is being displayed.
For example, if your chat bot is for the web, you might be able to get it to display line breaks by sending <br> instead of \n, since that is the line break code for HTML.
That said -- accepting and displaying raw HTML from your back end could represent a serious security risk.
If I was designing a this whole thing, I would use \n to represent the line break in NodeJS, and on the web where I displayed the text, I would
take apart the string (string.split("\n")),
create a new DOM element for each part of the string,
make sure these elements were display: block, and
put the text into each of those elements via the .textContent property.
This final step avoids making the browser parse HTML, mitigating that security risk.
Related
I'm inputting text in a texbox which is working fine. But there is an existing watermark in the textbox. The entered text in the textbox is inputted as a watermark, hence clicking on 'Next' button results in an error.
Can somebody help on how to enable textfield before entering text using Blue Prism tool?
Can you sandkey event(like SAPCE key) into that field it may cause the watermark to clear it self?
How do you clear that filed in the first palce?
quoting directly from the browser automation guide which you should've read and consumed before being a developer:
Using a Write stage to write to an HTML element such as a text field
does not always work properly. For example, you might try writing to a
username field, only to see a message appear on the web site saying
something like “Please enter a username”, even though you can see that
the value has been correctly written to the field. This can happen
because the data validation functions used by the web form might be
expecting keystrokes, and the write stage has “fooled” it. To get
around this, you will need to use a Navigate stage to call the Send
Keys Action instead of using a Write stage. Some websites have maximum
character limits imposed on some text fields. Using a Write stage can
sometimes fool the website into allowing too many characters into the
field, because the Write stage “sets” the field value rather than
keying characters into it. This is important to bear in mind because
if a field has been filled with more characters than the website would
usually allow, the website could produce an error when you try to
submit or post the data.
to get around this go ahead and use sendkeys, those are likely the best option to push past this validation tool issue on the website.
I posted this once, but I was a bit too vague in my information, so I am trying again.
nHibernate/Fluent nHibernate seems to be truncating, or 'stripping' certain characters from strings that I submit to my database. For example, if I submit the string This\nis\na\nblock\nof\ntext\n\with\nreturns, the \n symbol represents the carriage returns. I want these to stay intact, because later, when the data is read back out, that is when it will be parsed by MarkdownDeep
However, I have noticed that the \n symbol specifically gets 'stripped' when the database does its commit. I have performed debugging all the way up to ISession.SaveOrUpdate(object) and I can confirm that the data is unaltered up to the point I can visibly follow the debugging. But then I go and look at the record in the database, and it has been stripped of this symbol.
If I use String.Replace("\n","\\n")) on the text, it will actually work right. But this does not seem like an intelligent way to go about storing everything. This means I have to continuously remember what fields may have this problem and do in-between logic.
Is there a setting I am missing in nHibernate/Fluent nHibernate that is forcing it to strip this data?
Debugged Code Path
Following the path of my code, it goes like this.
ASP.NET MVC View (textarea) -> This\nis\na\nblock\nof\ntext\n\with\nreturns
ASP.NET MVC Model (Json) -> This\nis\na\nblock\nof\ntext\n\with\nreturns
ASP.NET MVC Controller Parameter -> This\nis\na\nblock\nof\ntext\n\with\nreturns
ISession.SaveOrUpdate -> This\nis\na\nblock\nof\ntext\n\with\nreturns
Database Record -> This is a block of text with returns
So the problem is obviously happening at the ISession level.
How are you actually verifying that the \n's aren't in the database record? You will not see a \n visually when you look at the record in sql management studio. It will look like a space if you just query the data. Copy and paste that data into notepad++ and show all the characters that exist in that string (I'm betting you will see the new lines).
Whenever you manually insert \n in the table view like you describe above this is not a special character. It is the actual text '\n'. Please note that '\n' != char(10). One is a special character and the other is just text.
Use this add-on to log produced sql's. then you can find where is the problem.
+ If you are displaying the data on a web page, don't forget to use replace("\n","<br/>").
I have an ASP.NET form which has textbox. The user can enter any characters,numbers etc. I should not restrict the user to filter hazardous characters. But I need to prevent cross site scripting.
The user can enter any text like alert('hi') like this.
The data should be saved as its in DB. Also it should be return back and display in label in form as it is.
How can acheive this without cross site scripting
Well, I think you should consider some restriction on what users are allowed to enter. You don't want null bytes or non-printable characters do you? Even if you accept more than alphanumeric values, you should decide which characters are allowed and exclude the rest using a simple regular expression (with start and end anchors of course).
Then, the way to prevent XSS is to encode the value whenever you display it. There are a whole host of ways to do this, but using the AntiXSS class of the Microsoft Web Protection Library is the best if you ask me. You can encode the output based on whether you're rendering it within HTML elements, attributes, JavaScript, and so on.
Is it possible to eliminate these characters from a wordpress password? I have heard that it can open up scripts this way, that hackers can use to get in. Thank you.
Simple answer:
Your friend has misinformed you. Restricting these characters in a wordpress password is not something you need to worry about. But as they say "There is no smoke without fire".
More background information:
In your own web-application code, you should always be especially careful whenever you take any data from a user (Whether from a form, a cookie,or a URL) or another external computer system or application. The reason for this is that you want to avoid the values being interpreted as code and not just used as data.
The issue that has led your friend to worry about the <> characters is called Cross-Site Scripting and is a kind of attack that malicious users can perform to "inject" html or javascript content into your pages. If you accept information from the user that contains these html mark-up characters and re-display it on the same, or another page, then you can cause their html or javascript content to become part of your page. Any javascript content will run with access to the same data as the user that views the page.
Whenever outside data is read, it sould always be
validated : i.e. checked that it looks like the kind of thing you are expecting, and rejected if it doe not.
and encoded: i.e. When this data is displayed to back to the user or sent to another part of the system, it is converted to be safe. The type of conversion always depends on how and where the data is being used.
Please note that the angle-bracket characters are not the only thing to worry about. Please also note that it is well proven that disallowing certain characters (also called "blacklisting") is never the best way to secure code. It is always safer to state what is allowed (also called "whitelisting").
When do you call Microsoft.Security.Application.AntiXss.HtmlEncode? Do you do it when the user submits the information or do you do when you're displaying the information?
How about for basic stuff like First Name, Last Name, City, State, Zip?
You do it when you are displaying the information. Preserve the original as it was entered, convert it for display on a web page. Let's say you were displaying it in some other way, like exporting it into Excel. In that case, you'd want to export the preserved original.
Encode every single string.
You should only encode or escape your data at the last possible moment, whether that's directly before you put it in the database, or display it on the screen. If you encode too soon, you run the risk of accidentally double encoding (you'll often see & on newbies' websites - myself included).
If you do want to encode sooner than that, then take measures to avoid the double encoding. Joel wrote an article about good uses for hungarian notation, where he advocated use of prefixes to determine what is stored in the variable. eg: "us" for unsafe string, "ss" for safe string.
usFirstName = getUserInput('firstName')
ssFirstName = cleanString(usFirstName);
Also note that it doesn't matter what the type of information is (city, zip code, etc) - leaving any of these unchecked is asking for trouble.
It depends on your situation. Where I work, for years the company did no HTML encoding, so when we started doing it, it would have been almost impossible to find every location within the system that user input could be displayed on the page.
Instead we chose to sanitize input on its way into the system since there were fewer input points than output points. We sanitize immediately before inputting data into the DB, although we don't use Microsoft's AntiXss library, we use a set of homebrew methods that whitelist ranges of HTML tags and characters depending on the type of input.
If you're designing the system from scratch, or you have a system that is small (or managed well) enough to encode output, follow Corey's suggestion. It's definitely the better way to do it.
Encoding is not a property of the data, it is a property of the transport mechanism. Therefore you should unencode data when you receive it, and encode it appropriately before transmission. The transport mechanism determines what sort of encoding is necessary.
This principle holds true whether your transport mechanism is HTML, HTTP, smoke signals, etc. The trick is knowing how to do the types of encoding manually, and when various frameworks do the steps for you automagically. For instance, ASP.NET will encode data assigned to a System.Web.UI.WebControls.Button's Text, but not text assigned to a System.Web.UI.WebControls.Literal's Text. jQuery will encode content you set with .innerText(), but not content you set with .innerHtml().