I trying to prevent url hacking, I passing an id to the url that the forms need, it works fine but if the user changes that value on the url it will send values to the wrong table.
<%= link_to '+ New Event',
{:controller =>'events', :action =>
'new', :company_id => company.id} %>
On the php world I used to encrypt that id ...how can I do this on rails3 or is there a better way ??
needless to say I sort of new to rails and I know a little bit of php
any help or suggestions will be greatly appreciated.
Even though this is an older question, it's a very worthwhile question. It is absolutely worthwhile to conceal the ID in the URL for, among other things, prevention of information disclosure.
For example, an application has a robust security model allowing users to only view resources to which they have rights. However, why should a user be able to look at the value of the ID in the URL and use it to deduce how many resources there are or, as the original questioner suggests, start trying to poke around with forced browsing.
The solution to this in rails turns out to be pretty simple. What I find works best is overriding to_param in the models, usually via a module in the lib directory and a before_filter in the application controller that decrypts the IDs.
For a walkthrough, have a look at this: http://www.youtube.com/watch?v=UW_s9ejrCsI
Rather than trying to encrypt or hide your company.id value, ask yourself what exactly it is that you want to prevent users from doing.
If you just want to prevent users from creating events associated with non-existant companies (by setting the id to a really high value for instance), then a simple
validates_presence_of :company
On the Event model would be fine.
If you only want users to be able to create events associated with companies that they work for, or have access for in some way, then you should create custom validations to verify that.
F
Related
I need some help with the authorization. So far I was trying to solve it with the internal rails authorization combined with devise.
I have a user who is posting a request. If this request is private only a group of "reader" can see and answer the request. (This is number one)
Then the user give a rating to the answer of the reader. This should be accesible only for the user which received the answer and the "reader" who gave an answer.
So far I was using the following to limit access to the hidden requests:
before_filter :require_reader!, only: [:open_requests]
But if the request is not hidden, than still only the reader should be able to answer the request (but all can see it). Here I do not know how to manage this. Any Ideas?
To continue... I could not manage to solve the second problem (that the rating is seen only be the one who was placing the request and the reader).
Any ideas here?
Is cancancan maybe an option?
Best
witali
What you're doing does not quite follow the 'admin' pattern that's commonly setup with tools like Railsbricks. The 'admin' permissions pattern is typically a whole set of actions/views that are available only to admins, so often the entire Controller, or family of controllers, have the :require_admin! filter applied before every single action and view. Very simple permissions logic, and it depends only on the user and view.
Instead, what you've got is views with permissions that depend on your object's state as well as the user's status and the view. So you're going to have to write your own filter to use instead of using 'require_reader!'.
For example, you might have a RequestsController, and you could add to it:
before_action :must_be_able_to_view_request, except: [:index, :new, :create]
Then define that filter in the controller:
private
def must_be_able_to_view_request
if !current_user.is_reader? && !#request.ispublic
head :forbidden
end
end
If you need to use the same filter in other Controllers, then you can define it in your ApplicationController.
I'm working on a project where users can upload videos through a simple form and additionally by FTP to a certain directory and then simply choose the file from the FTP directory instead of uploading it through the form.
I got the following, pretty standard setup for a videos_controller:
# routes.rb
resources :videos
# new.html.rb
form_for(#video) do |f|
...
end
The restful actions in the controller are all working and just standard behaviour. The upload works, that's not the problem. The problem is if I do the following:
# routes.rb
resources :videos do
member do
post :from_ftp
end
end
# new.html.rb
form_for(#video, :url => from_ftp_video_url) do |f|
...
end
I get the error: No route matches {:action=>"from_ftp", :controller=>"videos"}, because the generated route looks like this:
from_ftp_video POST /videos/:id/from_ftp(.:format) videos#from_ftp
which seems right, since it's a member route. But I don't need the :id part of the URL, since I'm creating a new Video object, not through a form but simply by using the file from the FTP directory... So it basically is another create action, that's why I would like to do it as a POST request...
So how do I tackle this the best way?
Although the selected answer is correct for Vapire's situation, it doesn't necessarily answer the title question. If you came here looking for how to get member actions without an ID because you don't need an ID, the answer is a little different.
Say you implemented authentication that sets current_user. You let users edit their own profile only. In that case users/:id/edit doesn't make sense because :id is dictated by the current_user method. In this case /users/edit makes more sense.
You can change your routes.rb file to create member actions without an id in the path.
...instead of this...
resources :user
...use this (note the plurality of resource)...
resource :user
The way to understand member and collection routes is this:
Member routes do something to an object that you have.
Collection routes do something to the set of all objects.
So when we consider what the create route would be, it's a collection route, because it's adding a new object to the collection!
So your from_ftp method should also be a collection route, because it's adding to the collection.
Also, you might want to consider if you can accommodate the FTP functionality within your existing create method - it might be neater.
This is an incredibly newbish question, but I can't seem to find the answer.
I'm building an app that utilizes external APIs heavily, and I'm fairly new to Rails, so it's still a little rough to get around. I can't, for the life of me, figure out how to accept user input and execute a function in my app without writing to a model.
For example, I just want to let a user type in a Twitter username and have it display on the page. I know how to make a form to cache the search in a model, but I can't figure out how to just... make a function happen on a page. I've been breaking my brains on this for several days now.
Please help? :/
You don't need a model to use Rails, but if you don't need ActiveRecord at all, you might benefit from a lighter framework like Sinatra. That doesn't answer your question, but it's worth thinking about if you really have no database requirement for your application.
It sounds like you're just trying to access non-resourceful user input, which is accessible in the controller via the params hash. So, assuming you have set up a valid route for the form action, you use your controller to extract GET or POST parameters.
For example:
# You define a non-resourceful route in routes.rb for your form action.
get 'twitternames/show'
# Form action directs user to GET the following route after filling in the form.
http://example.com/twitternames/show?user=foo
# The controller action extracts the data.
def show
#user = params[:user]
# render the view unless you tell rails to do something else
end
# show.html.erb
<%= #user %>
Creating the right route is the key. Once you've defined a route that can break a URL into the proper segments, the rest will fall into place.
Back-end: I have a model (User) that has_many of another model (ContactPreference).
Front-end: An interface allowing the user to reorder, add, and delete contact preferences for a particular user.
I'd like to let the user commit all their changes all at once with a single form submit. The way I'm doing this now is with allows_nested_attributes_for :contact_preferences in the User model, and naively POSTing the attributes of the edited preferences list. It works just fine except for a glaring bug: If a user deletes a contact preference, the ID simply isn't sent, and the preference doesn't get deleted from the DB.
allows_nested_attributes_for has support for deleting objects from the collection, but it requires the client to keep track of what IDs were deleted and pass a '_destroy' => 1 parameter. This is messy logic that I'd rather avoid; I just want objects deleted unless they are explicitly included in the parameters. allows_nested_attributes_for doesn't support this behavior as far as I can tell, so I'm looking to implement my own solution.
What's the most efficient (in terms of database access) way to do this kind of update? Do I delete everything and rebuild the list from scratch? Do I load the association and pick out objects that aren't explicitly included? Perhaps there's some clever ActiveRecord magic I can use?
My personal feeling is that doing this using the :destroy => 1 flag set a lot less messy than the alternative. The alternative would be loading the association on the server, comparing the incoming parameters, figuring out which records are missing, then deleting the missing ones and updating the remaining ones. That's a lot of extra logic, DB operations, and worst of all, you'll have to hand-rework the accepts_nested_attributes_for which is a non-trivial feat.
HTML give you a little trick/hack to accomplish this without JS. Add a checkbox to each record with name :destroy. Use the high-level form helpers, e.g. check_box, not check_box_tag (which requires a lot of things to get right manually), or a higher level form helper such as the simple_form gem.
If the flag is not checked, then HTML won't submit anything, and the record stays. If the flag is checked, HTML will submit the :destroy flag, and it will be deleted with the built-in server-side mechanisms out of the box.
You didn't say much about your front-end code; it sounds like you have a bunch of JS on there. You probably hide the record when the user "removes" it, you can simply add the destroy flag programmatically in that case, if you don't want to use the check box method above. This will be a lot simpler and less error prone than trying to second-guess the backend behavior.
I've used CanCan before and it's great, but sometimes I don't need such customizable role management. Sometimes I just need to distinguish between an admin and everyone else. So, I usually just write an :authenticate_admin! method for the controllers and methods I need to protect.
What I've found a little more complicated is ensuring that users can only manage resources they own. Say, I user can create posts, I don't want them to be able to update or destroy a post they didn't create. So, I'm curious about how others have gone about handling this in the most DRY way possible.
Here's what I've done, off the top of my head:
In the application controller:
def user_can?(resource_user_id, current_user_id)
return true if current_user.is_admin
return true if resource_user_id == current_user_id
end
Then, in the controller in question, I do something like
before_filter :can_manage_project?, :except => [:new, :create]
and
protected
def can_manage_project?
#project = Project.find(params[:id])
return true if user_can?(#project.user_id, current_user.id)
redirect_to user_path(current_user), :flash => {:error => "Sorry, you're not allowed to do that."}
end
Seems like a lot of code for a relatively simply task. How have you gone about handling this task? I'm sure there's a more elegant solution -- short of using a gem or plugin.
My first thought would be to abstract out a tiny bit and mix in an is_manageable? method into models via a acts_as_user_manageable-type doodad. Resource controllers would get a manageable_by_current_user? filter (I'm not sure how I'd do that automagically yet). is_manageable? could encapsulate arbitrary rules, so it would be able to handle things like admin flags etc.
I'd have to play a bit to see what implementation I liked the most, but a solution like this seems pretty reasonable, and probably something that a lot of people would dig for projects that don't need the level of control the canonical solutions provide.