I am wondering about the difference between 301 and 307 redirects.
I am looking to generate backlinks through a home-brew url redirector, and I wish for any of the "link juice" or "page rank juice" to flow directly from the originating back page through to the final URL, but if one of the originating back pages goes bad, I'd like to be able to shut that link off by deleting the redirect link for that particular page. Make sense?
My understanding is that 301's are permanent meaning that google will see the 301 and update its cached URL as the final destination, regardless of whether I kill off that redirect at a later time.
If I use a 307, it won't cache the destination URL and will keep checking the redirect URL to see where the back link actually points to, and if I kill off the redirect link, Google will no longer assign that back link to the destination URL.
Is this a correct summary?
It's correct. Actually 307 is variation of the more common 302 redirect
301 Moved Permanently This and all future requests should be directed
to the given URI.
307 Temporary Redirect (since HTTP/1.1)
In this case, the request should be repeated with another URI;
however, future requests should still use the original URI.
Related
I have an app where I try to adhere to REST.
The app receives requests for external links that don't belong to the app, so the sole purpose of the action is to redirect the request to the external URL.
My suggestion is to have the following controller/action: redirects_controller#create.
Is my thinking correct or should it be the show action instead?
REST (apart from Rails) is about using the correct HTTP method for the correct action. The Rails part is just using the conventional controller action for a given HTTP method.
So, if you're doing a 301 or 302 redirect to another page, which browsers handle by issuing a GET request to the URL in the redirect response's Location header, do it in a show action. This will allow the user's browser to cache the other page when appropriate, and to not notify the user before redirecting.
(There is a way to redirect POSTs, but you didn't mention it so I expect you're talking about regular 301/302 redirects.)
Coming from a Java background, the REST actions must be related to CRUD operations. Requests that do not change the resource like in your case where the intent is to redirect to another page must be tied to a GET verb or show in your example.
If you were to create a new resource you would use POST.
A more detailed explanation can be found in Richardson's rest maturity model level 2
I have an HTTPS post coming in via a secure form. Without going into lengthy explanation: I need to call an action within the same controller that accepts two tokens passed as parameters. When I run Fiddler, I see that that method is being called with the parameters in the URL. My question is: Does this pose a security risk? Is there a more secure way of redirecting within the same controller?
Yes, it poses a security risk, but it is easily mitigated by simply validating that the urls you are redirecting to are within the same domain as your source destination.
In fact, this is on the OWASP top 10.
A10 - Unvalidated Redirects and Forwards
EDIT:
I just realized that I missed the "ToAction" part of the question, so no.. It's not really possible to redirect outside of the site with RedirectToAction, so there isn't a worry for that. However, if you are using direct user input to feed into your RedirectToAction (and that includes accepting post data that you generate in a different page) then it's possible that an attacker could redirect to a method you did not anticipate. However, this is no different from a user simply trying random URL's and hitting one, or knowing a url and going to it manually. You need to have authorization in place to prevent access to URL's that the user does not have authorization to view.
If the original Action is accessed via HTTPS then RedirectToAction will redirect to a relative URL on the same domain using the same protocol.
So if your original page is
https://www.example.com/Foo/Bar
and this redirects to the FooBar action with some route parameters:
https://www.example.com/Foo/FooBar/1/2/3
an attacker cannot read the parameters 1/2/3 nor the rest of the URL.
However, the things you should bear in mind are:
The URL parameters will be logged by default by the browser (history), your server, by corporate proxy servers and possibly by other devices on your network by default.
If the user follows any links from your page to other https URLs, the referer HTTP header will contain your page address including parameters. Modern browsers will not send the referer header with http links though.
If there are any other https resources on your page this will cause the browser to send the referer header with the request.
For these reasons, if your parameters (1/2/3) are private, then you may wish to POST this data to the target page rather than use RedirectToAction (which results in a GET).
Note that you should be validating that the current user has access to the resources that 1/2/3 refers to (e.g. if the parameters were an order ID, you should check that the user identified by their auth cookies allow them to see the order referenced). Keeping 1/2/3 private are only beneficial if the parameters are themselves sensitive (e.g. a social security number).
Note that the OWASP Top 10 vulnerability, "A10 - Unvalidated Redirects and Forwards" does not apply here as RedirectToAction can only redirect to another action. If the other action redirects to a user set URL, then the vulnerability would lie there instead.
Given I use an CMS which makes an article available unter the following URL: http://example.com/article/1-my-first-and-famous-article/
Internally I can identify the requested article unequivocally by its id (1).
How should I handle requests to a wrong (typing error, manipulation, ..) URL? For example someone requests http://example.com/article/1-my-firsz-and-famous-article/ or http://example.com/article/1-this-article-is-stupid-idiot/ - should I respond with http status code 301 and redirect to the right URL or with 404 and show a not found page (maybe with redirection after a few seconds). Which is the preferable way in terms of search engine optimization?
Wrong URLs will be 404 error and any existing page moved to new location will be 301 redirect
Whats difference between Redirect() and RedirectPermanent(). I had read some articles, but I don't understand when we must use Redirect() and RedirectPermanent(). Can you show a pieces of example.
The basic difference between the two is that RedirectPermanent sends the browser an HTTP 301 (Moved Permanently) status code whereas Redirect will send an HTTP 302 status code.
Use RedirectPermanent if the resource has been moved permanently and will no longer be accessible in its previous location. Most browsers will cache this response and perform the redirect automatically without requesting the original resource again.
Use Redirect if the resource may be available in the same location (URL) in the future.
Example
Let's say that you have users in your system. You also have an option to delete existing users. Your website has a resource /user/{userid} that displays the details of a given user. If the user has been deleted, you must redirect to the /user/does-not-exist page. In this case:
If the user will never be restored again, you should use RedirectPermanent so the browser can go directly to /user/does-not-exist in subsequent requests even if the URL points to /user/{userid}.
If the user may be restored in the future, you should use a regular Redirect.
RedirectPermanent is 301 and Redirect is 302 status code
They send different response codes to the browser. 301 is a permanent redirect, 302 a temp one. The end effect is the same, but if the client wants to index links (the most common client that does this will be search engines) then a permanent redirect tells the client to update its records to ignore the old link and start using the new one. A temp redirect tells the client that the page is redirecting for now, but not to delete the old link from its indexing database
I am trying to track the url that refered my website. One way is using a custom affiliate url which will do a redirect (302) to my site. I want to track where the users are coming from. However, I realize that after redirection, the HTTP_REFERER fro the header defaults to '/' when I was expecting it to be the url where the user was redirected from. Does the HTTP_REFERER header gets deleted after redirection? If yes, is there a way to store this information.
I am using rails for my website and I am doing request.referer to get the HTTP_REFERER.
Referers are not guaranteed; they are completely optional and any number of things could be stripping them.