Im using .net multiline control. The I use jQuery to get data from that control:
$('.detailsCommentContent').val()
in this moment when I alert that value new lines are visible.
Then I make request www.example.com?commentContent= + "$('.detailsCommentContent').val()"
And in the http request there are no newLines signs at this moment.
What should I do to keep this new Lines symbols ?
thanks for help
Use a POST request for data that changes something, not a GET. That way you can POST whatever data you like without encoding it, and best of all: bots that are just spidering your page can't do any damage to your site. See also http://thedailywtf.com/Articles/The_Spider_of_Doom.aspx
You're going to have to URL-encode the value:
var url = "http://www.yourpage.com?commentContent=" +
encodeURIComponent($('.detailsCommentContent').val());
<Textarea> elements store "new lines" based on the host operating system, and sometimes even just the browser.
Between windows, mac, and linux, this could be \r\n, \n, or \r.
\r is a "carriage return", and \n is a "line feed". (C++ people will be familiar with crlf)
These characters make up a new line.
Here's the problem:
When you get the value of a textarea, it doesn't always preserve the line marker when going to store to a variable. You can try and replace the line-break, or encode it as per #Pointy's answer.
This question's existed in a few forms, but they're all hard to find because we have a lot of differnt names for the line-break.
Basically, the browser hates you for some reason, you need to hide what you're doing because it's trying to be really really smart.
use the escape() function on the value, or use a POST instead of a GET.
Related
There is a long story to this. Short form is, I have a legacy Javascript/JQuery/HTML app that can submit form data as query string variables to a long list of unrelated applications on multiple servers over which I have no control.
https://www.company1.com?s=this+is+the+data
As in the example, data is submitted with application/x-www-form-urlencoded encoding which replaces spaces with the + sign. Most recipients accept this normally. Some do not and require %20 instead. That's the problem.
I need to force the use of %20 for those problem URLs and am limited to Javascript and related libraries. The logic of parsing out and handling the outlier form destinations is not an issue. I just need to know how to force the use of %20 for the spaces.
Note: I don't think changing the enctype is the solution as text/plain would leave me with the same issue and cause other problems and multipart/form-data would leave un-encoded spaces. Maybe I'm wrong?
UPDATE (3/20/20)
This is a really goofy and temporary fix. So, I'm not posting it as an answer. (Still hoping for a real solution.)
Basically, I'm using Javascript's preventDefault() to hijack all form's submit events. Then, I'm checking for the specific URLs I know will fail if + signs are used.
For those, I'm grabbing the form's input name/values, constructing the query string manually and running it through encodeURIComponent() which encodes spaces with %20 like I need. Then, together with the form action, I can put the whole URI together and shove it across with window.location.href.
Please, somebody tell me there's a better way to do this entirely client-side!
I'm working on a project which accepts user input of a name and subsequently navigates to a website to scrape data related to that name. Everything is going well, except when users input non-ASCII characters, accented characters, and Non-Western characters. I'm looking for the simplest way to store those characters in a string without having javascript convert them to a "�".
I've done some research on the issue and found similar questions to mine, but they all seem to address removing accents from characters with accent folding, rather than simply storing those characters for later use.
I am using the readline-sync Node module to simplify the process of requesting user input. If that is part of the problem, please let me know! Here is the entirety of the code from my test algorithm:
const rlSync = require('readline-sync');
const name = await rlSync.question('Enter player name (Case Sensitive): ');
console.log(name);
This is all of the code from the test algorithm where the issue arises, so I know the source is not elsewhere. The primary test case I have been using up to this point has been any name with the letter "ë", although that is not the only problematic character. When I type "Hëllo" in the input prompt, the program outputs "H�llo".
Thank you all so much for any help you can provide! <3
UPDATE based on everyone's responses and a bunch of research: I think y'all are right about the console settings being an issue, rather than the code. Does anyone have a suggestion as to a good alternative CLI that uses UTF-8, or a means of updating the settings in the Windows command prompt to do so?
My Windows version is 10.0.18362.267. I have tried setting the language to "Beta: use UTF-8" via the administrative language settings, but this seems to present another issue: Instead of printing "H�llo", the cmd printed "Hllo".
(If this is beyond the scope of this forum I totally understand... just hoping to get as much help as I can!) :-)
I re-read your question... I don't recall the node.js bit being there before, but....
Your issue is not in your program. It is the settings in your terminal. You need to change your terminals settings to use UTF-8 and a font capable of displaying those characters. Or switch to a terminal that can.
If your terminal only understands ASCII or is set to wrong encoding, it's showing the replacement character because it can't display them.
Node.js uses UTF-8 by default, so internally all should be well.
**Note:
I checked up on readline-sync to be sure it's not the problem, and what I read seems to support this hypothesis.
https://github.com/anseki/readline-sync/issues/58
ECMAScript (Node.JS) already supports Unicode, by default. If your
environment (not readlineSync) does not support those characters (e.g.
you use Windows), the console.log method in your code can not print
those when the answer contains those characters.
Old answer:
If your seeing that symbol in place of characters, it is almost certainly a font issue rather than a javascript issue. Try using a font that supports these characters. How you do this depends on what your viewing the output with (i.e. terminal, browser, etc). If that doesn't work, you may need to specificy using utf8 as well, and also depends on the same.
This seems an issue of your text encoding settings on your server. If stored in a DB then maybe not in UTF-8, if happens directly in node on output, reading from a file and output in console, then you must make sure to specify to use UTF-8 if reading from a file. If happening like with you using node cli and reading from console input this is your text encoding engine that doesn't support multibyte.
So this is a settings issue so make sure all is in UTF-8 or even 16 since multibyte must be supported as all accents are stored that what cause they need a second memory space for the accent...
I use JS to sent encodeURIComponent string to a PHP file write and has been working fine for years; until recently I met with a strange effect that the text need to be further encoded with escape in order to get it to work! The sympton start to show only when I use an open source wysiwyg editor !
What could be the offending characters in URI that need escape to fix it? I used to think URI only reserve ? & = for its syntax to work.
The situation you describe could possibly be explained--although there's no way of knowing without you telling us what the string is, and how it's being used--by a URL which involves two levels of nested URL-like values.
Consider a URL taking a query parameter which is another URL:
http://me.com?url=http://you.com?qp=1
That URL is subject to misinterpretation, so we would normally URL-encode the you.com URL, giving us:
http://me.com?url=http%3A%2F%2Fyou.com%3Fqp%3D1
Whoever is working with this URL can now extract the query parameter named url with the value http%3A%2F%2Fyou.com%3Fqp%3D1, decode it (often a framework or library will decode it for you), and then use it to jump to or call that URL.
Consider, however, the case where the you.com URL itself has a query parameter, not ?qp=1 as given in the first example, but rather something that itself needs to be URL-encoded. To keep things simple, we'll just use "cat?pictures". We'd need to encode that, making the query parameter
In other words, the URL in question is going to be
?qp=cat%3Fpictures
If we just use that as is, then our entire URL becomes
http://me.com?url=http%3A%2F%2Fyou.com%3Fqp=cat%3Fpictures
Unfortunately, if we now decode that in a naive way, we get
http://me.com?url=http://you.com?qp=cat?pictures
In other words, the nested URL has been decoded as well, meaning that it will think the URL has two query paramters, namely url and qp. To successfully deal with this problem, we need to encode the second query parameter a second time, yielding
http://me.com?url=http%3A%2F%2Fyou.com%3Fqp%3Dcat%253Fpictures
Please note, however, that if you use your language or environment's built-in tools and libraries for handling query parameters, most of this will happen automatically and prevent you from having to worry about it.
The symptom start to show only when I use an open source wysiwyg editor
An editor merely places characters in a file. It's very hard to imagine that an editor is causing the problem you refer to, unless perhaps one editor is configured to use smart quotes, for example, which would pretty much break everything that involved quotes.
So I decided to use GET in my form element, point it to my cshtml page, and found (as expected) that it automatically URL encodes any passed form values.
I then, however, decided to test if it encodes angle brackets and surprisingly found that it did not when the WebMatrix validator threw a server error warning me about a potentially dangerous value being passed.
I said to myself, "Okay, then I guess I'll use Request.Unvalidated["searchText"] instead of Request.QueryString["searchText"]. Then, as any smart developer who uses Request.Unvalidated does, I tried to make sure that I was being extra careful, but I honestly don't know much about inserting JavaScript into URLs so I am not sure if I should worry about this or not. I have noticed that it encodes apostrophes, quotations, parenthesis, and many other JavaScript special characters (actually, I'm not even sure if an angle bracket even has special meaning in JavaScript OR URLs, but it probably does in one, if not both. I know it helps denote a List in C#, but in any event you can write script tags with it if you could find a way to get it on the HTML page, so I guess that's why WebMatrix's validator screams at me when it sees them).
Should I find another way to submit this form, whereas I can intercept and encode the user data myself, or is it okay to use Request.Unvalidated in this instance without any sense of worry?
Please note, as you have probably already noticed, my question comes from a WebMatrix C#.net environment.
Bonus question (if you feel like saving me some time and you already know the answer off the top of your head): If I use Request.Unvalidated will I have to URL-decode the value, or does it do that automatically like Request.QueryString does?
---------------------------UPDATE----------------------------
Since I know I want neither a YSOD nor a custom error page to appear simply because a user included angle brackets in their "searchText", I know I have to use Request.Unvalidated either way, and I know I can encode whatever I want once the value reaches the cshtml page.
So I guess the question really becomes: Should I worry about possible XSS attacks (or any other threat for that matter) inside the URL based on angle brackets alone?
Also, in case this is relevant:
Actually, the value I am using (i.e. "searchText") goes straight to a cshtml page where the value is ran through a (rather complex) SQL query that queries many tables in a database (using both JOINS and UNIONS, as well as Aliases and function-based calculations) to determine the number of matches found against "searchText" in each applicable field. Then I remember the page locations of all of these matches, determine a search results order based on relevance (determined by type and number of matches found) and finally use C# to write the search results (as links, of course) to a page.
And I guess it is important to note that the database values could easily contain angle brackets. I know it's safe so far (thanks to HTML encoding), but I suppose it may not be necessary to actually "search" against them. I am confused as to how to proceed to maximum security and functional expecations, but if I choose one way or the other, I may not know I chose the wrong decision until it is much too late...
URL and special caracters
The url http://test.com/?param="><script>alert('xss')</script> is "benign" until it is read and ..
print in a template : Hello #param. (Potential reflected/persisted XSS)
or use in Javascript : divContent.innerHTML = '<a href="' + window.location.href + ... (Potential DOM XSS)
Otherwise, the browser doesn't evaluate the query string as html/script.
Request.Unvalidated/Request.QueryString
You should use Request.Unvalidated["searchText"] if you are expecting to receive special caracters.
For example : <b>User content</b><p>Some text...</p>
If your application is working as expected with QueryString["searchText"], you should keep it since it validate for potential XSS.
Ref: http://msdn.microsoft.com/en-us/library/system.web.httprequest.unvalidated.aspx
I'm currently trying out websockets, creating a client in JavaScript and a server in Python.
I'm stuck on a simple problem, though: when I send something from the client to the server it always contains a special ending character, but I don't know how to remove it.
I've tried data[:-1] thinking that would get rid of it, but it didn't.
With the character my JSON code won't validate.
This is what I send through JavaScript:
ws.send('{"test":"test"}');
This is what I get in python:
{"test":"test"}�
I thought the ending character was \xff
The expression "data[:-1]" is an expression that produces a copy of data missing the last character. It doesn't modify the "data" variable. To do that, you have to assign back to "data", like so:
data = data[:-1]
My suspicion is the "special ending character" is a bug, somewhere, either in your code or how you're using the APIs. Network code does not generally introduce random characters into the data stream. Good luck!