Does anyone know if there are any particular circumstances when the [HttpGet] attribute gets ignored?
I have a controller that has an action with the [HttpGet] defined on it, which should mean that only GET requests are allowed and POST requests are rejected usually with a 404. Running locally under IIS this action seems to be able to accept Http POST requests however on the Test server this is not the case which is how it should be. It looks like we do need to be able to support POST request on the controller actions and we will be adding the support for this.
However this does raise the question as why my local copy of the site running under IIS seems to accept the requests. I would expect the request to rejected with a 404 http status. Also we have other sites running on the Test server that are behaving the same as my local server.
I am not sure if it has something to do with the fact that the requests are actually redirect requests. The 'main site / portal' is an old ASP.Net Web Forms application that then redirects to another 'routing' ASP.Net Mvc 3 web application that will re-route the request depending on business logic to 1 of 3 other 'channel' ASP.Net Mvc 3 web applications. All the channels essentially provide the same function but have slightly different business logic within them. Each channel has a landing controller that will redirect the user to the page where they should be going to. And it is the action on these ladning controllers that have the [HttpGet] attribute on.
The following is what occurs on 1 of the 3 channels on the test server:
User clicks a button
POST request to the 'Portal' site results in 302 to the 'Routing' site
POST request to the 'Routing' site results in 302 to the 'Channel' site
POST requets to the 'Channel' site results in 404.
The following is what ocurrs on the other 2 channels on the test server and on all 3 channels on my local server:
User clicks a button
POST request to the 'Portal' site results in 302 to the 'Routing' site
POST request to the 'Routing' site results in 302 to the 'Channel' site
POST requets to the 'Channel' site results in 302 to the destination page within the 'Channel' site.
POST request to the 'Channel' for destination page results in 200 and the page being servered.
UPDATE:
It turns out that I've been well and truly led up the garden path. The redirected requested are all being done via Http GET and not Http POST as is the correct behaviour for a 302 redirect. However IE developer tools incorrectly displays these as POST requests instead of GET requests. It turns out that the channel server had not been deployed to Test.
A http response with a 302 status for a http request with a POST method / verb will result in a new Http Request with a GET method / verb. This means that a redirect to an action on a controller with the [HttpGet] attribute will be successful.
Related
I have a Ruby on Rails application which redirects users to the start or login page if they end up at a resource they are not authorized for.
For that, it redirects through a 302 Found.
This does not feel right to me, as for example a successful creation of a resource via POST also returns a 302, with the only difference being that it redirects to the created resource.
On the other hand, it does not seem possible to redirect a user without returning a 30X status code (401/403 in this case).
Am I missing something here, or am I already doing it correctly and this is just the way to go?
Well I'd say that it depends of the context, for an API I'd go for you way, if the user is trying to reach an endpoint without authentication or without enough permissions, I'd return a 401 or 403 respectively.
But for a web application without a separated frontend app, you've no choice to tell to the browser where it has to go next and the only way of doing this is to use redirections (that are only 3xx HTTP codes => https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#redirection_messages).
I am trying to create my very first Azure Logic App that simply makes a http post request every hour to a website that has MVC ASP authentication. Whilst setting up the http Logic App action I am using the Basic option to enter the user details.
When it is run, the Logic App keeps failing and returning a 302 (redirect) error; I guess this is because the http post is getting redirected to the account login page.
I have run a test by carrying out a Logic App action to run a http post on a url from the same site that doesn't require user authorisation and it works.
I have also read that I may be able to add configuration to the Logic App action using the Run After rules, but for some reason this option is disabled for my action.
I'd appreciate it if someone with any knowledge in this area, could provide some possible direction.
Thanks.
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
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 using the new MVC 4 Beta Web API. I want to add an [Authorize] attribute to the Get action in order to have the user authenticate themselves before getting data from the server. I am using fiddler to test the action, but it is redirecting me to the Login Url that is defined in the web.config. I am using [System.Web.Http.Authorize] to add the [Authorize] attribute.
The reason for this happening is because the Forms Authentication module hijacks the 401 HTTP status code returned by the Web API and redirects to the Login page. You may take a look at the following blog post in which Phil Haack talks about how to configure ASP.NET to prevent it from doing this for AJAX requests. You could slightly modify his code so that it does this for all requests, or only for requests for your Api controllers.
To get it working in my API I just removed the authentication section from web.config and wrote (well converted from my WCF WebApi code) a message handler. I've put what I did in to a blog post.