I have posts, where users able to delete or edit them. And when I redirect them I was sending url with id number, like: test.dev/delete/15, where 15 is my id of post which should be deleted. Then I tested sending id in route like route('delete',['id' => $post->id]). In the end I realized that both methods include id number in url. I mean, for url it shows url test.dev/delete/15 and for route it shows test.dev/delete?id=15
So I was wondering if we can send id, without showing them in url, I am afraid that curious users may try to get use of these flaws
As you will always have to display the id somewhere on the page to send it through either a hidden field or id in the url all of which a user can change. That is why you should check in the Back-End if the user has privelege to delete that post or not
Related
I am new to RESTful URLs and I have a general question. Let's say I have a URL that I use to retrieve student records: somesite.com/students/123 which retrieves the details for the student with ID 123.
I then do the following to load an empty form for adding students: somesite.com/students/0 where zero indicates that I want to display an empty student detail form (or somesite.com/students/new).
The question I have is that after I add a student record I get back a new Id. However, if I add the record using AJAX without submitting and refreshing the page, my URL still shows somesite.com/students/0. If a user clicks refresh then the empty form is displayed again rather than the new student record.
How should that be handled?
It's not like your server can't respond to AJAX requests, right?
All you need to do is send back the newly generated ID, and then:
Use window.location = 'new_url' to redirect the user
Or even better, use history.pushState() (if available) to change the URL without any redirection (and reloading) happening at all
One thing that seems off, though, is the use of GET page/students/0 to get an "empty record", or, as I understand it, a "template" for new records. I don't think that's how RESTful services work, but then again, I'm not an expert in REST services.
I am sending email to user, in that email one link is there to redirect that user to rails application. I want that link to be in encrypted form with domain name for example:
https://www.domain_name.com?hdurstihnzdfalgfgdfhdrbnhduolsasrtyumyrtyr
when user click on this link, he should directly redirect to controller method we specified in that URL which is not visible.
Controller and methods given in URL may vary according to user.
So my question is how we can do this in rails.
If I encrypt controller name, method name and parameter we passed. How routes file come to know where to redirect this URL? How to decrypt this in routes file and redirect internally to decrypted URL?
Life will be easier if you can do a slight modification to your url, something like:
https://www.domain_name.com/enc/hdurstihnzdfalgfgdfhdrbnhduolsasrtyumyrtyr
Then you can create a route for that path to redirect where you want.
get '/enc/:encoded_path' => "controller#action"
This would give you access to params[:encoded_path], which would equal hdurstihnzdfalgfgdfhdrbnhduolsasrtyumyrtyr in this case. From there, you could decode in the controller and then redirect however you want.
That's not the right approach. Here's what you can do instead:
Create a new controller action, say for instance, activate.
def activate
activation_token = params[:auth_token]
....
your logic to do whatever with this token
end
Create a corresponding route:
match '/activate' => 'your_awesome_controller#activate'
Now, when you email your users, I'm guessing you're sending some sort of activation token. If not, create two new fields in your users table:
activation_token:string
activated:boolean
Use some unique string generation algorithm to generate your activation_token and email it to your user:
yourdomain.com/activate?auth_token=user.activation_token
I have a SPA (single page application) so it uses AJAX extensively for getting and saving data to and from the server. In one case I allow the admin to view/add/edit/delete users. Some current urls for this area looked something like:
(GET) /users?userId=1 // get user with id of 1
(POST) /users?userId=1&firstName=Jim // update the first name of the user with id 1
(POST) /users?firstName=Bob // create a new use with the first name Bob
(POST) /users?userId=1&delete=true // delete user with id of 1
Having spent some time working on a RESTful API in a related project, I'm wondering if it's preferred to use HTTP types (GET, POST, PUT, DELETE) in a web app as well. Also, is it better to use a path parameter for user id instead of a query parameter? So are these urls (rewrite of the ones above) a better option in the long run:
(GET) /users/1 // get user with id of 1
(PUT) /users/1?firstName=Jim // update the first name of the user with id 1
(POST) /users?firstName=Bob // create a new use with the first name Bob
(DELETE) /users/1 // delete user with id of 1
In theory yes you should. You should be as RESTful as possible which means using HTTP semantics to their fullest. However the reality is a bit more murky, several older browsers, I don't need to name names, don't support anything but GET and POST. So the current recommendation until those browsers go out of support, or until you drop support for those browsers, is to have backup methods that do the same thing but on POST, usually with an extra parameter or segment in the url.
I'm using Azure ACS in my ASP.net MVC 3 website (hosted in Azure too), the scenario is this:
A user first enters my website and fills a one field form, then they need to chose a provider and login, but first I want to store the field value so when they come back from login I'm able to create a profile with this value for the loged in user.
So I believe when they first enter the site and then leaves to login and enters the site again those are two different sessions am I right? and that's the reason the stored data using session state (through SQL Server) is not present when they come back after login am I right? if this is true what would be the best approach then? if not then I'm doing something wrong storing temp data right?
Thanks
UPDATE:
I have discovered that HttpContext.Application state works keeping the data, still I'm not sure if it's a good idea to use it in a controller considering it's in Azure, will it work on production properly??
You can pass state around in the WS-Federation redirect sequence using the wctx URL parameter. In the action that handles the initial POST request, you should get hold of the form parameter you want to keep, then redirect to you identity provider selection page (this will have to be a custom page) with the form parameter appended to the URL. When the user selects an IP on your page, you can pass the parameter on again using the wctx parameter. The WS-Federation passive requestor profile says that this should be returned to you eventually when the IP redirects the user back to your site.
This has some details
http://msdn.microsoft.com/en-us/library/bb608217.aspx
Edit: To get the wctx parameter out of the request when the user finally comes back to your app. Put something like this in the action code:
var fam = FederatedAuthentication.WSFederationAuthenticationModule;
if (fam.CanReadSignInResponse(System.Web.HttpContext.Current.Request, true))
{
string wctxValue = this.HttpContext.Request.Form["wctx"];
}
My preference is to have the wcxt parameter represent a redirect URL (URL encoded) with your parameter as a query parameter in that so it be a URL encoded version of this:
wctx=https://yourserver/yourapp/yourpage?yourparameter=foo
Then the action that was receiving the redirect from the ACS would simply pull out the value of wctx and do a redirect to it without any more processing. This keeps things simple.
Another approach would be to save whatever data you need to pass around in the Database, and just pass around some ID that refers back to the database record. You'll pass this ID to IP and back through wctx (as Mike mentioned above).
This will solve the issue of limited length of URLs (in case your data is very large). Of course you would need to manage deletion of this data, but this shouldn't be hard.
noob question. when I pass an id in the route to query my DB, is there a way to prevent the actual id from showing in the URL in browser.
If not, is there a way to prevent the user from changing the id in the URL and access other information?
Some sort of validation you get from clicking the link on the previous page or something.
I hope this make sense.
You could retrieve your record with an hash instead of the id directly.
You can use package like https://github.com/mitchellvanw/hashids (there must be some others)
Also, if you just want to hide it, you can POST it to your page. Don't forget that users can still change the form informations.
U can use base64_encode() and base64_decode to hide url from users and preventing them to change.