RoR 3 automagically sanitizes ERB templates (when done correctly). However, I've got a little project where I'm using RoR for the application tier only and javascript for the presentation. So, typical request is ajax call to rails route and render returned json. Issue is it is currently possible for me to inject js, create a new product with title <script>alert('hello')</script> and this is returned as is on the next request and the browser happily interprets the script.
Is it best to
sanitize the inputs on post?
sanitize the json response on the server? (override to_json?)
sanitize the json response on the client?
I appreciate any input.
You should encode HTML entities on the content client-side as you're appending data to the page.
The question is, do your other product fields intentionally contain markup like links or paragraph tags that will also be encoded? If this is the case, and you intend to render some parts of the json response as HTML on the page, then you should be sanitizing your input at the point when new products are created, and limited the HTML tags you allow to a specific subset, and then scrubbing away their attributes. There are libraries to automate this process, like the sanitize gem.
Related
I am used to creating webapplications with Wicket. There it is possible to generate a HTML page using POST, receiving a large JSON from the client (browser) to generate some charts. This can be done for example with CURL.
In Angular, I could not find a similar approach.
What is the recommended way to render a chart based on the JSON that a browser provides? An URL parameter is not really the way to go as the URL length is limited.
I can think of a work-around wheren I first post the data to some webservice, receive an id, and then pass that id to an URL in Angular, but that seems a lot of work for something simple :)
I recently started learning to create restful web services with spring framework.
all the course is using postman to send requests but I want to send requests from a web page, like creating a table and send firstName and lastName from the HTML file (from the view, .jsp file) and store it in the database.
everywhere I lookt, they all saying the standard file to send to or retrieve from a restful endpoint is JSON, not HTML.
and from what I see #RequestBody only accepts JSON or XML, not HTML inputs.
I tried sending data from HTML(Method = "POST") to a #PostMapping method of my restful web server, to create something and store it in the database but an exception that says "Content-type not supported" was thrown.
I have lots of questions about this, and they all point to the same thing, Not understanding the whole thing.
what's the point of creating restful web service for the back end of a website, when HTML doesn't support put and delete requests and standard file that everyone uses to get requests from the client is JSON, not HTML.
can a web page (HTML) generate it's content to form a JSON file that is being sent back from a restful server?
how can I generate a JSON file from the inputs in HTML file and send it to the restful #PostMapping method?
there are two things that I should mention here,
I don't know much about creating web pages (HTML) I have only been creating very simple HTML files to help me create and test a back end server.
I searched so many questions before I post this one, and none of them helped me.
I will try to answer your questions
First, you need to understand what rest is it is a Representational state transfer (REST) is a software architectural style that defines a set of constraints to be used for creating Web services.(https://en.wikipedia.org/wiki/Representational_state_transfer)
so we follow a set of standards to make things easier.
Now coming to your actual question why JSON and not HTML because these are not only consumed from HTML these are consumed by different apps or services and json is a more lightweight and less verbose format, and it’s easier to read and write as well. In most cases, it’s ideal for data interchange over the internet
and we can use it with front end libraries like react , jquery or vanilla javascript to render the content in HTML from JSON without any changes to the API and also use a Backend web service to use this API.
https://api.jquery.com/jQuery.getJSON/
https://reactjs.org/docs/faq-ajax.html
for the other two questions basically You don't have to generate JSON file to call the rest API from HTML and render the content in HTML Instead you can use front end libraries like Jquery, React, Angular or use vanilla javascript to render content and call the rest API.
I am working on play framework with SCALA as backend.
Json data is given to the front end from the controller.
I want to add HTML as value of some fields of json.
This HTML will be kept as a template and data will be added in this template at run time.
I think i should put unique names in the HTML template and then these names will be replaced by the data which i want to add at run time. Ultimately, this HTML will be added in the json response.
Is my approach right? If not, what is the best approach to add data in an HTML template,add this template in json response and send this combined response to the front-end for further use?
Is it a good practice to use string replacement to add data in an HTML template?
I think as long as you use Play, you can put your HTML templates into app/views package. Let's say you call your template mytemplate.scala.html
You can parameterize this view as any Play view.
In the place in your code where you generate your JSON response you can then call mytemplate(parameters) to get html generated, Play will do all the work here for you. Then using play.api.libs.json.JSON object's methods and related facilities you can convert this html to JSON.
So in your controller's code you will have something like Ok(JSON.toJson(mytemplate(parameters)))
This is of course a sketch, so you will need to elaborate and try.
I have a situation where I have to write a api to create a resource and amongst datafields that I need to accept is a string that is basically contents of a html file. As I see it I have a choice between structuring the entire thing as a json object where this field is a string field with urlencoded html string , and having the Content Type as multipart/form-data where each of the fields and the html string (UTF-8 encoded) is a part in the message.
Not using json is something I am not comfortable with as I feel violating the REST standards in not structuring the content of the entity I am about to create thus there is a loss of information for the consumers as they can't tell immediately looking at my api definition about what data to feed to it. But practically multipart/form-data handles stuff like html file content better and more efficient as I will not have to urlencode it and can control the char-encoding also.
What will be a better approach in current context and upholding RESTful principles ? Also are there other trade-offs i should be aware of ? what about parsing a json with a huge string field (~ 200 Kb)embedded?
EDIT :- I was reading some similar questions on SO and one approach that stood out was the 2-step approach of making a first call with metadata to create the entity and then upload the file as an UPDATE process to the created entity wherein we use multipart/form-data. In that context, I guess , what I am asking is how sound is an approach where I send both metadata and the file in a single api call as multipart data , where each metadata field is actually a part in the multipart message as is the file.
The canonical way to upload files to REST API is using the multipart/form-data. As W3 recommendation guide says:
The content type "multipart/form-data" should be used for submitting
forms that contain files, non-ASCII data, and binary data.
Multipart/form-data has advantages over base64 to represent binary data. Is sticked to REST/Http philosophy, and simplify the develop of API clients.
Returning values from Forms: multipart/form-data
W3 Recommendation guide
The good practice is to use multipart/form-data whenever files are uploaded to the server along with database fields. Do not send a base64 JSON string as the request to your Rest API as it might corrupt the file or degrade the performance of your application.
As far as documenting multipart/form-data Rest API for your consumers is concerned you have to force your API consumers to use the same form fields which you have predefined in your web service.
Returning Values from Forms: multipart/form-data
I started using FormData objects everywhere on the client-side, in lieu of regular form input fields, for dynamic REST posts. FormData is presented in a positive light in various tutorials, so I went with it.
However, down the line, this caused me problems when decoding the form data into my Go structs. FormData objects are sent as "multipart/form-data" (regardless of files being sent) and I believe my decoder in Go didn't convert the raw data back to string form. Eventually my SQL queries were throwing panics, as hex data was being sent in where strings should have been.
So with some adjustment, I could use FormData however I've decided to revert to the simple universal recommendation: Use "multipart/form-data" only for special cases like when sending files. Otherwise, just use regular "application/x-www-form-urlencoded".
So there's a small debate by my team, and I'm sure this is answered in many places but I couldn't find any definitive answers.
Right now we have a server that tosses up JSON data (think REST, sorta). The client is a complete JavaScript client that uses $.ajax to grab the data and render it appropriately.
The client is using UnderscoreJS templates to render data within the HTML:
<%- something %>
So if the server sends down a JSON block (non-html encoded):
{
"username": "Joe's Crab & Cookies"
}
Should the server be HTML or JavaScript encoding this value? Or should that still be left up to the client?
What if a bit of data from the server needs to be an attribute of an element:
<li data-item-id="<%= userId %>">something</li>
I realize that I shouldn't need to encode anything that's generated by the server, it's all data that is entered by the user. So imagine the "userId" above being set by a user, not generated.
So if we encode on the server and on the client we see on the rendered page:
Joe's Crab & Cookies
If you're sending json data somewhere, the only encoding that should be done to it is json encoding. You don't necessarily know if the values are going to end up in sql, javascript, xml, html attributes, a winforms app, etc.
Now, on the other hand, if some of your json values were to contain html, that html value should be encoded, ready-to-display html. It depends on context.
First of all, you should be escaping the value, if it can be set by a user.
You should use as much escaping and validation as possible -- both on the input fields, when capturing the data on the server, when inputting into DB and, finally, when rendering it back.
Among the mild consequences of not escaping data would be that it can crack your HTML when you're outputting to data-item-id.