I'm looking at the liquid templating language for Rails apps:
http://wiki.github.com/tobi/liquid/
I'd like my users to also be able to make AJAX calls (just like the ones in rails for periodically_call_remote, observe_field, etc). Is this possible?
Assuming the rails helpers can be added as filters, how will the user be able to modify what gets returned by the AJAX call? They cannot modify an rjs file on the server or anything like that. I suppose the AJAX call could return JSON (instead of rendered html) and then the javascript could use that to render something. But I'm having a little trouble envisioning how it would work exactly.
If anyone can point me to an example of this or clarify it'd be much appreciated. Thanks!
Is allowing any user to make any ajax call really what you want ?
Don't forget you can't trust your users. Do you really want them to be able to request any page on your domain name ?
I guess you want to be able to allow them to request some pages only though. A defined list of urls.
Then you can just create one filter per url that'll return your content.
So if the user does in his template :
{{ get_users }}
Which will do, internaly, an ajax call retrieving the list of all your users.
You can think generic when you're working on things that only developers should be working on.
But when it's about allowing your users to change the code of your application, you should restrain them so they don't hack and break everything.
Related
I am making a rails MVC style application.
When I am loading the pages, the controller gets the data from the model and forwards it to the view and the view renders itself.
However, I am wondering what the appropriate way is to interact between javascript and my database.
Say the user is playing a game and he has a bunch of clues on the screen. Clicking a clue will move it to his clue box and needs to update the UserClues model to add the clue.
The user also needs to be able to remove clues where the clue gets removed etc...
This needs to happen via AJAX.
I am wondering what the appropriate approach is.
Say he got his page from /Investigation which loaded the page using the InvestigationController.
Should the InvestigationController be the one calling the model to add/remove the clues, or should some sort of data controller do it.
For example:
/Investigation/AddClue
or another controller
/User/Clues/Add
The reason I am asking is I have a lot of data on my pages that is created/added/modified and I am wondering if my routes/controllers should be separate for data manipulation and pages, or if I should have a controller for each page and it also manages what the user can do on that page (like add / remove clues to and from a ClueBox)
Thanks
Ideally you will want to have a separate controller for each resource. Even though your current view is in the context of the Investigations, controller, dealing with clues should have its own resource. Otherwise things can get complex. If the clues are investigation specific, then you can scope them under the Investigation URL.
resources :investigations do
resources :clues
end
This will give you something like /investigations/1/clues/1, but this maybe not be necessary, and I would avoid nesting unless required.
The controller can then respond in the correct format. In this case Rails UJS provides you with the tools you need. You can render a create.js.erb or destroy.js.erb templates to handle user actions. The templates would have the required JavaScript and dynamic code to update the screen state.
If at all possible, try to use Rails' RESTful routes. In this case, that probably means line in your routes file that looks something like:
resources users do
resources clues
end
In your users/clues_controller.rb file, put in actions for the different AJAX requests, like create to add a clue to a user (via a POST request), destroy action to remove a clue from user (via a DELETE request, might need to simulate with POST + "_method=delete" parameter).
Basically I'm wondering if it's possible to have a form on a site outside of mail Rails app to POST to a form in my Rails app. For example (not what I'm going to be doing) a contact form on a Wordpress site, when submitted would POST the values to my Rails app. What would my steps be to make that possible? Or any references that are already out there?
OR if it's possible to load a form from my Rails to an outside site using Ajax or something. Eh that's probably a long shot but don't know what would be more secure and slim on code.
Thanks so much!
If you do it with AJAX you may have to handle XSS issues. Maybe you need to write an easy API for your application that could be consumed from that other application. That's not difficult from Rails and you can get help from some good controller abstractions like inherited_resources.
At some point that external application will send a form to itself using AJAX and will handle it and send it to your rails application using JSON or XML... or whatever format you want.
Yes, you can do it. Be aware that you'll have issues with the form authenticity token, so it might be easier to turn the token off.
what are the scenario's where Ajax could not be used in Rails Application.
Is there any disadvantages of AJAX (AJAX on RAILS) if yes please mention which are they?
The browser may not be able to interpret javascript, but rails can detect that and you can act accordingly
The user cannot back/forward or bookmark a particular state within the page, because it is dynamically generated
Search engines cannot index particular states within the page
There may be others that i can't think of right now.
I think the biggest disadvantage of AJAX in general is the desire to use is when it is not needed.
I'm currently in the process of writing my first Rails app. I'm writing a simple blog app that will allow users to comment on posts. I'm pretty new to Rails, so I'm looking for a bit of guidance on how to address security concerns with user input.
On the front end, I am using TinyMCE to accept user input. It is my understanding that TinyMCE will strip out any suspicious tags (e.g. <script>) from user input before posting to server. It seems that this could be bypassed by disabling javascript on the page, allowing a user to have free reign in the text area. TinyMCE recommends using javascript to create the TextArea. Therefore if the user disables javascript, there will be no text area. Is this the standard solution? It seems like a bit of a hack.
On the back end, what is the best way to strip out malicious code? Would I want to put some sort of validation in the create and update methods inside my comments controller? Is there some functionality built into Rails that can assist with this?
When displaying the information back out to the user, I'm assuming that I don't want to escape the HTML markup (with <%= h *text*%>), because that's how its stored in the back end. Is this bad practice?
I'm generally a big fan of cleaning out the data prior popping that stuff into the database. This is a debatable practice, but I usually lean toward this.
I use a modified version of the old white_list plugin to not strip out the html, but to convert anything I do want into a safer format.
<tag>
becomes
<tag>
This way I'm not really altering the content of the submission.
There are some plugins that specifically handle sanitization using a white/black list model.
http://github.com/rgrove/sanitize/ # Have not used, but looks very interesting
http://github.com/imanel/white_list_model # Used, not bad
There is also act_as_sanitized, but I have no real info on that.
And of course using the h().
Your suspicions are justified, but the creation of a text area in javascript won't make you any less vulnerable. A user could always use something like curl to force a form submission without ever visiting your site through a web browser.
You should assume that a user can post malicious scripts into the comments, and escape it on the frontend. Using <%= h(...) %> is one way to do it, or you can use the sanitize method in the same way. It will strip any scripts and escape all other html except for a few common tags that aren't harmful. Documentation for sanitize.
In addition to nowk's suggestions there is also the xss_terminate plugin. I have been using it in some of my applications. I found it to be easy to use, it needs almost no configuration, and has been working like a charm.
This is probably a stupid question but I'll go ahead and humble myself.
The Ruby code in my controllers and models are interpreted so that a HTML result is sent to the browser. Ok, I get that part.
But is there any way for a mailicious user to somehow take a peek at the Ruby code in the controllers and models by bypassing the process that converts or interprets that code before it is sent to the browser?
The reason I'm concerned is I am planning on doing some order processing in my app and if a malicious user was able to do that, they might be able to figure out how to do all kinds of unpleasant things.
Side tip: make sure you use html_escape or h to escape user data and prevent someone from injecting code into your site. For example, use
<%= h(person.name) %> so that someone can't put javascript in the name field and have it run when people view that page.
Nope. Try and navigate to the file yourself in the browser, you won't be able to see it. Your biggest worry should be someone trying to fake out GETs and POSTs because they know how REST works.
Assuming you have things set up correctly, then the web server in front of Rails is pointed to the /public directory. So anything in that directory may be open to direct attack. However, the web server intercepts the HTTP call based on certain criteria and redirects it to Rails for processing.
The architecture of Rails makes it impossible for model and controller code to be exposed to the public. There is a possibility that view code is viewable, but ONLY if you seriously mess up the code (I think). I have never managed to expose code to the client by accident, and I have never deliberately attempted to do so.