Im not sure if what I want to do is possible or even makes sense, basically I want to use a rails application that server a API and has a web component as well.
My plan is to have some sensors send POST data (from some Raspberry Pi Zero's) to this rails backend. I want to also be able to GET sensor data in JSON form from the backend api via some sort of nice URL (GET sensor_id/temp or something).
However I also want to be able to have a sort of dashboard that displays values over X timeline for instance.
At that point, does it really make sense using the new rails 5 API addition (--api when making a new rails project) or should I actually separate it into 2 separate backends? (Feeding one into the other)
Yes this is possible. You would define your controller action like this:
def index
#people = Person.find(:all)
respond_to do |format|
format.html do
#do some html specific stuff here
end
format.json { render :json => #people.to_json }
end
end
Related
As i mentioned on the question title, I want to know the best approach to get this to work and i'll need and example ( very simple one as the follow: )
Let's say i have an API which has 1 controller and 1 action for example simplicity
root 'main#index'
and inside the index action i have
def index
#date = Data.today
end
Then i have another rails app which will work for front-end rendering
How can i pass this #date as JSON from the API to the other app to render it ?
Should i have same controller on the other app ?
How can i connect and send http request and receive response ?
Thanks in advance
For such a simple example, you can do something as simple as:
def index
#date = Date.today
respond_to do |format|
format.json #date
end
end
However, you're most likely going to want to deal with more complicated JSON responses, so before long you'll probably want to use something like the Jbuilder gem or ActiveModel Serializers (my preferred approach).
On the other end, your front-end will need to make an HTTP GET request. Lots of ways (and gems) to do this, but one common approach is just to use the built in Net::HTTP class.
require 'net/http'
url = URI.parse('http://backend.dev/main/index')
request = Net::HTTP::Get.new(url.to_s)
response = Net::HTTP.start(url.host, url.port) do |http|
http.request(request)
end
raise response.body.inspect
In your situation, a better approach might be to use the Active Resource gem. This gem allows you to create models that are backed by a REST API rather than a database. For example, if your API app provides basic Create-Read-Update-Destroy actions for a particular model (let's call it Widget) at the following URLs:
GET http://backend.dev/widget # listing of widgets
GET http://backend.dev/widget/1 # Read for widget id: 1
POST http://backend.dev/widget # Create new widget
UPDATE http://backend.dev/widget/1 # Update widget id: 1
DELETE http://backend.dev/widget/1 # Destroy widget id: 1
then in your front-end app you could declare an Active Resource like this:
class Widget < ActiveResource::Base
self.site = "http://backend.dev"
end
which will auto-magically access all of those methods in your API, and behave much like a regular Active Record model. That way, you basically design your front-end app like a "normal" rails app, but using ActiveResource-based models in place of ActiveRecord.
I would note, however, that a more common thing to do these days would be to build your API in Rails, and build your front-end with client-side Javascript, using something like JQuery or Angular to make requests from the API. I'm not sure what you're gaining by splitting API and front-end, where both of them are Rails apps - unless you've got a compelling reason, I'd just build one Rails app that handles both API and front-end, or build a Rails API + Angular (or similar) front-end.
I'm writing a rails application with an AngularJS front-end, this is part of a tutorial series I'm writing on connecting rails and angularjs. This means my rails application communicates with the browser exclusively in JSON.
In the angularjs $http documentation it describes a potential json security vulnerability where the json request can be embedded into a script tag, plus some tricky use of jsonp, to allow something akin to a cross-site scripting attack. I've found a few other pages, one in particular I thought described this well, and dates from 2008, so this isn't a new issue.
Apparently this isn't a vulnerability in standard rails json rendering, as rails by default provides back an object containing an array. But when working with angularjs we appear to set root: false (although I have to confess I can't find where I did that, but it's definitely not giving the root node).
Anyway, the bottom line is that the angular documentation recommends prefixing any json response with )]}', so:
['one','two']
Becomes
)]}',
['one','two']
Angular then automatically strips that off again.
I'm looking for a way to do this elegantly. I've seen a lot of questions and answers on stackoverflow about this, but most of those either relate to much earlier versions of rails before JSON handling was more thoroughly embedded, or seem to require me to create a lot of boilerplate code. I'm looking for a method that I can apply to the application controller, or as a helper method, that will work everywhere.
The controller that I'm currently using looks as follows:
class ClubsController < ApplicationController
respond_to :json
# GET /clubs.json
def index
#clubs = Club.all
render json: #clubs
end
end
This doesn't call any templates - the render action skips the templating engine. I can get this working by changing the render line instead to:
respond_with json: #clubs
And creating a template file views/clubs/index.json.erb that contains
)]}',
<%= raw(#clubs.to_json) %>
But I'd then have to create a template for every action on every controller, which feels like boilerplate. I'd like instead to be able to change views/layouts/application.json.erb to have something like:
)]}',
<%= yield %>
But that doesn't work because we only get templating if we call respond_with. And if we call respond_with, we have no way to put the #clubs into the response - so we end up with:
)]}',
As the entirety of the response.
An alternative would perhaps be to override the as_json method to prepend what I want, but that seems a bit like a sledgehammer. Ideally there would be a place I could introduce a helper method, something like:
render prepend_vulnerability_protection(json: #clubs)
So, after all that, two questions:
Is this even a real problem, or does Rails already have some other protection that means I don't need to worry about this at all
Is there a way to do this centrally, or do I need to bite the bullet and create all the boilerplate templates? I can modify the scaffold generators to do it, so it's not the end of the world, but it does seem like a lot of boilerplate code
So, no responses as yet. I'm going to write down what I find from my research, and my current answer.
Firstly, I think this is a genuine vulnerability in rails. Unfortunately the rails and JSON/JSONP area has had some other recent vulnerabilities relating to the JSON parser at the Rails end. That has really drowned out any google search relating to this specific XSS issue.
There are a couple of approaches to resolving this:
Have your application only respond to put/post/delete requests. That's not really an option when integrating to Angular - well, it is, but it means overriding a bunch of standard behaviour
Insert something at the front of your returned JSON - this can be the root node (default rails behaviour in rails 3, no longer in 3.1), a closure like )]};, or a loop like while (1);. Angular expects and can deal with )]}',
I've looked at using a json template in my rails app. You can do this with one of many gems, the one I like the look of is JBuilder (railscast 320), but RABL is perhaps more powerful (railscast 322).
This does mean a template for each of the actions on each of the controllers. However, I've also just completed working out how to have rails scaffold those for me automatically, so it's not as scary as it was when I first asked the question, and I can see some other reasons that I might want more control over the json that is returned from my application.
Having said that, I couldn't immediately see a way to get JBuilder to prepend an arbitrary string - it seems to only want to prepare valid JSON (and this I think is not valid JSON). RABL looks like it can do it, but it is a bit more complex. It can definitely be done through just using ERB, but I feel kinda wrong in doing that.
The other alternative I've identified is a helper method in application_controller.rb, which I then call in each of my controller methods. This is reasonably elegant, and I can quite easily change my template to do it. So I'm going with this for now:
class ApplicationController < ActionController::Base
def render_with_protection(json_content, parameters = {})
render parameters.merge(content_type: 'application/json', text: ")]}',\n" + json_content)
end
end
class ClubsController < ApplicationController
respond_to :json
# GET /clubs.json
def index
#clubs = Club.all
render_with_protection #clubs.to_json
end
# GET /clubs/1.json
def show
#club = Club.find(params[:id])
render_with_protection #club.to_json
end
# POST /clubs.json
def create
#club = Club.new(params[:club])
if #club.save
render_with_protection #club.to_json, {status: :created, location: #club}
else
render_with_protection #club.errors.to_json, {status: :unprocessable_entity}
end
end
end
Note that you should be also including CSRF protection in your application controller - so see this as additive to the security precautions you were already taking, not a replacement.
I am trying to set up a graph like this http://bl.ocks.org/4063269#index.html with d3.js:
I need to do this by putting methods in a controller and the js in a .html.haml file. I have made the controllers, but have absolutely no idea how to write the methods.
The methods need to take values from a sqlite3 database and convert it into JSON for the d3.js to use. Could someone get me started? I have no idea what to do right now...
Unfortunately the question you are making is too open, with more details you will get more help ;)
So the javascript library is going to make ajax call to your application, and your application should respond with json?
In that case, you can just do the routing on config/routes.rb, and then you just write a method like this:
class MyController < ApplicationController
def values_for_js
my_data = MyModel.calculate_data
respond_to do |format|
format.json { render json: my_data.to_json }
end
end
end
And your js should request something like http://mywebsite.com/values_for_js.json (or it can say in the ajax request that a json format is expected). If you are not able to make the json request, you can just use format.js instead of format.json
Please explain why do we need this code in a controller? What is the significance of this block of code?
respond_to do |format|
format.html # index.html.erb
format.json { render json: #users }
end
It allows you to format output differently depending on the format the user/caller requests. If you were to access http://yourhost/controller/index.html, the controller would respond with the ERB template index.html.erb (or HAML or whatever). If you were to access http://yourhost/controller/index.json, it would respond with the JSON template index.json.erb.
This allows you to have a single controller action that can prepare data and then select the view for rendering based on the requested format.
Defines mime types that are rendered by default when invoking respond_with.
So basically, this means that your controller action can be hit in different formats(html, json in your case), and still provide data back to whatever is calling it. This is helpful for API development, and many other things.
For example: You want to get a json list of all your users to do something with javascript. You'd call /users.json and this would go to your user_controller#index action and know to render a json object of all your users.
The above code is scaffold generated, and provides a way to render *.html and *.json views for your controller, making it easy to have access to data for implementing an API or normal views for your web application.
You can also create XML output:
format.xml { render xml: #users }
and other formats like PDF, or DOC, depending on the gems you are using.
See the Rails Guide Action Controller Overview for more information.
What is the best practice for excluding certain fields/data in a RESTful response if the user requesting it shouldn't be able to see all of the data?
Example:
Person has a First Name, Last Name, and Date of Birth.
Both authenticated and non-authenticated users can make RESTful requests to /people.xml to get a full list of people. However, only authenticated users should be able to view all of the information. Non-authenticated users should only have the First and Last Name fields returned (excluding the Date Of Birth data).
Should the Person controller check for authentication before building the response? If user is authenticated they get everything, else they only get a subset? Does that break any rules of REST where /people.xml can send two separate results?
No, that's fine. It's the same resource, but with a different representations based on the authentication information. You could also serve different versions depending on what the Accept header contained (you should use that one instead of file extensions like .xml, by the way), or you could serve different language versions, or you could render the page different if the logged in user has specific personalization options defined. It's all legal. Consider a website that has a login box. If you're logged in, the page will be different. That's the same thing, except it doesn't specifically affect the enclosed information per se. Controlling caching and so forth in these cases is exactly what Cache-Control, Vary and friends are for. Also see http://www.subbu.org/blog/2007/12/vary-header-for-restful-applications
The same URL can yield different representations, depending on the request-headers. For example, Accept is commonly used to control the format of the response (f.ex. XML or JSON). Likewise, authentication-headers could be used to control how much is returned for an entity.
You can use the :only option of the to_xml method to restrict the fields returned by the controller, i.e.:
def show
#person = Person.find(params[:id])
payload = current_user.nil? ? #person.to_xml(:only =>
[:first_name, :last_name, :dob]) : #person
respond_to do |format|
format.xml { render :xml => payload }
end
end
I use serialize_with_options plugin, as most of the view data access configuration can be done at the model level.
class Person
serialize_with_options(:anonymous) do
only :first_name, :last_name, :dob
end
end
class PersonController
def show
#person = Person.find(:params[:id])
respond_to do |format|
format.xml { render :xml => current_user.nil? ? #person.to_xml(:anonymous):
#person }
end
end
end
Reference
1 serialize_with_options
Consider that different representations of the same data (depending on the user) could have surprising consequences if you have a cache somewhere in the middle. If the fully authenticated user makes the request first, then followed by the 'lesser' user, they might see surprising result: The same view as the fully authenticated user before. That's because there is no difference in the two requests as far as the cache is concerned (unless you make it aware of these issues). So, tread carefully.
I would also suggest separate namespaces, as proposed by Robert.
By the book, REST says that one resource should return the same result every request.
I would create a namespace with "unauthenticated" or something and make
/people.xml for authenticated
and
/unauthenticated/people.xml
They could be the same controller building different xml results for each request.