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/>").
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.
So I am in the process of building a new screen for my application (built using Verivo App Studio - uses the same syntax / expressions as the .NET Framework) that will link items directly from the SharePoint list to be view able in the App.
This has all been no problem so far, however, when I pull the data down from SharePoint, some of strings (such as the title of a document) come with extra characters, in varying length, at the start (such as 132;#Titleexample). When viewed in SharePoint, these additional characters are not present. After some searching, it seems SharePoint uses ;# in a similar fashion that a CSV file uses commas.
My question is; is it possible to parse the string (either on the SharePoint side {creating a new view?}, or from within the Verivo App studio side {though it seems it has limited parsing functionality}), so that I can display the data correctly? Keep in mind the additional characters are of varying length, could be 123;#Title or 1;#Title, so a simple SUBSTRING function won't suffice. If there was a function to pick up the string after the # key, it would be great!
I am new to this so apologies if I have left out anything obvious.
Thanks in advance!
When I make GET request on my service stack it is working fine.
Thanks to service stack, to make a developer work very easy.
On the page, I am having two queries. May be some one can help me. according to me it is always better to know for what you are working and how the internal thing works.
see the above image, when I send GET request on service stack, it displays me this kind of layout.
1>I want to know can I make it customize display. i.e. can I remove the sentence "SnapShot of ....." (the big header)
2>I want to know, why it takes space in header of table (the result table) for every capital character define in property.
i.e. in my project the name of property in class is -> instanceName, which is represented as "instance Name" in header .
Can anyone tell me what is the reason behind this?
The implementation of the HtmlFormat is in a single class at:
https://github.com/ServiceStack/ServiceStack/blob/master/src/ServiceStack/WebHost.Endpoints/Formats/HtmlFormat.cs
It allows some customization, e.g:
HtmlFormat.TitleFormat = "";
HtmlFormat.HtmlTitleFormat = "";
The default behavior like splitting the case of the header labels was specifically added to make it more readable. To change this you are going to have to download the source code, make changes to the class yourself and cut a new build. This is the line that does the split-camel-casing:
https://github.com/ServiceStack/ServiceStack/blob/master/src/ServiceStack/WebHost.EndPoints/Formats/HtmlFormat.cs#L289
You can read more about the JSON HTML Report Format used at:
https://github.com/ServiceStack/ServiceStack/wiki/HTML5ReportFormat
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.
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().