I've created a task management app that consists of lists and tasks. Users can only view their own lists and tasks. I would like to add the ability for a user to share a list if they like. Here are the steps I would like to accomplish:
User clicks a link from /list/show to share the list
User receives a secret URL to share: myapp.com/lists/1/23534512345234523 or whatever.
Secret URL redirects to a view other than /lists/show. Something like /lists/1/23534512345234523 which would be routed to /lists/secret_show or whatev.
Only users who have that url can see the information on that page.
Hope that is making sense. I imagine I would have to update the list record with a unique token to list.token. Then I would some how have to recieve the incoming URL and through a new action
lists#secret_share
def secret_share
...
end
Where I filtered for the list record by list.token and routed to secret_share. Then perhaps in the view I could simply restrict the view by the presence of the token in the URL.
Thoughts?
Whatever "secret URL" you hand out should not redirect to the real URL or you're going to create all kinds of opportunities for information leakage. It should be a strictly alternate URL.
Using routing for this seems like a good idea instead of using a separate controller. In your route you might want to pass an additional parameter to indicate this is a "secret" URL, like :secret => true where the value in question is something that cannot be submitted by the user to fake things out. User parameters are always strings, for instance, so using true should be a safe alternative.
This special parameter might disable access checking on your controller so that the page can be viewed by people that don't normally have access. You could also show a different layout using the layout method in your controller.
Related
I'm working on REST API, and I trying to understand whether this looks legit in terms of REST.
I've players which using some mobile app with a login mechanism,
So the question is, if the player needs to update some attribute on his resource,
How the URL & PARAMS should looks like:
Option #1:
PUT /api/players/59/
PARAMS { some_attribute: "some_value" }
Option #2:
PUT /api/players/self
PARAMS { some_attribute: "some_value" }
The thing is, that the player doing the call with authentication, so it looks odd that he needs to send his id, it feels like he can send update on some other id, so when he sends 'self' it looks more suitable but uglier.
What's the REST point of view here?
Or maybe another option?
You should use first option
But in first option, request additional parameter like authentication_token
to verify the user and user is updating his information only.
This gist will help you in authenticating user
https://gist.github.com/josevalim/fb706b1e933ef01e4fb6
It shows 2 method for authenticating user while communicating with API
I use require_admin! frequently in my controllers. It works great.
Now, I want to add named route like so:
# config/routes.rb
match "poniesandrainbows" => redirect("https://poniesandrainbows.com")
# ^sadly, not really a website, btw.^
How do I restrict access to that route? Is this possible? Obviously it redirects to a public URL, but I still want to keep the route private.
You cannot restrict access from routes.
The safest way to match "poniesandrainbows" with a controller where you can use require_admin! and then redirect them to the public url.
You can try to solve the problem on the front end. Maybe only show the link to admin users.
It won't stop other users to paste the link directly to their browser url though
That kind of functionality should be encapsulated in the controller. The router handles the plumbing of passing a request to the correct controller. It is the controller's job to correctly figure out how to process the request. In this cause, the controller would use the auth service (such as require_admin!) to determine if the user is allowed to be redirected or if they are doom to another fate.
It is actually possible although as the other posters mentioned very rarely a good idea. You can read about how in this blog post: (scroll down to the routes section)
http://collectiveidea.com/blog/archives/2011/05/31/user-centric-routing-in-rails-3/
I'm building a referral program for my Ruby on Rails app, such that a user can share a link that contains their user ID (app.com/?r=ID). If a referrer ID is present when a visitor lands on app's homepage, the signup form on the homepage contains a hidden field that populates with the referrer's ID. The controller then detects the ID and creates a new referral in a referral table if the referred visitor signs up. It works, and here's that chunk of code:
#referrer = User.find(params[:r]) rescue nil
unless #referrer.nil?
#referral = Referral.new(:referrer_id=>#referrer.id)
end
Pretty simple stuff, but it's pretty easy to break (ex: if visitor navigates away from the homepage, referrer ID is lost). I feel like cookies could be a more robust method, where a cookie containing the referrer's ID is stored on the referred user's computer for x days. This is pretty commonplace, especially with affiliate programs like Groupon, but I have never worked with cookies and have no idea where to start.
Also, is there any good way to mask or change the URLs of the referral system? Instead of having app.com/?r=1842, I would prefer something like app.com/x39f3 <- a randomly generated sequence of numbers associated with a given user, without the ?r= portion.
Any help is greatly appreciated. Thanks!
To answer the cookie question, it's quite easy to set them:
cookies['app-referrer-id'] = params[:r]
And then it's the same format to read them back (but without the assignment). I would suggest putting this code in a before_filter in your application controller. This way, the cookie will be set irrespective of the page on which your visitor first lands on your site.
With regards to changing the structure of the urls to the suggested format, you would need to have the referral codes match a specific pattern, otherwise you are likely to run into routing problems. If, for example, they matched the format of 3 letters followed by three numbers, you could put the following your routes file:
match '/:referrer_id' => 'app#index', :constraints => {:referrer_id => /[a-zA-Z]{3}[0-9]{3}/}
The reference to app#index should be changed to the controller in which you handle referrals and you can access the referrer_id through params[:referrer_id].
Hope this is of some use.
Robin
I am new to RoR and started working on a typical 'has_many' association (ie. a user has many friends). I have everything working correctly, but I don't like having the ids exposed in the url. I find that I need to add extra validation in my controller to make sure the ids represent valid associations in case the user manually entered different ids.
Personally I would like to see the ids out of the url and passed via some other means but that is not always possible. Shallow nesting of resources will help reduce the number of ids I need to validate at least.
What is the RoR philosophy on this? I have not seen anything specific to this issue.
Thanks
the URL has parameters if it is a GET url.
Try using POST parameters, which means your url will no longer be cluttered. Note that a malicious user can still send a made-up POST request using curl.
My approach to this is implementing proper authorization. If the user requests information for an object he is not permitted to read, this should be handled by an authorization framework.
With CanCan or Declarative Authorization you can define rules that replace your "manual" (and error-prone) checks in controllers.
I like the IDs being in the URL. That is what REST is about. Getting information for specific Resources, which have to be identified with an ID.
You can use Friendly ID in order to replace the integer ID by a slug (e.g. users/tollbooth instead of users/42).
basically ror routes by default takes id as key to generate urls. If you are not fan of id based urls then you can always override urls by using to_param inside model.
def to_param
# make sure this field is always present & unique
username
end
then by default you will start seeing username instead of id inside urls
How to find object inside controller actions
User.find_by_username(params[:id])
If you dont want to do this manually make use of slug gems like friendly id
I have the following restful structure:
My login page uses the session/new action
My signup page the users/new action
My logout page uses the session/destroy action
My register process uses the users/create action
I need 3 more actions for:
I forgot my password page
Start forgotten password action (send email)
Reset password based on token
Where do these 3 actions fit in a restful world?
To clarify:
I know I can create whatever actions on my existing session and user controllers (eg. a reset_password get action or a start_reset_password post action) it just doesn't really sit right, it seems I am trying to make these controllers do too much work.
REST is not black magic. Figure out what your technical goals are for these pages, then pick the right verbs to go with them.
I forgot my password page: essentially a static form, right? You want this to be cachable. GET on any URL you want.
Send email: costly action which you don't want repeated and you DO want executed every time the user requests it: POST or PUT on any URL you want. Heck, you could make it the same as the above URL if you wanted to, but I don't see a particularly pressing need to.
Reset password based on token: I'd consider implementing this as a login-via-token instead, but if you're going to do it your way, then it has server-side consequences and hence should probably be a POST or PUT.
I ended up creating a new controller called forgotten_passwords, to control the process
forgotten_passwords - new : maps to I forgot my password page
forgotten_passwords - create : maps to start forgotten password action (send email with token)
forgotten_passwords - show : maps to the end of the process (a page where the user sees her new password)
I am pretty happy with this design. I think it called for a new controller.